On Fri, Jul 5, 2024 at 5:23 AM FX Coudert <fxcoud...@gmail.com> wrote:
> Hi,
> The core of the powerpc-FPU manipulation is okay for me. Some comments
> below.
>
Thank you for reviewing!
> > --- a/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
> > +++ b/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
> > @@ -1,3 +1,11 @@
> > +#ifdef __POWERPC__ // No support for issignaling in math.h on Darwin PPC
>
> Two things:
>
> 1. I don’t understand why that needs to be added. The companion test in
> signaling_2.f90 has:
>
> ! { dg-require-effective-target issignaling } */
> ! The companion C source needs access to the issignaling macro.
>
> Therefore, if the issignaling macro is not available, the test should not
> even be run.
>
This part of the patch is quite old, but from the remaining log it looks I
got an error here:
```
issignaling2483.c: In function 'main':
issignaling2483.c:6:18: warning: implicit declaration of function
'issignaling' [-Wimplicit-function-declaration]
Undefined symbols:
"_issignaling", referenced from:
_main in ccORNr9V.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit status
```
Now on a second thought, this did not require a fix perhaps. We can drop it.
2. Maybe this is actually moot. Is the __builtin_issignaling() macro
> available on all targets? The test was written before it was added to the
> middle-end. If the answer to the previous question is yes, we should simply
> use it in instead of the macro.
>
I am not really sure about support for it across targets. (If we are
unclear on this, changes to tests themselves could be moved to a separate
issue, I guess.)
> +/* There is no consistency re what is to be included in all_invalid.
> > + Apple libm has 0x01f80300, Openlibm/FreeBSD/NetBSD has 0x21f80700
> > + and OpenBSD has 0x01f80700. In particular, FE_INVALID_SOFT and
> > + FE_INVALID are contested. */
> > +#define FE_ALL_INVALID 0x01F80700
> > +#define FE_NO_INVALID 0xFE07F8FF
> > +
> > +/* Apple libm has 0xFFF80300 and 0x0007FCFF here. */
> > +#define FE_ALL_FLAGS 0xFFF80700
> > +#define FE_NO_FLAGS 0x0007F8FF
>
> Since it’s a darwin-only file, why not follow Apple libm conventions?
>
I arrived at a conclusion that they are not exactly correct, and moreover
look somewhat inconsistent internally (i.e. different Apple headers between
each other in regard to assumptions for powerpc hardware capabilities).
However I am no expert here, so please take it with a grain of salt.
Do we know exactly whether FE_ALL_INVALID should or should not include a)
VX and b) VX_SOFT bits?
(This could be a matter of purely academic relevance though, since I did
try switching the values for those macros to add/remove questionable bits,
and the only one to make a difference, FWIW, was SET_INVALID define.)
> There is one test which changes from PASS to FAIL (round_4), however I
> think this is not a real regression, and the test in its present form is
> expected to fail.
> > See comments in the test code in the source and my post:
> https://gcc.gnu.org/pipermail/fortran/2024-July/060612.html
>
>
> I agree that round_4.f90 should be added to the dg-skip-if.
> But I’d like to understand better what are the other new failures, and why
> there arise?
>
> FX
I suspect that a chunk of failures are due to incorrect assumptions for
precision; there are also some obscure differences between Power and
PowerPC architectures in regard of floating point, which might not be
accounted for in the tests.
Since I was getting consistent failures with different versions of the
patch, I am reasonably sure that failures are not caused by fine details of
the implementation here; at least these tests failed on every attempt (and
aside from one version, extra failures, if present, were in single digit
numbers), and whenever the output contained numerical values, those also
matched, AFAICT.
I think I cannot attach a log here, even compressed, but I have put it
here:
http://macos-powerpc.org/gcc/gfortran/gfortran_macos_ppc_2024.06.28_ieee_added.log.zip
If you or anyone could help me to debug, I can rerun tests, modify
something etc. It is desirable to have it working correctly, of course.
By the way, do we have some point of comparison from other ppc32 platforms,
Linux or BSD (for the recent gcc master)?
Sergey
