https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127811
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so the issue is that SLP scheduling places things at a valid point but
during transform we ignore that placement (or rather, we run into this
assertion before adjusting it back). In particular the existing vector def is
the problem here which gets picked up as topmost.
I'm adjusting the assertion.
We are correctly vectorizing this as the following (note _12 + { .. } can
trap).
<bb 2> [local count: 1073741824]:
_12 = get ();
<bb 3> [local count: 1073741824]:
vect__2.3_18 = _12 + { 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0 };
_1 = BIT_FIELD_REF <_12, 32, 0>;
_2 = _1 + 1.0e+0;
_3 = BIT_FIELD_REF <_12, 32, 32>;
_4 = _3 + 1.0e+0;
_5 = BIT_FIELD_REF <_12, 32, 64>;
_6 = _5 + 1.0e+0;
_7 = BIT_FIELD_REF <_12, 32, 96>;
_8 = _7 + 1.0e+0;
_9 = vect__2.3_18;
*r_13(D) = _9;