>> 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
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_
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
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
> 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
> > 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?
It looks like a multilib build, but the FreeBSD toolchain
cannot find its ls-elf32.so.1 dynamic loader (or I need
to
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
> 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,
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
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 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
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
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
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'
> 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.git;a=commit;h=c0a4a658097c56fa03d04b8d15c3ea02961d62
24 matches
Mail list logo
