[Bug target/68934] [ARM] using simd types should be rejected if not fpu=neon
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
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
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.