[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595
chrbr at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Fri Dec 18 15:58:00 GMT 2015
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.
More information about the Gcc-bugs
mailing list