https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #22 from Jakub Jelinek ---
What we could do there is remove the first of those two splitters, remove the
&& !dead_or_set_p (insn, operands[1])
test from the second, and add peephole2 that would transform
(set (access part 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #21 from Andreas Krebbel ---
(In reply to Jakub Jelinek from comment #17)
> (In reply to Andreas Krebbel from comment #16)
> > I'll commit a patch which just removes the splitter for now. I'll try to
> > come up with a nicer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #20 from Andreas Krebbel ---
Author: krebbel
Date: Tue Feb 5 17:19:26 2019
New Revision: 268552
URL: https://gcc.gnu.org/viewcvs?rev=268552=gcc=rev
Log:
S/390: Remove load and test fp splitter
gcc/ChangeLog:
2019-02-05 Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #19 from Andreas Krebbel ---
Author: krebbel
Date: Tue Feb 5 17:17:00 2019
New Revision: 268551
URL: https://gcc.gnu.org/viewcvs?rev=268551=gcc=rev
Log:
S/390: Remove load and test fp splitter
gcc/ChangeLog:
2019-02-05 Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #18 from Andreas Krebbel ---
Author: krebbel
Date: Tue Feb 5 17:14:11 2019
New Revision: 268550
URL: https://gcc.gnu.org/viewcvs?rev=268550=gcc=rev
Log:
S/390: Remove load and test fp splitter
gcc/ChangeLog:
2019-02-05 Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #17 from Jakub Jelinek ---
(In reply to Andreas Krebbel from comment #16)
> I'll commit a patch which just removes the splitter for now. I'll try to
> come up with a nicer testcase.
All 3 s390 splitters that do this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #16 from Andreas Krebbel ---
I'll commit a patch which just removes the splitter for now. I'll try to come
up with a nicer testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #15 from Jakub Jelinek ---
(In reply to Andreas Krebbel from comment #14)
> (In reply to Jakub Jelinek from comment #11)
> > ... Can't what you are doing in the splitters be done in
> > define_peephole2 instead?
>
> Not that easy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #14 from Andreas Krebbel ---
(In reply to Jakub Jelinek from comment #11)
> ... Can't what you are doing in the splitters be done in
> define_peephole2 instead?
Not that easy unfortunately. peephole2 will run after reload. So the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #13 from Eric Botcazou ---
> Segher on IRC says that removing REG_DEAD notes that aren't valid is the
> right thing, so paging others what they think.
Definitely not, passes are not required to maintain REG_DEAD/REG_UNUSED notes,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #11 from Jakub Jelinek ---
So, to me this looks like a backend bug, using dead_or_set_p in a splitter when
the split passes don't really compute the note problem. Seems s390 is the only
backend that does this, other backends use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #10 from Jakub Jelinek ---
I admit I have just a vague recollection of this, but I thought since df has
been added, usually if a pass wants REG_DEAD notes, it needs to
df_note_add_problem () and df_analyze should rebuild the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #9 from Andreas Krebbel ---
Created attachment 45588
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45588=edit
experimental patch
That patch appears to fix the problem for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #8 from Andreas Krebbel ---
The r265193 patch was found via reghunt. However, it just reveals an underlying
issue.
The problem can also be seen with mainline.
The miscompile happens in the following loop:
do 110 j = 1, n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #7 from Andreas Krebbel ---
gfortran -O3 -march=zEC12 -funroll-loops -fpie qrsolv-reduc.f -c
gcc qrsolv-caller.c -c
gcc qrsolv-caller.o qrsolv-reduc.o -o t
r265191
./t
1.359429
r265193
./t
0.00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #6 from Andreas Krebbel ---
Created attachment 45587
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45587=edit
A C wrapper to call the qrsolv function in the fortran snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #5 from Andreas Krebbel ---
Created attachment 45586
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45586=edit
qrsolv-reduc.f the miscompiled fortran file autoreduced from scipy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
Andreas Krebbel changed:
What|Removed |Added
Status|WAITING |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #3 from Andreas Krebbel ---
I've tried building scipy 1.1.0 from github on a Fedora installation. The build
already uses -funroll-loops. But I couldn't reproduce the problem with the
resulting binary.
gcc version 8.0.1 20180324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.3
--- Comment #1 from Richard Biener
24 matches
Mail list logo
