https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
--- Comment #17 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #16)
> Created attachment 55409 [details]
> A patch
>
> I am stilling trying to find a small testcase.
The patch triggers an ICE building Spidermonkey 115b9 (it segfaults with GCC
trunk because of some unaligned vmovdqa):
0x93297b ix86_finalize_stack_frame_flags
../../gcc/gcc/config/i386/i386.cc:8224
0x162064c ix86_expand_epilogue(int)
../../gcc/gcc/config/i386/i386.cc:9405
0x1b2e27f gen_epilogue()
../../gcc/gcc/config/i386/i386.md:17517
0x160a815 target_gen_epilogue
../../gcc/gcc/config/i386/i386.md:17013
0xf15e86 make_epilogue_seq
../../gcc/gcc/function.cc:5964
0xf15f8b thread_prologue_and_epilogue_insns()
../../gcc/gcc/function.cc:6046
0xf166c2 rest_of_handle_thread_prologue_and_epilogue
../../gcc/gcc/function.cc:6544
0xf166c2 execute
../../gcc/gcc/function.cc:6625
The code at i386.cc:8224 reads:
if (crtl->stack_realign_finalized)
{
/* After stack_realign_needed is finalized, we can't no longer
change it. */
gcc_assert (crtl->stack_realign_needed == stack_realign);
return;
}
I'm not sure if the assert should be dropped or it's more difficult.
Or can we just force to use unaligned vector moves for block operations until
we can find a better solution? It's at least better than leaving the
vectorized block moving broken and forcing people trying to disable the
feature.
