[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 --- Comment #1 from Thomas Koenig --- Created attachment 54617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54617&action=edit rnflow.f90
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 --- Comment #2 from Thomas Koenig --- Created attachment 54618 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54618&action=edit Header file needed for compilation
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 --- Comment #3 from Thomas Koenig --- Created attachment 54619 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54619&action=edit Compressed input file
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 Thomas Koenig changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |13.0 --- Comment #4 from Thomas Koenig --- As also confirmed by Paul Thomas, the program works fine at -O2.
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 --- Comment #5 from Thomas Koenig --- Might be invalid code, see https://gcc.gnu.org/pipermail/fortran/2023-March/059062.html That appears to be a problem with widely used old-style linear congruential random number generators, which expect overflow to just silently truncate. Looking at the test case with nagfor -C=all shows the problem: 0: 0: 0.000 -> Read sequence 0: 0: 0.150 -> extract extrema 0: 0: 0.159 -> Generate raw transitions counts 0: 0: 0.183 -> Compute Markov matrix 0: 0: 0.184 -> Calculate theoretical rainflow 0: 0:43.286 -> Simulate random markov sequences Runtime Error: rnflow.f90, line 902: INTEGER(int32) overflow for 843314861 * 1993 The issue with the patch is that it is also illegal Fortran, because the assignment outside the value range of a default integer is also illegal. Again, nagfor catches this: 0: 0: 0.000 -> Read sequence 0: 0: 0.140 -> extract extrema 0: 0: 0.150 -> Generate raw transitions counts 0: 0: 0.175 -> Compute Markov matrix 0: 0: 0.175 -> Calculate theoretical rainflow 0: 0:44.032 -> Simulate random markov sequences Runtime Error: rnflow.f90, line 905: Overflow converting 1681180334666 to INTEGER(int32) So, what to do? I think we need to mention this in the release notes, and also a workaround which gives the same result. If there is a flag which suppresses whatever this does, we could also set this with -std=legacy (and also mention this in the relase notes).
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- jmul is used just once, so I wonder if the easiest solution wouldn't be to make jmul PARAMETER kind=8. Anyway, does -fwrapv work around it too?
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 Thomas Koenig changed: What|Removed |Added Known to work||12.2.0 --- Comment #7 from Thomas Koenig --- I've just checked 12.2.0, and the code does not hang there. (In reply to Jakub Jelinek from comment #6) > jmul is used just once, so I wonder if the easiest solution wouldn't be to > make jmul > PARAMETER kind=8. We can change the benchmark source, but we cannot change the existing code base using the same idiom out there :-| > Anyway, does -fwrapv work around it too? Yes, -frwapv works. We could just include that in -std=legacy (it really is used for legacy code) and mention it in the release notes, then. How does that sound?
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | --- Comment #8 from Jakub Jelinek --- BTW, rnflow without the tweaks started to hang with r13-5103-g7c9f20fcfdc2d8453df8
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #9 from Richard Biener --- duplicate *** This bug has been marked as a duplicate of bug 71231 ***
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 Paul Thomas changed: What|Removed |Added Resolution|DUPLICATE |INVALID CC||pault at gcc dot gnu.org Known to work|12.2.0 | Keywords||needs-bisection --- Comment #10 from Paul Thomas --- See comment at rnflow.f90:899 - As Richard Biener suggested to the list -fdefault-integer-8 fixes the problem but breaks tfft2 of the polyhedron suite. Better is: integer(8), parameter :: jmul = 843314861 ! multiplicateur integer(8), parameter :: jadd = 453816693 ! constante additive Cheers Paul
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 Paul Thomas changed: What|Removed |Added Keywords||needs-bisection --- Comment #11 from Paul Thomas --- As a final remark from me, rnflow is not hanging but, rather, execution time becomes quadratic in ndonm (in rnprfm.h) and is already tiresomely long at a value of 40, compared with the default 101. Cheers Paul
