http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
--- Comment #8 from rakdver at kam dot mff.cuni.cz 2011-11-03 08:06:52 UTC ---
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
> >
> > --- Comment #6 from Yuehai Du 2011-11-03
> > 06:24:58 UTC ---
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
--- Comment #17 from rakdver at kam dot mff.cuni.cz 2011-05-17 20:18:39 UTC ---
> This is not really heuristic -- it prevents compiler from generating code in
> ivopt that violates the aliasing assumption.
no, it does not. For exampl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
--- Comment #15 from rakdver at kam dot mff.cuni.cz 2011-05-17 19:26:18 UTC ---
Hi,
> The following patch fixes the problem. Is it ok?
as a heuristic, this probably makes sense. Still, it does
not fix the problem, just masks it and makes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
--- Comment #11 from rakdver at kam dot mff.cuni.cz 2011-04-21 13:34:29 UTC ---
> > > I am somewhat sympathetic to treating indirect (TARGET_)MEM_REFs as
> > > opaque,
> > > only looking at the final pointer that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
--- Comment #9 from rakdver at kam dot mff.cuni.cz 2011-04-21 12:56:20 UTC ---
> ivtmp.25_24 = (long unsigned int) &array;
> array.26_26 = (long unsigned int) &array;
> D.2769_27 = array.26_26 + 0x0fff0;
&g
