On Thu, 28 Sep 2006, Mark Mitchell wrote:

> 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.

I think we "read past each other".  I was just countering what
(I read as) your statement that for C semantics, only omitted
subobjects in initialiers of objects with *static storage* are
zero-initialized; i.e. that others are ok to be left undefined
by an implementation.

(Not to be mixed up with the interface between GCC front-ends,
back-end and linker.)

brgds, H-P

Reply via email to