http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #21 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-26 14:36:02 UTC --- (In reply to comment #20) > On Fri, 26 Nov 2010, Joost.VandeVondele at pci dot uzh.ch wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 > > > > --- Comment #19 from Joost VandeVondele <Joost.VandeVondele at pci dot > > uzh.ch> 2010-11-26 13:39:00 UTC --- > > Tobias, thanks for the clean explanation. I overlooked that the target of a > > pointer has that target attribute (seems logical!). > > > > Richard, I tried to get to a testcase for which the ME generates wrong code, > > but somehow things are always 'right'. I was expecting this to fail (-O3 > > -fno-inline), since the ME should not now that X aliases with V1%D: > > > > MODULE M1 > > IMPLICIT NONE > > TYPE T1 > > REAL, DIMENSION(:), ALLOCATABLE :: D > > END TYPE T1 > > CONTAINS > > SUBROUTINE S1(V1) > > TYPE(T1), POINTER :: V1 > > We can't exploit restrict information for pointers, it would need to > be a var of type t1 with target attribute - but even then the double > indirection (v1 passed by reference, embedded array desc points to > data) prevents us from exploiting restrict info. > > So we might be safe for now (apart from the related ICE seen with lto). Actually we _can_ see the restrict, but only with -fipa-pta which then also sees the pointer association (even with -fno-inline) which then makes the alias visible again (so we ignore restrict, maybe by pure luck of course): D.1625_4 = *v1_2(D); # PT = nonlocal unit-escaped null { D.1644 D.1645 } (restr) D.1626_5 = D.1625_4->d.data; # PT = nonlocal unit-escaped null { D.1644 D.1645 } (restr) D.1630_10 = x.data; wonders of propagation ;)
