[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[nsz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970

nsz at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #10 from nsz at gcc dot gnu.org ---
*** Bug 94646 has been marked as a duplicate of this bug. ***

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[nsz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970

nsz at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-04-18

--- Comment #11 from nsz at gcc dot gnu.org ---
confirmed

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970

--- Comment #12 from Rich Felker <bugdal at aerifal dot cx> ---
There's some awful hand-written asm in libgcc/config/arm/ieee754-df.S replacing
the standard libgcc2.c versions; that's the problem. But in order to use the
latter it would need to be compiled with -mfloat-abi=softfp since the
__aeabi_l2d function (and all the __aeabi_* apparently) use the standard
soft-float EABI even on EABIHF targets.

I'm not sure why you want a library function to be called for this on hardfloat
targets anyway. Inlining the hi*0x1p32+lo is almost surely smaller than the
function call, counting spills and conversion of the result back from GP
registers to an FP register. It seems like GCC should be able to inline this
idiom at a high level for *all* targets that lack a floatdidf operation but
have floatsidf.

Of course a high level fix is going to be hell to backport, and this really
needs a backportable fix or workaround (maintained in mcm not upstream gcc)
from musl perspective. Maybe the easiest way to do that is just to hack the
right preprocessor conditions for a hardfloat implementation into
ieee754-df.S...

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970

--- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
bpabi-lib.h is the existing mechanism for renaming libgcc2.c functions and 
declaring them with __attribute__((pcs("aapcs"))).  (But when causing more 
such functions to be used, or such functions to be used when they weren't 
before, we'd need to make sure all the declarations therein are being 
applied properly in the new cases to give the functions the desired ABI.)

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[thiago.bauermann at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970

Thiago Jung Bauermann <thiago.bauermann at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thiago.bauermann at linaro dot org

--- Comment #14 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
This came up in the context of a Linux kernel patch series providing a "Unified
cross-architecture kernel-mode FPU API" because the AMD GPU driver fails to
build on arm with the series applied because of this issue:

https://lore.kernel.org/linux-arm-kernel/75a37a4b-f516-40a3-b6b5-4aa1636f9b60@sifive.com/

Copying the patch author's response here:

> In both cases, the issue is that the toolchain requires runtime support to
> convert between `unsigned long long` and `double`, even when hardware FP is
> enabled. There was some past discussion about GCC inlining some of these
> conversions[1], but that did not get implemented.
> 
> The short-term fix would be to drop the `select ARCH_HAS_KERNEL_FPU_SUPPORT`
> for 32-bit arm until we can provide these runtime library functions.

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Thiago Jung Bauermann from comment #14)
> This came up in the context of a Linux kernel patch series providing a
> "Unified cross-architecture kernel-mode FPU API" because the AMD GPU driver
> fails to build on arm with the series applied because of this issue:
> 
> https://lore.kernel.org/linux-arm-kernel/75a37a4b-f516-40a3-b6b5-
> 4aa1636f9b60@sifive.com/

That is a totally unrelated issue from this one. The issue there is arm EABI
defines the function names rather than GCC and GCC follows the ARM EABI here
(so does clang/LLVM). so you would need to do a similar renaming for the
functions on arm (32bit).

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[thiago.bauermann at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970

--- Comment #16 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Thiago Jung Bauermann from comment #14)
> > This came up in the context of a Linux kernel patch series providing a
> > "Unified cross-architecture kernel-mode FPU API" because the AMD GPU driver
> > fails to build on arm with the series applied because of this issue:
> > 
> > https://lore.kernel.org/linux-arm-kernel/75a37a4b-f516-40a3-b6b5-
> > 4aa1636f9b60@sifive.com/
> 
> That is a totally unrelated issue from this one. The issue there is arm EABI
> defines the function names rather than GCC and GCC follows the ARM EABI here
> (so does clang/LLVM). so you would need to do a similar renaming for the
> functions on arm (32bit).

Thank you! I relayed your point (hopefully correctly) in the email thread
above.