> Thanks. Just a nit, it is cc1 that reports the warning, not f951.
I confirm the patch fixes the testcase failure. And I fixed the comment in a
follow-up commit.
Thanks!
FX
On Wed, Jan 12, 2022 at 12:03:40PM +0100, FX wrote:
> > We need -fintrinsic-modules-path option for the signalling_1.f90 compilation
> > but need to make sure it isn't used when the *.c file is compiled, so they
> > need to be compiled by separate compiler invocations probably.
>
> Thanks for post
Hi Jakub,
> We need -fintrinsic-modules-path option for the signalling_1.f90 compilation
> but need to make sure it isn't used when the *.c file is compiled, so they
> need to be compiled by separate compiler invocations probably.
Thanks for posting the errors! So I wasn’t seeing it because I had
On Wed, Jan 12, 2022 at 11:23:43AM +0100, FX via Gcc-patches wrote:
> I can confirm that I don’t see this failure on a Debian bullseye/sid (Linux
> 5.11.0-46, glibc 2.31-0ubuntu9.2) with a fresh bootstrap of master:
>
> $ grep signaling testsuite/gfortran/gfortran.sum
> PASS: gfortran.dg/ieee/sig
Hi,
I can confirm that I don’t see this failure on a Debian bullseye/sid (Linux
5.11.0-46, glibc 2.31-0ubuntu9.2) with a fresh bootstrap of master:
$ grep signaling testsuite/gfortran/gfortran.sum
PASS: gfortran.dg/ieee/signaling_1.f90 -O0 (test for excess errors)
PASS: gfortran.dg/ieee/signa
Hi HJ,
> I looked at gcc-testresults and find e.g.
>
> https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747938.html
> https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747935.html
>
> which is x86 (64 and 32 bit) by H.J.; plus some more.
> Maybe H.J. can explain what is differ
Hi FX,
Am 11.01.22 um 23:04 schrieb FX via Fortran:
Hi Harald,
I think this patch breaks the testsuite
On what platform? It regtested fine on x86_64-pc-linux-gnu
I looked at gcc-testresults and find e.g.
https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747938.html
https://gcc.gn
Hi Harald,
> I think this patch breaks the testsuite
On what platform? It regtested fine on x86_64-pc-linux-gnu
> since the directive
> ! { dg-additional-sources signaling_1_c.c }
> should rather read
> ! { dg-additional-sources "signaling_1_c.c" }
I find plenty of evidence saying it’s allowed
Hi FX,
Am 02.01.22 um 11:50 schrieb FX via Fortran:
Hi,
This is the first part of a three-patch series to fix PR 82207
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle
signaling NaNs. This part fixes the library code implementing IEEE_CLASS, by
using the issignali
Thanks Mikael. I haven’t been active with gfortran development in a while, but
I originally wrote those IEEE routines so I believe my understanding of them is
fair. I will continue posting my next patches to gather comments (if any), but
they’re relatively straightforward.
The main limitation (
Le 09/01/2022 à 11:52, FX via Fortran a écrit :
ping
Le 2 janv. 2022 à 11:50, FX a écrit :
Hi,
This is the first part of a three-patch series to fix PR 82207
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle
signaling NaNs. This part fixes the library code imple
ping
> Le 2 janv. 2022 à 11:50, FX a écrit :
>
> Hi,
>
> This is the first part of a three-patch series to fix PR 82207
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle
> signaling NaNs. This part fixes the library code implementing IEEE_CLASS, by
> using the i
Hi,
This is the first part of a three-patch series to fix PR 82207
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle
signaling NaNs. This part fixes the library code implementing IEEE_CLASS, by
using the issignaling macro (from TS 18661-1:2014) to check whether a NaN
13 matches
Mail list logo
