https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #16 from Thiago Jung Bauermann
---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #15 from Andrew Pinski ---
(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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
Thiago Jung Bauermann changed:
What|Removed |Added
CC||thiago.bauermann at linaro dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #13 from 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #12 from Rich Felker ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
nsz at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
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
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #9 from nsz at gcc dot gnu.org ---
ok i was looking at the wrong code, didn't know libgcc2,
i agree that's the right way to fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #8 from joseph at codesourcery dot com ---
The code snippet you posted looks like exactly what libgcc2.c would
typically do for __floatundidf. Given that, I'd prefer building the
relevant function from libgcc2.c rather than having
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #7 from nsz at gcc dot gnu.org ---
i think the code snippet i posted is more efficient and significantly
smaller than using libgcc (which also sounds hard to wire up to do the
right thing). the code sequence can possibly be even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #6 from joseph at codesourcery dot com ---
Arm only uses soft-fp for Thumb-1; otherwise it uses Arm-specific assembly
code.
A natural fix might be, for these particular functions, in the hard-float
case, to use the libgcc2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #5 from nsz at gcc dot gnu.org ---
ok so the real problem is that libgcc does not define
FP_INIT_ROUNDMODE and FP_HANDLE_EXCEPTIONS etc for
hardfloat arm targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #4 from joseph at codesourcery dot com ---
The libgcc2.c functions for conversions that get used by default on most
architectures should respect the rounding mode if the underlying
single-word-to-floating-point instruction does so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #3 from nsz at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #2)
> Don't you need #pragma STDC FENV_ACCESS?
yes, for iso c conformance you need it, but gcc does not
handle it anyway, instead it requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #2 from Andreas Schwab ---
Don't you need #pragma STDC FENV_ACCESS?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #1 from nsz at gcc dot gnu.org ---
floating-point exceptions are also missing for the same reason.
16 matches
Mail list logo
