https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
--- Comment #5 from Stam Markianos-Wright <stammark at gcc dot gnu.org> --- (In reply to rsand...@gcc.gnu.org from comment #4) > (In reply to Stam Markianos-Wright from comment #3) > > Just started looking at this. I've narrowed it as the bug appearing with > > commit 9b75f56d4b7951c60a656396dddd4a65787b95bc. > > > > I have yet to fire this up in gdb to see what's happening, but one test I > > did do was to try commenting out the assert that is causing the ICE and it > > then ran to completion. > > > > So one _total speculation_ would be that with these latest changes that > > enable groups of different sizes, this condition in the assert is now too > > strict: > > > > > > multiple_p (TYPE_VECTOR_SUBPARTS (nunits_vectype), > > TYPE_VECTOR_SUBPARTS (*stmt_vectype_out))) > What are nunits_vectype and *stmt_vectype_out at the point > that the assert fails? Hmm so looking at this on commit 9b75f56d4b7951c60a656396dddd4a65787b95bc, we have: nunits_vectype is a: vector(SUBPARTS {coeffs = {4, 0}}) float *stmt_vectype_out is a: vector(SUBPARTS {coeffs = {8, 0}}) long int In this case we are checking multiple_p (4, 8) == false (and also group_size == 9 here which is expected) Before the commit we'd get here with: nunits_vectype is a: vector(SUBPARTS {coeffs = {4, 0}}) float *stmt_vectype_out is a: vector(SUBPARTS {coeffs = {2, 0}}) long int And here we were checking multiple_p (4, 2) == true I'm tempted to try and add a reverse: || multiple_p (*stmt_vectype_out, nunits_vectype) And then regtest, but I probably need to do more reading around to figure out what we really should be expecting each case!