https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120718
Alex Coplan <acoplan at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[15/16 Regression] ICE |ICE (unrecognizable insn)
|(unrecognizable insn) with |with SVE intrinsics and C++
|SVE intrinsics and C++ |class
|class since |
|r15-4235-gbcccc3221b838e |
--- Comment #3 from Alex Coplan <acoplan at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Alex Coplan from comment #1)
> > Seems to have started with
> > r15-4235-gbcccc3221b838ee7ae7848e7194603acb18294b3, FWIW.
>
>
> My bet you could use vector(2) int to hit the issue before this.
Yes, indeed, the following is a C testcase which does that and fails back to
the introduction of SVE in GCC 10:
#include <arm_sve.h>
typedef int __attribute__((vector_size(8))) v2si;
typedef struct { int x; int y; } A;
void bar(A a);
void foo()
{
A a;
*(v2si *)&a = (v2si){0, (int)svcntd_pat(SV_ALL)};
bar(a);
}
Not sure how well-defined it is because of the pointer pun, though.
