[Bug tree-optimization/49279] [4.5/4.6/4.7 Regression] Optimization incorrectly presuming constant variable inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for x86_64 targets

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #13 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-06 08:07:59 UTC ---
(In reply to comment #12)
> (In reply to comment #10)
> > with tag coming from allocate_decl_uid ().  We would use these copies
> > as restrict tag sources using the specified UID.  Thus every inline
> > copy (and clone) would share them.
> 
> Assuming we don't CSE over it (in particular, the LHS of such a builtin with
> some non-restricted later pointers not based on it), perhaps it could work.
> I wouldn't expose it to users, because how would users ensure uniqueness of the
> tag over the whole CU?  __COUNTER__ or something similar?  That's going to lead
> to bugs...

Yeah, I suppose it's not trivial.  OTOH programs have to sort out global
symbol space as well, so ...

> The FEs should probably add that for user __restrict variable initializers too.

Yes.

One slight complication with the proposal arises when the restrict qualified
parameter is address-taken, you'd get

foo (int * restrict p)
{
  tem = p;
  tem = RESTRICT <tem, tag>;
  p = tem;
  bar (&p);
}

which would work for the purpose of making loads from p restrict, but the
load and the store above would not be identifiable as artificial (as opposed
to the RESTRICT statement), and thus may persist in the final code.

Not sure if we need to worry about this case though (similar issue
with address-taken pointers and __builtin_assume_aligned).  I'd just
add the RESTRICT casts for non-address-taken pointers.