[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 --- Comment #13 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:c8c587b854c9e85fc9ce58c8192d532205f0ee1f commit r14-9104-gc8c587b854c9e85fc9ce58c8192d532205f0ee1f Author: Tamar Christina Date: Wed Feb 21 11:42:13 2024 + 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.
[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #12 from Tamar Christina --- Indeed, should we just xfail it on AArch64?
[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 Andrew Pinski 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 --- Still fails.
[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 --- Comment #10 from Richard Earnshaw --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 --- Comment #9 from Francois-Xavier Coudert --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
--- Comment #8 from Richard Earnshaw ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 --- Comment #7 from Francois-Xavier Coudert --- @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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 --- Comment #6 from Richard Earnshaw --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
--- Comment #5 from Francois-Xavier Coudert ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 --- Comment #4 from Andreas Schwab --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 --- Comment #3 from Andreas Schwab --- Still STOP 3.
[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 Francois-Xavier Coudert changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-28 --- Comment #2 from Francois-Xavier Coudert --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 --- Comment #1 from Andreas Schwab --- STOP 3
