http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
Steven Bosscher changed:
What|Removed |Added
Keywords||patch
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
Alan Modra changed:
What|Removed |Added
Target||powerpc-linux
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
--- Comment #5 from rguenther at suse dot de
2010-11-22 11:15:01 UTC ---
On Mon, 22 Nov 2010, amodra at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
>
> --- Comment #4 from Alan Modra 2010-11-22 10:47:24
> UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
--- Comment #4 from Alan Modra 2010-11-22 10:47:24
UTC ---
But within a loop gcc-4.2 looked quite reasonable too..
Don't we have a pass ordering problem if fwprop is to rewrite addresses? We
currently have cse1, fwprop1, loop passes, cse2, fwpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
Alan Modra changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever Confirmed|1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
--- Comment #1 from Alan Modra 2010-11-21 23:09:13
UTC ---
I believe this code size regression is due to the fix for #32698. Before that
change, gcc calculated the offset for accessing the array elements as
n*4
64+n*4
128+n*4
After, we get
n*4
