https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637
--- Comment #3 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> If I change the testcase to following (so that it doesn't rely on
> __builtin_convertvector), it started ICEing with
> r0-122162-gb7aa4e9afcd3da4f09d6f982a663ea2094b1f2cf
> typedef short __attribute__((__vector_size__ (64))) U;
> typedef unsigned long long __attribute__((__vector_size__ (32))) V;
> typedef long double __attribute__((__vector_size__ (64))) F;
>
> int i;
> U u;
> F f;
>
> void
> foo (char a, char b, _Complex char c, V v)
> {
> u = (U) { u[0] / 0, u[1] / 0, u[2] / 0, u[3] / 0, u[4] / 0, u[5] / 0, u[6]
> / 0, u[7] / 0,
> u[8] / 0, u[0] / 0, u[9] / 0, u[10] / 0, u[11] / 0, u[12] / 0,
> u[13] /
> 0, u[14] / 0, u[15] / 0,
> u[16] / 0, u[17] / 0, u[18] / 0, u[19] / 0, u[20] / 0, u[21] / 0,
> u[22]
> / 0, u[23] / 0,
> u[24] / 0, u[25] / 0, u[26] / 0, u[27] / 0, u[28] / 0, u[29] / 0,
> u[30]
> / 0, u[31] / 0 };
> c += i;
> f = (F) { v[0], v[1], v[2], v[3] };
> i = (char) (__imag__ c + i);
> }
>
> In any case, I don't see anything wrong on the GIMPLE side and it isn't
> clear on reloading which insn it is ICEing.
It is a pitfall of LRA hard reg split subpass. It is a small subpass used as
the last resort for LRA when it can not assign a hard reg to a reload pseudo by
other ways (e.g. by spilling non-reload pseudos). For simplicity the subpass
works on one split base (as each split changes pseudo live range info). To
solve the problem the subpass should make as many splits as possible. This
requires to check overlapping hard reg splits.
In other words, the subpass should be considerably modified. I hope to commit
the patch on the next week.
