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.
Requiring explicit zeros is just a way to take up memory. We clearly wouldn't want to do it for big arrays, and I think we might as well treat vectors the same way, since we already need logic to handle the implicit zeros in the back end for arrays and structures.
The counter-argument is that front ends should be explicit. However, explicit doesn't need to mean verbose; as long as we specify the semantics I give above, eliding the elements is still perfectly clear.
This is why PR 29091 is failing currently. output_constant assumes VECTOR_CST have the correct number of elements but the C front-end via digest_init creates a VECTOR_CST with only 2 elements.
Thus, I think that output_constant should be changed to add the additional zeros.
-- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
