GCC Bugzilla Bug 18583

If you try to have a constant array of vectors on gcc-3.4.3 you you may get
parse errors when they shouldn't.
All seems related to the vector definition and where you place the const attribute.
If you define each array element constant and vector is defined as __vector ->
__attribute__((altivec(__vector))), you may get a parse error; if vector is
defined as __attribute__((vector_size(16))) all works.

If isn't a parser bug, is a documentation issue.

please look at the testcase for further details

Created an attachment (id=7573) [edit]
testcase

Confirmed.
The problem is:
<nop_expr 0x40f6aac8
    type <vector_type 0x40ddbd24 __vector signed short
        type <integer_type 0x40dcc89c HI
            size <integer_cst 0x40dc9280 constant 16>
            unit size <integer_cst 0x40dc9360 constant 2>
            align 16 symtab 0 alias set -1 precision 16 min <integer_cst 0x40dc9680 -32768> max 
<integer_cst 0x40dc96a0 32767>
            pointer_to_this <pointer_type 0x40ddb15c>>
        V8HI
        size <integer_cst 0x40dc97a0 constant 128>
        unit size <integer_cst 0x40dc99c0 constant 16>
        align 128 symtab 0 alias set -1>
    constant
    arg 0 <vector_cst 0x40f419c0
        type <vector_type 0x40f68570 __vector signed short type <integer_type 0x40dcc89c>
            readonly V8HI size <integer_cst 0x40dc97a0 128> unit size <integer_cst 0x40dc99c0 16>
            align 128 symtab 0 alias set -1
            pointer_to_this <pointer_type 0x40f6889c>>
        constant
        elt0:  <integer_cst 0x40ddde40 constant 4095>
        elt1:  <integer_cst 0x40dddea0 constant 5681>
        elt2:  <integer_cst 0x40dddf00 constant 5351>
        elt3:  <integer_cst 0x40dddf60 constant 4816>
        elt4:  <integer_cst 0x40dddfc0 constant 4095>
        elt5:  <integer_cst 0x40f6b020 constant 4816>
        elt6:  <integer_cst 0x40f6b080 constant 5351>
        elt7:  <integer_cst 0x40f6b0e0 constant 5681>>>

Note the NOP_EXPR and how the vector types are located at different memory location.

A regression hunt shows that I broke this on the 3.4 branch with

  http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg01183.html

I submitted a fix to mainline a few months later to fix the problem; I'll
backport that to the 3.4 branch next week.

I'm still looking at this.  My earlier comment about having fixed it on
mainline was wrong; I thought it was a problem in altivec.h, but it's in
the compiler itself and this problem never showed up on mainline.

My debugging sessions for this got bogged down, but I ran into a mainline fix
for this problem while investigating something else:

  http://gcc.gnu.org/ml/gcc-cvs/2004-05/msg00133.html

I'm testing a backport of that fix to the 3.4 branch and hope to submit it
later today or tomorrow.  Besides fixing the submitter's problem, the patch
also fixes a problem with DWARF2 debug information for vector types that a
neighboring gdb developer discovered yesterday.

I forgot to add the PR information to the ChangeLog entry at first, but this
is fixed in 3.4.5 by http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00274.html.

Fixed.