https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #57 from Richard Biener ---
It might be not ideal but it seems unless somebody finds the time to analyze
the difference the "fix" did and thereby identifies the problem itself closing
the bug is the most efficient way of dealing with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #56 from Jürgen Reuter ---
What do we do now? We know the offending commit, and the commit that fixed (or
"fixed") it. Closing? Do we understand what happened here, so why it went wrong
and why it got fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #55 from Jürgen Reuter ---
Actually, according to my testing, the last commit where the gfortran produced
failing code,
ishttps://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c496d15954cdeab7f9039328f94a6f62cf893d5f
(Aldy Hernandez A single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #54 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #53)
> Additional comment: the commit which fixed/"fixed" this offending commit
> came between July 3 and July 10.
Wildly speculating, it would be this commit maybe,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #53 from Jürgen Reuter ---
Additional comment: the commit which fixed/"fixed" this offending commit came
between July 3 and July 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #52 from Jürgen Reuter ---
(In reply to Jakub Jelinek from comment #51)
> The easiest would be to bisect gcc in the suspected ranges, that way you'd
> know for sure which git commit introduced the problem and which
> fixed/"fixed" it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #51 from Jakub Jelinek ---
The easiest would be to bisect gcc in the suspected ranges, that way you'd know
for sure which git commit introduced the problem and which fixed/"fixed" it.
If it is about what the compiler emits, one doesn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #50 from Jürgen Reuter ---
How to proceed here? Since almost exactly a month the current gcc git master
doesn't show this problem anymore, from our CI I can deduce that the version on
July 3rd still failed, while the version on July
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #49 from Jürgen Reuter ---
(In reply to anlauf from comment #48)
> (In reply to anlauf from comment #47)
> > However, when I use -O2 together with an -march= flag, the code works.
> > I've tested -march=sandybridge, -march=haswell, -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #48 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #47)
> However, when I use -O2 together with an -march= flag, the code works.
> I've tested -march=sandybridge, -march=haswell, -march=skylake,
> -march=native.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #47 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #46)
> The issue goes away with -O0, with -O1 and with -O2 -fno-tree-vectorize.
> I might want to find the offending commit in the week of June 12-19 in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #46 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #45)
> Created attachment 55492 [details]
> Smaller stand-alone reproducer
>
> I will give more information in a comment, this contains 3 files and a
> Makefile.
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #45 from Jürgen Reuter ---
Created attachment 55492
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55492&action=edit
Smaller stand-alone reproducer
I will give more information in a comment, this contains 3 files and a
Makefil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #44 from Jürgen Reuter ---
(In reply to anlauf from comment #43)
> Mabye the fprem issue was a red herring from the beginning, pointing to a
> problem in a different place.
>
> I recompiled each module in a loop with -O0 until the F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #43 from anlauf at gcc dot gnu.org ---
Mabye the fprem issue was a red herring from the beginning, pointing to a
problem in a different place.
I recompiled each module in a loop with -O0 until the FPE went away.
instances_sub.f90 se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #42 from Jürgen Reuter ---
(In reply to Jakub Jelinek from comment #41)
>
> 0x04f5dc90 is pseudo NaN:
> Pseudo Not a Number. The sign bit is meaningless. The 8087 and 80287 treat
> this as a Signaling Not a Number. The 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #41 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #39)
> (In reply to anlauf from comment #36)
> > Breakpoint 2, rng_stream.rng_stream_s::mmm_mod (x1=330289839997,
> > x2=4294967087) at rng_stream_sub.f90:336
> > 336
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #40 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #38)
> At the moment unfortunately too busy to provide a smaller reproducer (which
> also still has a small dependency on a dynamic library),
I have just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #39 from Uroš Bizjak ---
(In reply to anlauf from comment #36)
> Breakpoint 2, rng_stream.rng_stream_s::mmm_mod (x1=330289839997,
> x2=4294967087) at rng_stream_sub.f90:336
> 336 res = mod (x1, x2)
> (gdb) info float
> R7:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #38 from Jürgen Reuter ---
At the moment unfortunately too busy to provide a smaller reproducer (which
also still has a small dependency on a dynamic library), but one more info:
inserting the explicit operations instead of the intri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #37 from anlauf at gcc dot gnu.org ---
After the FPE:
(gdb) info float
R7: Valid 0x401be51fb578 +480507567
R6: Valid 0x401be51fb578 +480507567
R5: Zero0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #36 from anlauf at gcc dot gnu.org ---
Breakpoint 2, rng_stream.rng_stream_s::mmm_mod (x1=330289839997, x2=4294967087)
at rng_stream_sub.f90:336
336 res = mod (x1, x2)
(gdb) info float
R7: Valid 0x401be51fb578 +480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #35 from Uroš Bizjak ---
(In reply to anlauf from comment #33)
> (In reply to Jakub Jelinek from comment #32)
> > Then maybe r13-6361-g8020c9c42349f51f75239b
> > is the commit that changed it?
> > Would be good to put a breakpoint at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #34 from anlauf at gcc dot gnu.org ---
A few more data points:
reverting r13-6361-g8020c9c42349f51f75239b on 13-branch fixes the issue:
no fprem generated, no FPE.
Adding -ffinite-math-only to the modified 13-branch restores the FPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #33 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #32)
> Then maybe r13-6361-g8020c9c42349f51f75239b
> is the commit that changed it?
> Would be good to put a breakpoint at that instruction and see in whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #31 from anlauf at gcc dot gnu.org ---
Looking at rng_stream_sub.o with objdump, I see fprem generated for 13 & 14,
but not for 12.
I haven't yet found an option to suppress its generation and fall back to
the behavior of 12-branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #30 from anlauf at gcc dot gnu.org ---
BTW: you can get a traceback on FP exceptions by adding to the linker options:
-ffpe-trap=zero,overflow,invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #29 from Jürgen Reuter ---
(In reply to anlauf from comment #28)
> Update: recompiling that file with 13-branch fails for me, too.
> Playing with the one-line patch for pr86277 makes no difference, fortunately.
>
> Compiling the fil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #28 from anlauf at gcc dot gnu.org ---
Update: recompiling that file with 13-branch fails for me, too.
Playing with the one-line patch for pr86277 makes no difference, fortunately.
Compiling the file with gfortran-12 seems to work ok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #27 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #26)
> It is included here:
> https://www.desy.de/~reuter/downloads/repro002.tar.xz
> I am working on a smaller example right now.
Good. I can reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #26 from Jürgen Reuter ---
(In reply to anlauf from comment #25)
> Unfortunately, there is no main.f90, which is needed to build whizard.
>
Indeed, sorry, cf. below
> The Makefile needs to be modified to take into account that pyt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #25 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #24)
> Here is a first reproducer without the need for OCaml, unfortunately a bit
> too big to be uploaded, here is the link:
> https://www.desy.de/~reuter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #24 from Jürgen Reuter ---
Here is a first reproducer without the need for OCaml, unfortunately a bit too
big to be uploaded, here is the link:
https://www.desy.de/~reuter/downloads/repro001.tar.xz
the tarball contains Fortran files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #23 from anlauf at gcc dot gnu.org ---
You could check the input arguments for validity, e.g. using ieee_is_finite
from the intrinsic ieee_arithmetic module.
use, intrinsic :: ieee_arithmetic, only: ieee_is_finite
...
if (.not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #22 from Jürgen Reuter ---
(In reply to anlauf from comment #21)
> I forgot to mention that you need to check that the location where a symptom
> is seen sometimes may not be the location of the cause.
Indeed, I think you are right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #21 from anlauf at gcc dot gnu.org ---
I forgot to mention that you need to check that the location where a symptom
is seen sometimes may not be the location of the cause.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #20 from anlauf at gcc dot gnu.org ---
If that doesn't help: there appear to be recent optimizations for divmod.
Try declaring a1, a2 as volatile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #19 from Jürgen Reuter ---
(In reply to anlauf from comment #18)
> (In reply to Jürgen Reuter from comment #17)
> > How would I set up such a bisection for the n git commits between June 12 to
> > June 19? Unfortunately, I cannot rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #18 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #17)
> How would I set up such a bisection for the n git commits between June 12 to
> June 19? Unfortunately, I cannot really get a small reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #17 from Jürgen Reuter ---
How would I set up such a bisection for the n git commits between June 12 to
June 19? Unfortunately, I cannot really get a small reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #16 from Jürgen Reuter ---
It seems that it is this function where the NaNs appear:
function mult_mod (a, b, c, m) result (v)
real(default), intent(in) :: a
real(default), intent(in) :: b
real(default), intent(in) :: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC|anlauf at gmx dot de |
--- Comment #15 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #14 from Jürgen Reuter ---
Did anybody manage to reproduce this?
Download https://whizard.hepforge.org/downloads/?f=whizard-3.1.2.tar.gz
You need OCaml as a prerequisite, though.
Then configure, make,
cd tests/functional_tests
make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #13 from Jürgen Reuter ---
I changed the component from fortran to tree-optimization, as the problematic
commit during that week was in that component. The only commit in the fortran
component turns out to be unproblematic.
46 matches
Mail list logo
