This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug lto/55118] Missed forward propagation of addresses


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]