This change was orignally approved in Differential Revision
https://reviews.llvm.org/D40256 and committed in r319420 and subsequently
reverted in r319425.
The problem was identified due to creating a local string which was placed
in a vector used by the calling function resulting in undefined behaviour;
this revised patch fixes this issue with a call to Args.MakeArgString()
and updates the test results due to the fix (order of expected options
changed requiring more matching patterns) and other changes affecting
the tests since this issue was previously approved (macro hex constants
changing case). Due to the number of changed lines in the tests I though
I should get this change re-reviewed and approved.
To be compatible with GCC if soft floating point is in effect any FPU
specified is effectively ignored, eg,
-mfloat-abi=soft -fpu=neon
If any floating point features which require FPU hardware are enabled
they must be disable.
There was some support for doing this for NEON, but it did not handle
VFP, nor did it prevent the backend from emitting the build attribute
Tag_FP_arch describing the generated code as using the floating point
hardware if a FPU was specified (even though soft float does not use
the FPU).
Disabling the hardware floating point features for targets which are
compiling for soft float has meant that some tests which were incorrectly
checking for hardware support also needed to be updated. In such cases,
where appropriate the tests have been updated to check compiling for soft
float and a non-soft float variant (usually softfp). This was usually
because the target specified in the test defaulted to soft float.