fix expansion of addr_expr

Richard Kenner
Mon Aug 30 19:25:00 GMT 2004

    In testing my &a.b non-expansion patch with c++, I found several 
    cases in the c++ testsuite for which expand_expr would produce
    completely incorrect results.

    I believe this to be primarily due to the block that tries to be
    too smart and copy the object to a new stack slot and return the
    address of the stack slot.  To my mind, this is insane.

I'm not sure how you could run into problems with this code in C++,
as it should never be triggered.  And if it were triggered, then
it would be needed.

    I know that this is intended to support Ada records with packed

Sort of.  The issue is that you might be taking the address of something
that's not on the proper alignment boundary for its type.

    I think the Ada front end is going to have to handle this
    in the gimplifier, introducing the new temporary there rather than
    in the rtl expander.

I've actually be thinking in this direction for a while since doing it
at a sufficiently-high level (higher than the gimplifier) will get
rid of some really annoying issues that have been plauging this code
for quite a while.

What I'm not sure about is whether it's possible to get as accurate
information about the alignment that'll be in MEM_ALIGN when doing things
at tree level.

+    case REALPART_EXPR:
+      /* The real part of the complex number is always first, therefore
+	 the address is the same as the address of the parent object.  */
+      offset = 0;
+      bitpos = 0;
+      inner = TREE_OPERAND (exp, 0);
+      break;
+    case IMAGPART_EXPR:
+      /* The imaginary part of the complex number is always second.
+	 The expresion is therefore always offset by the size of the
+	 scalar type.  */
+      offset = 0;
+      bitpos = GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (exp)));
+      inner = TREE_OPERAND (exp, 0);
+      break;

Why not just add these to get_inner_reference and handled_component_p?
That'll simplify *a lot* of code.  It's been on my list to do this, but
I've been neck-deep in fixing bugs for too long ...

More information about the Gcc-patches mailing list