[llvm-dev] *** GMX Spamverdacht *** Re: clang 4.0.0: Invalid code for builtin floating point function with -mfloat-abi=hard -ffast-math (ARM)

[Renato Golin via llvm-dev]

On 13 July 2017 at 11:55, Peter Smith <peter.smith at linaro.org> wrote:
> My understanding (not much) of gcc is that the default of -mfloat-abi
> is controllable at gcc build time. Some distributions such as debian
> use gnueabihf to distinguish -mfloat-abi=hard and gnueabi as
> -mfloat-abi=soft, but not all do i.e. they do not follow the
> convention of adding hf to the triple so you can have eabi meaning
> -mfloat-abi=hard. If I'm correct here it seems that it is impossible
> to match any arbitrary target that you might get from gcc as there
> isn't a universally followed convention. To me this implies that
> -mfloat-abi should take precedence over what it is in the target.

Some OSs take the hf/sf division to the arch name (armv7lh) instead of
the ABI, so just using the environment part of the triple is not
enough.

This is really crazy and impossible to get it right because you never
know what you will get and OSs can change the run time behaviour
without warning.

There were suggestions to make Clang more like GCC and hard-code stuff
at build time, but this seems forcing one toolchain to behave like the
other for no additional benefit.

--renato