[Bug c++/13146] inheritance for nonoverlapping_component_refs_p

[rguenth at gcc dot gnu dot org]

--- 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 try to
disambiguate based on struct contain-ness of the types of that accesses.

Maybe I'll have a look, as this sounds uselful in general.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-01-15 20:43:32 |2008-03-15 12:40:51
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13146

[Bug c++/13146] inheritance for nonoverlapping_component_refs_p

[rguenth at gcc dot gnu dot org]

--- 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

[Bug c++/13146] inheritance for nonoverlapping_component_refs_p

[dann at godzilla dot ics dot uci dot edu]

--- 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)
{
:
  s1->f1 = 0;
  s3->f3 = 0;
  s1->f1 = s1->f1 + 1;
  s3->f3 = s3->f3 + 1;
  s1->f1 = s1->f1 + 1;
  s3->f3 = s3->f3 + 1;
  if (s1->f1 != 2)
goto ;
  else
goto ;
:
  link_error () [tail call];
:
  return;
}
void foo(first*, second*) (s1, s2)
{
:
  s1->f1 = 0;
  s2->f2 = 0;
  s1->f1 = s1->f1 + 1;
  s2->f2 = s2->f2 + 1;
  s1->f1 = s1->f1 + 1;
  s2->f2 = s2->f2 + 1;
  if (s1->f1 != 2)
goto ;
  else
goto ;
:
  link_error () [tail call];
:
  return;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13146

[Bug c++/13146] inheritance for nonoverlapping_component_refs_p

[rguenth at gcc dot gnu dot org]

--- 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 gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13146

[Bug c++/13146] inheritance for nonoverlapping_component_refs_p

[pinskia at gcc dot gnu dot org]

--- 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

   Last reconfirmed|2004-10-03 16:32:42 |2005-01-27 02:17:43
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13146

[Bug c++/13146] inheritance for nonoverlapping_component_refs_p

[dnovillo at gcc dot gnu dot org]

--- 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 memory tag.

Without context sensitive information, we cannot tell where these arguments are
really pointing to, so we have to base the analysis exclusively on types. 
Notice, however, that the analysis DTRT when the calls are inlined.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13146