https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
--- Comment #8 from Marc Glisse ---
With the modified hack below, the testsuite passes, except:
gcc.dg/tree-ssa/scev-[34].c those go from xfail to pass, that sounds good
g++.dg/tree-ssa/pr31146.C seems that the scan-tree-dump is too strict
c-c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
--- Comment #7 from Marc Glisse ---
I am testing the following hack, I hope there will be at least 1 failure in the
testsuite that will help me understand why it is wrong. It bootstraps and gives
accesses like MEM[(struct _Vector_impl *)v_4(D)]._
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
--- Comment #6 from Richard Biener ---
Note that we do it correctly even - forcing a TBAA type of just 'int' and thus
disabling path-based disambiguation.
So doing this won't help you, it just will generate larger trees:
void f(V&, V&) (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
--- Comment #5 from Richard Biener ---
Created attachment 34460
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34460&action=edit
patch
This is what I am talking about (I think it's wrong and instead we have
to remove the case completely)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
--- Comment #4 from Richard Biener ---
(In reply to Marc Glisse from comment #3)
> Actually there is no need for inlining.
>
> struct A { int i; };
> void f(struct A *a){ *&a->i=0; }
> void g(struct A *a){ int*p=&a->i;*p=0; }
>
> The main diffe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
--- Comment #3 from Marc Glisse ---
Actually there is no need for inlining.
struct A { int i; };
void f(struct A *a){ *&a->i=0; }
void g(struct A *a){ int*p=&a->i;*p=0; }
The main difference seems to be that the first one gets through fold-cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> It's indeed that GCC only sees int accesses based on w and v and thus has to
> consider they might alias.
>
> TBAA cannot be strengthened easily here because the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
--- Comment #1 from Richard Biener ---
It's indeed that GCC only sees int accesses based on w and v and thus has to
consider they might alias.
Maybe it's time to try that "trick" with the same clobbering value...
TBAA cannot be strengthened eas
