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

[Peter Smith via llvm-dev]

I have been looking into one particular case so far which is in clang
https://bugs.llvm.org/show_bug.cgi?id=28164
The _Complex multiply and divide helpers are always called with AAPCS,
regardless of -mfloat-abi=hard which is not correct.

I'm not at the moment looking at the general problem but I can spare
the time to do so soon.

Apologies in advance for jumping in here without knowing much of the context.

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.

Peter


On 13 July 2017 at 11:07, Renato Golin <renato.golin at linaro.org> wrote:
> Hi Peter,
>
> Sorry, I completely missed this reply. Peter (Smith) is looking into
> it, so copying him, here.
>
> I remember too many hacks to Clang's driver to understand all the
> nuances between the flags to copy GCC bug-for-bug. We've done it
> mostly because the solution space is gigantic and too many (external)
> people rely on those bugs being there or the hackery they have won't
> work.
>
> I have always been a strong supporter to clean up GCC bug
> implementations and be candid (but helpful) to the users to help them
> migrate to a decent scheme (and ultimately fix GCC).
>
> Hopefully, we'll have now enough people looking into it that we can
> get at least some of that cleaned up.
>
> cheers,
> --renato
>
> PS: Also adding Joerg, because he has some weird cases on his own.
>
> On 31 March 2017 at 00:12, Peter Jakubek <pjak at gmx.de> wrote:
>> I think the problem is here:
>>
>> llvm\lib\Target\ARM\ARMISelLowering.cpp, line 187:
>>
>>   if (!Subtarget->isTargetDarwin() && !Subtarget->isTargetIOS() &&
>>       !Subtarget->isTargetWatchOS()) {
>>     const auto &E = Subtarget->getTargetTriple().getEnvironment();
>>
>>     bool IsHFTarget = E == Triple::EABIHF || E == Triple::GNUEABIHF ||
>>                       E == Triple::MuslEABIHF;
>>     // Windows is a special case.  Technically, we will replace all of the
>> "GNU"
>>     // calls with calls to MSVCRT if appropriate and adjust the calling
>>     // convention then.
>>     IsHFTarget = IsHFTarget || Subtarget->isTargetWindows();
>>
>>     for (int LCID = 0; LCID < RTLIB::UNKNOWN_LIBCALL; ++LCID)
>>       setLibcallCallingConv(static_cast<RTLIB::Libcall>(LCID),
>>                             IsHFTarget ? CallingConv::ARM_AAPCS_VFP
>>                                        : CallingConv::ARM_AAPCS);
>>   }
>>
>> IsHFTarget is only true if the target is eabihf. -msoft-abi is completely
>> ignored.
>>
>> cheers,
>>
>> Peter
>>
>> Am 30.03.2017 um 00:15 schrieb Renato Golin:
>>>
>>> On 29 March 2017 at 02:33, Saleem Abdulrasool <compnerd at compnerd.org>
>>> wrote:
>>>>
>>>> sin/cos are libm functions, and so a libcall to those need to honour the
>>>> floating point ABI requests.  The calling convention to be followed there
>>>> should match `-mfloat-abi` (that is, -mfloat-abi=hard => AAPCS/VFP,
>>>> -mfloat-abi=soft => AAPCS).
>>>
>>>
>>> Exactly, but they're not, and that's the problem. Do you have any idea
>>> why -ffast-math would change their PCS for libc calls?
>>>
>>> The behaviour seems to have been by your patch
>>> (https://reviews.llvm.org/rL291909), so maybe there's some
>>> transformation that uses the run-time functions, or some other badly
>>> coupled logic...
>>>
>>> cheers,
>>> --renato
>>>
>>