[Bug libgcc/102017] New: libgcc ieee754-df.S for arm does not support exceptions

[Bug libgcc/102017] New: libgcc ieee754-df.S for arm does not support exceptions

[clyon at gcc dot gnu.org]

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

            Bug ID: 102017
           Summary: libgcc ieee754-df.S for arm does not support
                    exceptions
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

As stated in libgcc/config/arm/ieee754-df.S:

* Exceptions aren't supported yet, but that can be added quite easily
* if necessary without impacting performances.

Since I upgraded the newlib version I use in validation (moved from 3.3.0 to
4.1.0), fenv support is not enabled, thus enabling new tests in the GCC
testsuite.

Some of them fail at execution time on some targets because the code in libgcc
does not raise exception as those tests expect:
gcc.dg/torture/float32x-nan.c
gcc.dg/torture/float64-nan.c
gcc.dg/torture/inf-compare-1.c
gcc.dg/torture/inf-compare-2.c
gcc.dg/torture/inf-compare-3.c
gcc.dg/torture/inf-compare-4.c
gcc.dg/torture/pr52451.c

This happens when targeting cortex-m4 or cortex-m33/-march=armv8-m.main+fp+dsp.

These tests pass when targeting cortex-m7, because it has a DP FPU, and does
not use the libgcc emulation code.

Some of these tests already have xfail { powerpc*-*-* } or dg-skip-if "fenv" {
powerpc-ibm-aix* }, but I am not sure whether and how we want to do this on arm
(maybe using a dg-skip-if checking for -mcpu/march, but that could be painful).

Or do we want to update libgcc to raise exceptions properly?

[Bug libgcc/102017] libgcc ieee754-df.S for arm does not support exceptions

[rearnsha at gcc dot gnu.org]

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

--- Comment #1 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
There are a number of complications here:
- What's the code size overhead?  Even if the performance overhead is trivial,
I suspect the additional code might be non-trivial on an m-profile device, so
is there a simple way to choose not to link such support in when not
needed/wanted?  Perhaps it could be done by using some weak function calls for
raising the exceptions and then only link the stub code in if there are calls
to fe*().
- How would it work in a hybrid -mfloat-abi=soft + -mfloat-abi=softfp
environment?  See the point above again, especially if the float-env testing
routines can get inlined.

[Bug libgcc/102017] libgcc ieee754-df.S for arm does not support exceptions

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
If you want to support exceptions and rounding modes for double precision 
on processors with hardware support for single-precision only 
floating-point arithmetic, I suggest using soft-fp instead of this 
Arm-specific code; lots of configurations use soft-fp integrated with 
hardware exceptions and rounding modes like that (e.g. for binary128 
TFmode arithmetic on architectures without hardware support for it but 
with hardware SFmode and DFmode support).

If you want to support exceptions, rounding modes or both on processors 
with no hardware floating-point, you have the complication of needing 
working TLS support from the runtime environment (if the floating-point 
code might ever be used in an environment with threads), because 
exceptions and rounding modes are thread-local (not global) state.

[Bug libgcc/102017] libgcc ieee754-df.S for arm does not support exceptions

[clyon at gcc dot gnu.org]

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

--- Comment #3 from Christophe Lyon <clyon at gcc dot gnu.org> ---
I made a typo in my description of the bug, it should read: fenv support is NOW
enabled.

[Bug libgcc/102017] libgcc ieee754-df.S for arm does not support exceptions

[torbjorn.svensson at foss dot st.com]

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

Torbjörn SVENSSON <torbjorn.svensson at foss dot st.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |torbjorn.svensson at foss dot st.c
                   |                            |om

--- Comment #4 from Torbjörn SVENSSON <torbjorn.svensson at foss dot st.com> ---
I made an attempt to handle this for Arm as the number of failed tests related
to this is growing with each new GCC version...

Please review this patch
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602025.html and give
me your feedback.
Is this the right way to go?
Is there a better way to go in order to avoid filling the log with fails that
is not going to be addressed?