This is the mail archive of the gcc-patches@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]

Re: C++ PATCH: PR 16405


Eric Botcazou wrote:
The gimplifier could not see through the INDIRECT_REF/ADDR_EXPR
combination to find the underlying TARGET_EXPR, and so generate a
temporary for it.  One approach would be to change the front end not
to adjust things to elide those nodes, but the same kind of thing can
occur in user code.  So, I made the gimplifier smarter.


This is a bit worrisome. We just re-enabled the Ada compiler on STRICT_ALIGNMENT platforms and bypassing ADDR_EXPRs without care is dangerous there.

If an ADDR_EXPR applied to an expression with type T has a type different from pointer-to-T or reference-to-T, I believe that the front end is broken.


However, I was concerned as I was falling asleep last night about the possibility that their might be alignment differences introduced by the casts, i.e., that pointer-to-T might be cast to pointer-to-unaligned-T before the dereference. But, the existence of the ADDR_EXPR means that some actual object is being examined, and it can never be wrong to use the underlying object -- the alignment of that object is more accurate that whatever might be implied by a pointer type introduced along the way.

I think this kind of changes should be tested on a STRICT_ALIGNMENT platform.

I'll see about an IA64 HP-UX test run, but I'm not sure what shape that port is in at the moment.


--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304


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