This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595
- From: "chrbr at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 18 Dec 2015 15:58:15 +0000
- Subject: [Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595
- Auto-submitted: auto-generated
- References: <bug-68674-4 at http dot gcc dot gnu dot org/bugzilla/>
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.