https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674
--- Comment #12 from chrbr at gcc dot gnu.org --- (In reply to ktkachov from comment #8) > (In reply to chrbr from comment #7) > > I was suggesting in #68934 to make this code invalid and report an error. > > Since SIMD types should not be used for declarations in NOSIMD context. But > > I don't have a strong position about this. We might make this code work by > > repairing the DECL_MODE depending on the usage context, but certainly less > > practical than handle the error. > > > > Other opinions ? > > > > thanks > > I agree about considering this code invalid. > In the context where the variables are being declared there is no SIMD, so > they don't really have a meaning. In the testcase if we wrap the > declarations in a pargma like so: > #pragma GCC push_options > #pragma GCC target ("+simd") > int8x8_t a, b; > int16x8_t e; > #pragma GCC pop_options > > then we don't ICE. > I suspect repairing DECL_MODE will be a messy affair. So unless you see a > clean/safe way of doing this I'd propose just somehow detecting this error > and throwing an error instead of an ICE. I changed my mind :-) : - The surrounding of global declaration by the #pragma is too heavy to be used. The compiler is able to derive the type from the attribute target when using it. - The compiler already handle this partially: see the comment in stor-layout: /* Vector types need to re-check the target flags each time we report the machine mode. We need to do this because attribute target can change the result of vector_mode_supported_p and have_regs_of_mode on a per-function basis. Thus the TYPE_MODE of a VECTOR_TYPE can change on a per-function basis. */ I'm testing a central fix in expand_expr. Will need to check on the other targets but it fixes the case it for arm and aarch64. patch attached for first feedback and early review.