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

[Peter Jakubek via llvm-dev]

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
>