This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: your change to tree-sra.c


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]