This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/55118] Missed forward propagation of addresses
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 29 Oct 2012 15:37:53 +0000
- Subject: [Bug lto/55118] Missed forward propagation of addresses
- Auto-submitted: auto-generated
- References: <bug-55118-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55118
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2012-10-29
Blocks|54776 |
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-29 15:37:53 UTC ---
I will investigate what we can do. I ripped out the old propagation stuff
because we miscompiled things.
The first case cannot be simplified without "lowering" &expr_1(D)->left_m
to expr_1(D) which will cause issues with __builtin_object_size handling.
The 2nd case is because we cannot express dereferencing _5 with TBAA
type Element_t[2] when trying to "inline-expand" it's address. That is,
MEM[(const Element_t[2] &) &MEM[(const struct Domain
*)&D.660972].D.123571.domain_m[i_4].D.118841 ];
does not simplify because of the variable-offset address. The only case
we can simplify it is if D.118841 has type Element_t[2] but this is usually
not the case as far as I remember.
I'll still look into the details.