[llvm-bugs] [Bug 27455] New: disagreement with GCC about ABI of libgcc functions on hard-float ARM

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27455

            Bug ID: 27455
           Summary: disagreement with GCC about ABI of libgcc functions on
                    hard-float ARM
           Product: clang
           Version: unspecified
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: brian at peloton-tech.com
                CC: anton at korobeynikov.info, compnerd at compnerd.org,
                    jonathan at codesourcery.com, kristof.beyls at arm.com,
                    llvm-bugs at lists.llvm.org, tzuhsiang.chien at gmail.com
    Classification: Unclassified

Created attachment 16246
  --> https://llvm.org/bugs/attachment.cgi?id=16246&action=edit
A simple program which demonstrates the affects

Clang and GCC disagree about the calling convention for the helper functions in
libgcc/compiler-rt on ARM with hardware floating point. Clang passes the
floating point arguments in integer registers (like with -mfloat-abi=soft), but
GCC calls them like other functions with the hard-float ABI. The only reference
to this I can find online is an LLVM development mailing list post [1]
discussing why Clang switched to always using soft-float. At least one of the
Clang developers thought GCC did this too, but it doesn't seem to currently.
Complex arithmetic is implemented with these functions even when hardware
floating point is supported, which means complex arithmetic is pretty
completely broken on platforms like this when using libgcc.

[1] http://lists.llvm.org/pipermail/llvm-dev/2014-October/077898.html

I found the code in clang's lib/CodeGen/TargetInfo.cpp which sets BuiltinCC to
CallingConv::ARM_AAPCS and the __attribute__((pcs("aapcs"))) in compiler-rt's
lib/builtins/int_lib.h which compiles the relevant functions that way. I can't
find any evidence of GCC doing either of those.

In all three copies of libgcc.a I've disassembled (Debian Jessie armhf and both
of the ones from gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf) __divdc3
(for example) definitely uses the hard-float ABI. In
clang+llvm-3.8.0-armv7a-linux-gnueabihf/lib/clang/3.8.0/lib/linux/libclang_rt.builtins-armhf.a
(downloaded from llvm.org), __divdc3 is definitely using the soft-float ABI.

Attached is a simple program which demonstrates the effects. 
I've tried with Clang 3.7.1 I cross-compiled for armhf myself and 3.8.0
binaries downloaded from llvm.org.
$ gcc -lm test_complex.c -O3 && ./a.out
works
$ clang -lm test_complex.c -O3 && ./a.out
broken

On 4/21/16 2:36 PM, Renato Golin via cfe-dev wrote:
> I checked with the GCC folks, and the behaviour is:
> 
>  * arm-linux-gnueabi has *only* soft-float
>  * arm-linux-gnueagihf has *only* hard float
>  * arm-none-eabi has *all* variations (above) with the default being soft-float

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160421/0fd20c96/attachment.html>