> AFAICT, the first condition does not fail due to the missing
> trailing underscores.
>
> #if __FLOAT_WORD_ORDER == __BIG_ENDIAN
>
> becomes (I believe)
>
> #if 0 == 0
>
> so FreeBSD was using big endian in FX's issignaling_fallback
> when it needed little endian.
Yeah that makes total sense.
On Wed, Jan 26, 2022 at 11:47:27AM +0100, Tobias Burnus wrote:
> On 25.01.22 21:56, FX via Fortran wrote:
> > What I wonder is: if those conditions failed, then the struct they define
> > should have been empty, and therefore the code shouldn’t compile anyway
> > (that was the intent).
>
> Would
On 25.01.22 21:56, FX via Fortran wrote:
What I wonder is: if those conditions failed, then the struct they define
should have been empty, and therefore the code shouldn’t compile anyway (that
was the intent).
Wouldn't it make more sense to add '#else' / '#error ""' in that case?
Tobias
>> Does the attached patch fix the remaining failures?
>
> Yes!
>
> % gmake check-fortran RUNTESTFLAGS="ieee.exp=signaling_\*"
> ...
>=== gfortran Summary ===
>
> # of expected passes24
> # of unsupported tests 6
Thanks Steve, pushed:
https://gcc.gnu.org/gi
On Tue, Jan 25, 2022 at 09:56:05PM +0100, FX wrote:
> > Found it. https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
> >
> > Add trailing undersores to __FLOAT_WORD_ORDER and change
> > __BIG_ENDIAN to __ORDER_BIG_ENDIAN__. Likewise for LITTLE.
>
> Thanks Steve!
>
> What I wonder
> Found it. https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
>
> Add trailing undersores to __FLOAT_WORD_ORDER and change
> __BIG_ENDIAN to __ORDER_BIG_ENDIAN__. Likewise for LITTLE.
Thanks Steve!
What I wonder is: if those conditions failed, then the struct they define
should
On Tue, Jan 25, 2022 at 08:52:34PM +0100, FX wrote:
> > With --disable-multilib, so no -m32 support, I still
> > signaling_3.f90 failing. In
> >
> > ! { dg-do run { xfail { { i?86-*-* x86_64-*-* } && ilp32 } } }
> > ! x87 / x86-32 ABI is unsuitable for signaling NaNs
>
> This just means the tes
On Tue, Jan 25, 2022 at 09:04:05PM +0100, FX wrote:
> This is x86_64-linux, with the same source:
>
> $ gcc-10 v.c -fsignaling-nans && ./a.out
> Quiet NaN
> nan 7fc0
> nan 7ff8
> nan 564e29277fffc000
> Signaling NaN
> nan 7fa0
> nan 7ff4
> nan 564e29277f
On Tue, Jan 25, 2022 at 08:52:34PM +0100, FX wrote:
> > With --disable-multilib, so no -m32 support, I still
> > signaling_3.f90 failing. In
> >
> > ! { dg-do run { xfail { { i?86-*-* x86_64-*-* } && ilp32 } } }
> > ! x87 / x86-32 ABI is unsuitable for signaling NaNs
>
> This just means the tes
This is x86_64-linux, with the same source:
$ gcc-10 v.c -fsignaling-nans && ./a.out
Quiet NaN
nan 7fc0
nan 7ff8
nan 564e29277fffc000
Signaling NaN
nan 7fa0
nan 7ff4
nan 564e29277fffa000
On Tue, Jan 25, 2022 at 09:05:55AM +0100, FX wrote:
>
> > Got the following in testsuite/gfortran/gfortran.log
> >
> > NaN 7FFFA000
> > NaN 7FFFC000
> > NaN 7FFFA000
> >
Could be a problem with __builtin_nansl().
#include
#include
int
main(void)
{
unio
> With --disable-multilib, so no -m32 support, I still
> signaling_3.f90 failing. In
>
> ! { dg-do run { xfail { { i?86-*-* x86_64-*-* } && ilp32 } } }
> ! x87 / x86-32 ABI is unsuitable for signaling NaNs
This just means the test shouldn’t be run on 32-bit Intel.
Can you run this:
#include
On Tue, Jan 25, 2022 at 09:09:15AM +0100, FX wrote:
> > FAIL: gfortran.dg/ieee/signaling_3.f90 -O0 execution test
>
> For that one, can you confirm it’s a 64-bit run, not -m32?
> I’ve fixed that case:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0336ab4e7e2eb58a64d8ee4e5e8083dd53a4d2d
>
On Tue, Jan 25, 2022 at 09:05:55AM +0100, FX wrote:
> Hi Steve,
>
> > New signaling NaN causes 12 testsuite failures
>
> Thanks for alerting me.
>
> > Line 42 of signal_1.f90 looks wrong unless the
> > line is testing conversion on assignment. Should
> &g
On Tue, Jan 25, 2022 at 09:09:15AM +0100, FX wrote:
> > FAIL: gfortran.dg/ieee/signaling_3.f90 -O0 execution test
>
> For that one, can you confirm it’s a 64-bit run, not -m32?
It looks like a multilib build, but the FreeBSD toolchain
cannot find its ls-elf32.so.1 dynamic loader (or I need
to
> FAIL: gfortran.dg/ieee/signaling_3.f90 -O0 execution test
For that one, can you confirm it’s a 64-bit run, not -m32?
I’ve fixed that case:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0336ab4e7e2eb58a64d8ee4e5e8083dd53a4d2d
FX
Hi Steve,
> New signaling NaN causes 12 testsuite failures
Thanks for alerting me.
> Line 42 of signal_1.f90 looks wrong unless the
> line is testing conversion on assignment. Should
> y be x?
Indeed. Fixed:
https://gcc.gnu.org/git/?p=gcc.gi
On Mon, Jan 24, 2022 at 04:44:53PM -0800, Steve Kargl wrote:
> % gmake check-fortran RUNTESTFLAGS="ieee.exp=sign\*"
>
Line 42 of signal_1.f90 looks wrong unless the
line is testing conversion on assignment. Should
y be x?
Instrumented signal_1.f90.
Changed
if (ieee_class(z) /= ieee_signa
% gmake check-fortran RUNTESTFLAGS="ieee.exp=sign\*"
Test run by sgk on Mon Jan 24 16:42:07 2022
Native configuration is x86_64-unknown-freebsd14.0
=== gfortran tests ===
Schedule of variations:
unix
Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as
19 matches
Mail list logo
