C++ PATHC: PR5571

Richard Henderson rth@redhat.com
Fri Apr 12 14:14:00 GMT 2002


On Fri, Apr 12, 2002 at 01:31:50PM -0700, Mark Mitchell wrote:
> 2. Later, we complete the type.  Then, we reset the RTL for the MEM to
>    reflect the new DECL_MODE.  We accomplish this by calling make_rtl
>    again for the DECL, which triggers this code:
> 
>       /* If the old RTL had the wrong mode, fix the mode.  */
>       if (GET_MODE (DECL_RTL (decl)) != DECL_MODE (decl))
> 	SET_DECL_RTL (decl, adjust_address_nv (DECL_RTL (decl),
> 					       DECL_MODE (decl), 0));
> 
>    Unfortunately, that doesn't update MEM_ALIGN.

Yep, this is a problem; for performance if nothing else.

>    /* If OP0 is not aligned as least as much as the type requires, we
>       need to make a temporary, copy OP0 to it, and take the address of
>       the temporary.  We want to use the alignment of the type, not of
>       the operand.  Note that this is incorrect for FUNCTION_TYPE, but
>       the test for BLKmode means that can't happen.  The test for
>       BLKmode is because we never make mis-aligned MEMs with
>       non-BLKmode. */
> 
>    This seems semi-bogus in that surreptitiously making copies of
>    things right before you take their address seems likely to me to
>    be indicative of bad RTL/tree at that point, rather than anything
>    else.

I'd probably agree.  I think this is in here to handle Ada stuff
(of which I know aught).  It's also probably a mistake to model
this with the bare concept of ADDRESS_REF because it does lead
to problems like this.

> Here's the patch that I'm testing.  Richards, does this look reasonable
> to you?

Looks good to me.


r~



More information about the Gcc-patches mailing list