Missing elements in VECTOR_CST

Mark Mitchell mark@codesourcery.com
Fri Sep 29 00:55:00 GMT 2006


Hans-Peter Nilsson wrote:
> On Mon, 18 Sep 2006, Mark Mitchell wrote:
> 
>> Andrew Pinski wrote:
>>> The documention on VECTOR_CST is not clear if we can have missing
>>> elements in that the remaining elements are zero.  Right we produce such
>>> VECTOR_CST for things like:
>>> #define vector __attribute__((vector_size(16) ))
>>> vector int a = {1, 2};
>>>
>>> But is that valid?  We currently produce a VECTOR_CST with just two
>>> elements instead of 4.  Should we always have the same number of
>>> elements in a VECTOR_CST as there are elements in the vector type?
>> I think it is reasonable for front-ends to elide initializers and to
>> follow the usual C semantics that elided initializers are (a) zero, if
>> the constant is appearing as an initializer for static storage, or (b)
>> unspecified, "random" values elsewhere.
> 
> Maybe you didn't mean what I read, but it's not just "for static
> storage".  By my reading (of the May 6, 2005 ISO/IEC 9899:TC2
> for reference), all items in arrays and named structure members
> not mentioned in the initializer should be 0-initialized (the
> "all subobjects that are not initialized explicitly shall be
> initialized implicitly the same as objects that have static
> storage duration" part in 6.7.8:19).

No, I meant what I said, and you read it correctly.

I think that front ends should be allowed to omits zeros for 
initializers for variables with static storage duration, but not other 
initializers, independent of what C99 says.  The reason is that this 
matches traditional linker semantics; uninitialized variables with 
static storage duration are zeroed.  Also, if we did allow front ends to 
implicitly zero local variables, we would have to provide a way to allow 
them to override that and just say "uninitialized", to avoid pessimizing 
the code.  This consideration doesn't apply to variables with static 
storage duration.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713



More information about the Gcc mailing list