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