This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: MEM/u trouble
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Subject: Re: MEM/u trouble
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Wed, 14 Mar 2001 13:21:37 -0500
- Cc: gcc-patches at gcc dot gnu dot org
- References: <10103141813.AA28542@vlsi1.ultra.nyu.edu>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
On Wed, Mar 14, 2001 at 01:13:42PM -0500, Richard Kenner wrote:
> If (mem (addressof (reg))) is converted to (mem ()), then AFAIC the
> MEM flags are preserved.
>
> Yes, and that's the issue: since it will be a stack slot, those flags must
> correspond to that of the type with which the stack slot was allocated, so
> you can't safely change them.
But with (mem (addressof (reg))) the stack slot has not been allocated yet
and when it will, it will have the flag of the mem containing the addressof
(and the mem should be unique in the whole function).
>
> The m parameter of foo constructor is readonly (because of the const
> qualifier):
>
> <var_decl 0x401d5af8 m
> type <record_type 0x401cd138 K readonly needs-constructing
> readonly used SI file u.C line 4 size <integer_cst 0x401a2be0 32>
>
> Right. This is fine.
>
> <target_expr 0x401d44e0
> type <record_type 0x401cca90 K needs-constructing type_1 type_5 SI
>
> This looks wrong. Why isn't this the readonly variant of the type?
>
> Or am I misunderstanding something?
How could the temporary be readonly? The constructor constructs a
non-readonly object, the only problem is that when this object is assigned
into m, expand_expr decides to put them into the same rtl. The temporary may
be changed in its constructor any number of times the constructor wants, so
it cannot be readonly IMHO.
Jakub