https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #20 from Richard Biener ---
Created attachment 47216
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47216=edit
asm diff
-O2 -mfma -mtune=znver2 -fdbg-cnt=ivopts_loop:66:67 -fno-schedule-insns
-mno-stv -fno-tree-slsr
assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #19 from Richard Biener ---
(In reply to Alexander Monakov from comment #17)
> (In reply to Richard Biener from comment #16)
> > interestingly 66:66 and 67:67 generate exactly the same code and
> > 66:67 add a single loop. That's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
Richard Biener changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #16 from Richard Biener ---
(In reply to Richard Biener from comment #12)
> Trying to bisect with IVOPTs debug-counter.
>
> 65:69 FAIL
> 65:66 OK
> 67:69 OK
>
> *sigh*
Back to this (ivopts_loop counter soon to be checked in).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #15 from rguenther at suse dot de ---
On Fri, 8 Nov 2019, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
>
> --- Comment #14 from Martin Liška ---
> >
> > more complex "ranges" for debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #14 from Martin Liška ---
>
> more complex "ranges" for debug counters appreciated,
+1
> -fdbg-cnt=foo:{5-6,9,1-10} or some sorts of that (lists of ranges / values).
> I'm definitely missing a all-but-N as well. ~6 and ~6-9 maybe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #13 from Richard Biener ---
(In reply to Richard Biener from comment #12)
> more complex "ranges" for debug counters appreciated,
> -fdbg-cnt=foo:{5-6,9,1-10} or some sorts of that (lists of ranges / values).
> I'm definitely missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #12 from Richard Biener ---
Tackling from the tuning side, -mfma -mtune=znver2 miscompares,
-mtune=generic doesn't [checkme].
Using -mfma -mtune=generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #11 from Richard Biener ---
Created attachment 47194
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47194=edit
diff for results.f
So with the attached diff for results.f and a simple
> cat t.f
subroutine foobar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #10 from Richard Biener ---
Adding
!GCC$ unroll 0
before line 848 or adding a call to an empty function after the loop nest
(after 857) fixes the miscompare. GIMPLE level difference with the function
call
is one missed invariant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #9 from Richard Biener ---
So unrolling the inner loop of
846 if(iperturb.ge.2) then
do m3=1,3
do m4=1,3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #8 from Richard Biener ---
Created attachment 47188
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47188=edit
debugging patch
So we're unrolling innermost loops of
do m1=1,nope
do m3=1,3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #7 from Martin Liška ---
@Richi: May I please remind you this issue?
Is the debugging patching helping to isolate the issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #6 from Martin Liška ---
Created attachment 47132
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47132=edit
Debugging patch
With the attached patch (and r276645) run succeeds.
If you change s/counter < 2/counter < 1/ then it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #5 from Martin Liška ---
So the problematic file is results.f. If I use code from the previous revision
for the file, there is no miscomparison.
Now I'll bisect which loop is causing the miscompilation. Optimized dumps
differ quite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #4 from Richard Biener ---
Though with -O2 we should produce "exact" FP math (and vectorization is off).
So maybe we hit a latent issue after the extra unrolling from the rev. in
question.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #2 from Martin Liška ---
Apparently quite some files are different with the revision:
CalculiX.o
beamsections.o
cycsymmods.o
e_c3d.o
e_c3d_rhs.o
e_c3d_th.o
el.o
envtemp.o
extrapolate.o
gen3delem.o
incplas.o
linel.o
mastruct.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
20 matches
Mail list logo
