This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: your change to tree-sra.c
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 07 Jul 2004 11:19:55 -0400
- Subject: Re: your change to tree-sra.c
- Organization: Red Hat Canada
- References: <10407071455.AA05818@vlsi1.ultra.nyu.edu>
On Wed, 2004-07-07 at 10:55, Richard Kenner wrote:
> Why isn't it a valid initializer? It's not valid GIMPLE?
>
> For automatic variables, we *always* clear DECL_INITIAL.
>
> For static variables, the test is if initializer_constant_valid_p is
> true for DECL_INITIAL. If it is, then we can leave it set and the
> assembler/linker will take care of it.
>
> But if it *isn't* true, then we have to initialize it with code that's
> placed somewhere. There's no place to put such code in C, so it's
> not allowed in the language. But there is in Ada, the elaboration
> procedure, so it is allowed.
>
> The Ada code does the same thing that gimplify_decl_expr does: clears
> DECL_INITIAL and arranges for it to be initialized some other way.
>
> I don't think we should give 3 meanings to a binary value. DECL_INITIAL
> NULL -> it's not initialize. DECL_INITIAL non-NULL -> it is
> initialized. We use this in CCP.
>
> I don't follow. Are you talking about just the static case?
>
Yes.
> If the automatic case, you can't derive *any* info from DECL_INITIAL
> since it's always zero.
>
You just did, it's NULL, ergo it's uninitialized.
> But do you care what the value is? Should we define DECL_INITIAL for
> statics being ERROR_MARK as saying that it's actually initialized?
>
I care only if it's a GIMPLE constant. In SRA, we care that it be
GIMPLE code, so ERROR_MARK will not work. But I'm missing something, if
you have already expanded the initializer in the IL, why does it matter
that DECL_INITIAL is NULL?
Diego.