[Bug fortran/107071] New: gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[Bug fortran/107071] New: gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[fxcoudert at gcc dot gnu.org]

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

            Bug ID: 107071
           Summary: gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

According to
https://gcc.gnu.org/pipermail/gcc-testresults/2022-September/768757.html
the new test gfortran.dg/ieee/modes_1.f90 fails on aarch64-suse-linux-gnu.

I do not have access to this target, so I cannot test. Could someone run it and
let me know what the output is?

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[schwab@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
STOP 3

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-09-28

--- Comment #2 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Oups, there are two lines that trigger this in the test. Can you try with this
patch?

diff --git a/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
b/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
index b6ab28847f7..205c47f3800 100644
--- a/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
+++ b/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
@@ -81,15 +81,15 @@ program foo
   ! Check again
   if (ieee_support_underflow_control()) then
     call ieee_get_underflow_mode(f)
-    if (.not. f) stop 3
+    if (.not. f) stop 4
   endif
   if (ieee_support_rounding(ieee_down)) then
     call ieee_get_rounding_mode(rmode)
-    if (rmode /= ieee_down) stop 4
+    if (rmode /= ieee_down) stop 5
   endif
   if (ieee_support_halting(ieee_overflow)) then
     call ieee_get_halting_mode(ieee_overflow, f)
-    if (f) stop 5
+    if (f) stop 6
   endif

 end program foo

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[schwab@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
Still STOP 3.

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[schwab@linux-m68k.org]

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

--- Comment #4 from Andreas Schwab <schwab@linux-m68k.org> ---
The problem is that set_fpu_trap_exceptions does not check if feenableexcept
was successful.  Just because FE_* are defined does not mean that the hardware
supports fpu exceptions of that kind (it may depend on the actual flavor of the
hardware).

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[fxcoudert at gcc dot gnu.org]

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

--- Comment #5 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Right now the code to test support is indeed like this for glibc targets except
x86/x86_64 (libgfortran/config/fpu-glibc.h):


int
support_fpu_rounding_mode (int mode)
{
  switch (mode)
    {
      case GFC_FPE_TONEAREST:
#ifdef FE_TONEAREST
        return 1;
#else
        return 0;
#endif
…


so the correct code would be instead:


int
support_fpu_rounding_mode (int mode)
{
  int oldmode, res;

  switch (mode)
    {
      case GFC_FPE_TONEAREST:
#ifdef FE_TONEAREST
        oldmode = fegetround ();
        res = fesetround (FE_TONEAREST);
        fesetround (oldmode);
        return res ? 0 : 1;
#else
        return 0;
#endif
…



Does that seem correct to you?
Also, looking at the doc, I think this file may need to have this line
somewhere at the top:

#pragma STDC FENV_ACCESS ON

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[rearnsha at gcc dot gnu.org]

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

--- Comment #6 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Whilst the patch is probably fine and a better way of doing this, it won't fix
the test failure.  I think your problem is that you're assuming that an
exception will cause a trap in hardware.  That's not how IEEE says FP
exceptions have to work.  On aarch64, for most implementations the exceptions
are accumulated in a status register and you have to read that register to see
if an FP exception occurred.

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[fxcoudert at gcc dot gnu.org]

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

--- Comment #7 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
@Richard The test in gfortran.dg/ieee/modes_1.f90 is not doing that. It is
checking that the floating-point modes (rounding mode, underflow mode, and
halting modes) can be set and restored. It is not actually performing any FP
operation at all.

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[rearnsha at gcc dot gnu.org]

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

--- Comment #8 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #7)
> @Richard The test in gfortran.dg/ieee/modes_1.f90 is not doing that. It is
> checking that the floating-point modes (rounding mode, underflow mode, and
> halting modes) can be set and restored. It is not actually performing any FP
> operation at all.

This is to do with the trapping, though, isn't it?  The failing test is trying
to test the halting mode setting and restoration.  The code is currently
assuming that because the flag bit exists, it can set and restore it, but
although the bit is defined in the architecture, on some (most) implementations
it's RAZ/WI (read-as-zero, write-ignored).  So the code that assumes this goes
wrong.

I might be slightly on the wrong lines here, but in the glibc fp support we
have

int
support_fpu_trap (int flag)
{
  return support_fpu_flag (flag);
}

So we're immediately assuming that if we have the flag, we can support the
trap.  And of course, support_fpu_flag only tests that the relevant flag bit is
defined, not if the HW supports changing it.

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[fxcoudert at gcc dot gnu.org]

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

--- Comment #9 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
OK so there are three things tested here:

- underflow mode
- rounding mode
- trapping mode

For glibc targets, underflow control is only marked as supported for the float
and double types on __alpha__. For rounding mode, the code makes incorrect
assumptions and I have proposed a prototype patch to
support_fpu_rounding_mode().

For trapping modes, it means that support_fpu_trap() needs to perform correct
runtime checks. As I understand, this can be done by calling feenableexcept()
and checking whether it returns -1 (flag not supported) or something else (flag
supported). Then I need to restore the flag with fedisableexcept(), if the flag
was not already set prior to the feenableexcept() call.

I will write a patch when I have time. Thanks for pointing the issue out to me.

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[rearnsha at gcc dot gnu.org]

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

--- Comment #10 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
That sounds broadly sensible.  One optimization might be to check if the
exception trapping is already enabled, then you can skip the read/set/restore
dance entirely in that case. That might be more efficient on some hardware as
changing the flags might cause a pipeline bubble.

The same is also true for the other tests where you do a read/set/restore
sequence.

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2022-09-28 00:00:00         |2023-11-23
                 CC|                            |pinskia at gcc dot gnu.org

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Still fails.

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tnfchris at gcc dot gnu.org

--- Comment #12 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Indeed, should we just xfail it on AArch64?

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:c8c587b854c9e85fc9ce58c8192d532205f0ee1f

commit r14-9104-gc8c587b854c9e85fc9ce58c8192d532205f0ee1f
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Wed Feb 21 11:42:13 2024 +0000

    AArch64: skip modes_1.f90 [PR107071]

    This test has never worked on AArch64 since the day it was committed.  It
has
    a number of issues that prevent it from working on AArch64:

    The testfailures seem to be known and triaged, so until that's fixed
there's
    no point in running this test.

    gcc/testsuite/ChangeLog:

            PR fortran/107071
            * gfortran.dg/ieee/modes_1.f90: skip aarch64, arm.