[Bug target/68934] [ARM] using simd types should be rejected if not fpu=neon

[chrbr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68934

--- Comment #1 from chrbr at gcc dot gnu.org ---
run with cc1 -mfloat-abi=hard for a compiler configured with defaults

[Bug target/68934] [ARM] using simd types should be rejected if not fpu=neon

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68934

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Richard Earnshaw  ---
Realistically, this is never going to be feasible.  How would you expect the
compiler to distinguish between

#pragma GCC target ("fpu=neon")
typedef ... _some_simd_type;
typedef ... _some_nonsimd_type;

#pragma GCC target ("fpu=vfp")

_some_simd_type this_shouldnt_work;
_some_nonsimd_type this_should_work;

There's no practical way for the compiler to ever know which types should go
out of scope when the target attributes change.

Real code does not scope simd type definitions tightly enough to make this
feasible even if it were desirable.

[Bug target/68934] [ARM] using simd types should be rejected if not fpu=neon

[chrbr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68934

--- Comment #3 from chrbr at gcc dot gnu.org ---

> Real code does not scope simd type definitions tightly enough to make this
> feasible even if it were desirable.

there was an instance of this in Bug #68895. The second function ices while
using int8x8_t types while in vfp mode. So we should probably decide if the
code is legitimate or not (and close as invalid). And if it is how the RTL can
this bi-morphism.

The only solution I had in mind was to play with registered_builtin_types in
the lang hooks, but I agree it is not practical.