Bug 96990

Summary: Regression in aarch64 struct vector member initialization
Product: gcc Reporter: Yichao Yu <yyc1992>
Component: targetAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED DUPLICATE    
Severity: normal CC: rsandifo
Priority: P3 Keywords: rejects-valid
Version: 10.2.0   
Target Milestone: ---   
Host: Target: aarch64
Build: Known to work:
Known to fail: Last reconfirmed:

Description Yichao Yu 2020-09-09 02:41:11 UTC
The following code used to work on gcc 9.3 but stops working with 10.2 with an error

```
a.c: In function ‘test_aa64_vec_2’:
a.c:19:24: error: incompatible types when initializing type ‘signed char’ using type ‘int8x8_t’
   19 |     struct_aa64_3 x = {v1 + v1, v2 - v2};
      |                        ^~
a.c:19:33: error: incompatible types when initializing type ‘signed char’ using type ‘float32x2_t’
   19 |     struct_aa64_3 x = {v1 + v1, v2 - v2};
      |                                 ^~
```

Any one of the "working" version or compiling with c++ works.
From the error message it seems that GCC correctly inferred the return type of the `v1 + v1` or `v2 - v2` but instead got confused about the field type. Reverssing the order of `v1` and `v2` in the struct causes the error to change to `float` instead of `signed char` so it seems that gcc thinks the code is trying to initialize the first vector member (with element type of `signed char` or `float` instead). I thought such initialization should have an additional `{}` instead... Given that explicit casting or compiling in c++ mode helps I think this is a bug...

```
#include <arm_neon.h>

typedef struct {
    int8x8_t v1;
    float32x2_t v2;
} struct_aa64_3;

struct_aa64_3 test_aa64_vec_2(int8x8_t v1, float32x2_t v2)
{
    // works
    /* int8x8_t vi8 = v1 + v1; */
    /* float32x2_t vf = v2 - v2; */
    /* struct_aa64_3 x = {vi8, vf}; */

    // works
    /* struct_aa64_3 x = {(int8x8_t)(v1 + v1), (float32x2_t)(v2 - v2)}; */

    // not
    struct_aa64_3 x = {v1 + v1, v2 - v2};
    return x;
}
```
Comment 1 Drea Pinski 2020-09-09 06:29:10 UTC
I think it was only broken for GCC 10.2.0 and has already been fixed.
Comment 2 Richard Sandiford 2020-09-10 17:21:17 UTC
Yeah, this was fixed by https://gcc.gnu.org/g:7d599ad27b9bcf5165f87710f1abc64bbabd06ae, which will be included in GCC 10.3.

Sorry for the inconvenience.

(PR96377 is still open because there's a related unfixed bug on trunk, but the current GCC 10 branch is unaffected.)

*** This bug has been marked as a duplicate of bug 96377 ***