https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #11 from Martin Jambor ---
Author: jamborm
Date: Mon Mar 18 11:31:52 2019
New Revision: 269762
URL: https://gcc.gnu.org/viewcvs?rev=269762=gcc=rev
Log:
Add forgotten requeing in propagate_subaccesses_across_link
2019-03-18 Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #10 from Martin Jambor ---
Author: jamborm
Date: Mon Mar 18 11:28:01 2019
New Revision: 269761
URL: https://gcc.gnu.org/viewcvs?rev=269761=gcc=rev
Log:
Add forgotten requeing in propagate_subaccesses_across_link
2019-03-18 Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #9 from Martin Jambor ---
I have proposed the patch on the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00708.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #8 from Martin Jambor ---
Created attachment 45964
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45964=edit
x86_64 testcase
It took me four or five evenings and is quite fragile, but finally I have an
x86_64-linux testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #7 from Martin Jambor ---
Right, I must have been looking at output of a patched compiler. Anyway, I
believe I tracked it down to a bug in how SRA propagates write flag (since
r247604). In one specific case, an access structure is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #6 from Jakub Jelinek ---
And in the *.sra dump, I really don't see any way how it could be two:
MEM[(struct &) clique 22 base 1] ={v} {CLOBBER};
...
n1D.7146 ={v} {CLOBBER};
...
MEM[(struct &) clique 27 base 1] ={v}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #5 from Jakub Jelinek ---
You mean -fno-strict-aliasing? I guess many options change the behavior that
it doesn't trigger anymore.
In the #c3 dump, I really don't see how aliasing could matter though, all are
MEM_REFs with addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #4 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #3)
> ...But in the sra pass dump that possibility is gone:
I am still double checking because it is easy to make a mistake but I
have seen a (potential) path in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #3 from Jakub Jelinek ---
The gimple dumps aren't exactly readable with so many different tuple/type etc.
types, where it is unclear what exact offset is something being stored at.
That said, in cplxlower1 I still see a possibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #2 from Jakub Jelinek ---
When get_tail is esra optimized the old way, main is:
int n1$tail$head$payload;
struct type D.9885;
struct tuple D.9880;
struct type D.9879;
struct type D.9878;
struct type D.9875;
[local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
13 matches
Mail list logo
