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.git;a=commit;h=c0a4a658097c56fa03d04b8d15c3ea02961d62
> 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!
On 2022-01-24T12:54:27+, Hafiz Abid Qadeer wrote:
> On 24/01/2022 08:45, Tobias Burnus wrote:
>> On 21.01.22 18:15, Thomas Schwinge wrote:
>>> I'm seeing this test case randomly/non-deterministically FAIL to execute,
>>> differently on different systems and runs, for example: [...]
>>> I'
On 25.01.22 10:19, Thomas Schwinge wrote:
I am trying to figure out if the problem you observed
is a general one or just specific to fortran testcase.
So, unless the '-fsanitize=thread' issues are bogus -- unlikely ;-) -- it
seems a latent issue generally, now fatal with
'libgomp.fortran/allocat
On Mon, Jan 17, 2022 at 12:11:59AM +0100, FX via Gcc-patches wrote:
> This patch is the third in my “signaling NaN” series. For targets with IEEE
> support but without the issignaling macro in libc (i.e., everywhere except
> glibc), this allows us to provide a fallback implementation. In order to
Hi Jakub,
> This doesn't seem to handle the powerpc* IBM double double long double.
Do we support the IEEE Fortran modules on this target, despite having a
non-IEEE long double? I remember we talked about it when I first implemented
it, but can’t remember what choice we ended up making.
> __L
Hi!
Apparently something we (at least I) have totally missed, we clearly have a
problem with the IEEE modules for the dual -mabi={ibm,ieee}longdouble.
We have:
__ieee_arithmetic_MOD_ieee_class_16;
__ieee_arithmetic_MOD_ieee_support_datatype_16;
__ieee_arithmetic_MOD_ieee_support_denorm
Hi,
On 25.01.22 12:44, Jakub Jelinek via Fortran wrote:
Apparently something we (at least I) have totally missed, we clearly have a
problem with the IEEE modules for the dual -mabi={ibm,ieee}longdouble.
We have:
__ieee_arithmetic_MOD_ieee_class_16;
__ieee_arithmetic_MOD_ieee_support_da
> Thus, more functions could be handled in the compiler itself.
> (Likewise for INTMOD_IEEE_EXCEPTIONS, not that I know whether
> that has any relevant functions.)
In theory, there is no reason why we need an explicit .mod file in the library
for any of the three IEEE modules. They would probably
Hi all,
attached patch fixes wrong code generation when broadcasting a derived type
containing allocatable and non-allocatable scalars. Furthermore does it prevent
broadcasting of coarray-tokens, which are always local this_image. Thus having
them on a different image makes no sense.
Bootstrapped
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
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
> > y be x?
>
> Indeed. Fixed:
> https://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?
> I’ve fixed that case:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0336ab4e7e2eb58a64d8ee4e5e8083dd53a4d2d
>
> 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: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
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 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
> 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
Dear Fortranners,
committed as obvious after regtesting on x86_64-pc-linux-gnu.
We already had a check for the MOLD argument to the TRANSFER
intrinsic for having storage size 0, which failed if MOLD was
an EXPR_VARIABLE although having rank != 0. Duh.
Adjusting that check fixed the issue.
I int
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
Hi Andre',
Am 25.01.22 um 17:32 schrieb Andre Vehreschild via Fortran:
Hi all,
attached patch fixes wrong code generation when broadcasting a derived type
containing allocatable and non-allocatable scalars. Furthermore does it prevent
broadcasting of coarray-tokens, which are always local this_
>> 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
24 matches
Mail list logo
