--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-15 12:28 ---
Ah, indeed. It was fixed by the patch for PR23094 that I had applied ;)
Maybe adjust this testcase to not be a dup of PR23094.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13146
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-03-15 12:40
---
the nonoverlapping_memrefs_p check can be simplified (consolidated) by using
the generic get_ref_base_and_extent code. The result of that can be adjusted
by MEM_OFFSET and only in case of an indirect base we may
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-03-14 20:30 ---
The testcase is fixed by the SCCVN alias-oracle patch. I don't see how
BINFOs should be needed here - if the MEM_REFs are still there the
disambiguation can happen based on the member offsets, no?
--
rguenth at
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2008-03-15
00:28 ---
(In reply to comment #7)
The testcase is fixed by the SCCVN alias-oracle patch.
Are you sure? I still see the problem (.final_cleanup dump):
void bar(first*, multi*) (s1, s3)
{
bb 2:
s1-f1 = 0;
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-27
02:17 ---
Also it sounds like the scheduler still needs support from the rtl aliasing
mechanism is helped by more
information.
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-10-28 20:23
---
The tree alias analyzer depends on the type information given to it by alias.c.
In this case, the types of the pointers passed to the two routines have
conflicting alias sets, so they are given the same
