GCC 16.1.0 i686 ICE in extract_insn during IRA pass with -O2 -m32 -march=core2 -mfpmath=sse -ffloat-store

Hi,

I've been hitting a compiler crash with GCC 16.1.0 (i686-oe-linux-musl 
cross compiler from a Yocto/OpenEmbedded build) while compiling a Piglit 
test file and I'm trying to understand what's going on.

The error is:

   error: unrecognizable insn:
   (insn (set (reg:V4SF)
     (unspec:V4SF [(mem:V4SF ...) (reg:V4SF)] UNSPEC_IEEE_MAX)))
   during RTL pass: ira
   internal compiler error: in extract_insn, at recog.cc:2892

The flags being used are:

   -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse
   -O2 -ffloat-store -fstack-protector-strong -D_FORTIFY_SOURCE=2 -g

Source file: piglit tests/spec/ext_framebuffer_multisample/fast-clear.c

I did some digging and I think it might be related to the 
*minmax<mode>3_1 splitter in gcc/config/i386/sse.md. It looks like when 
-ffloat-store causes operands[2] to be a memory operand, the code does 
not force it into a register. The MEM_P case is not handled, only the 
immediate_operand case, so a MEM ends up inside the UNSPEC_IEEE_MAX node 
and IRA cannot match it against any pattern. I could be wrong though as 
I am still getting familiar with how the GCC backend works.

I also came across PR116925 from October 2024 which fixed something 
similar in the *minmax<mode>3_2 splitter for -mavx -ffloat-store. Not 
sure if this is the same issue showing up in a different splitter or 
something separate.

A few things I wanted to check:

1. Does this look like a real bug or am I reading the code wrong? Is it 
already tracked somewhere?

2. Is -ffloat-store expected to work with -mfpmath=sse and 
auto-vectorization at -O2? We inherited these flags from an older setup 
and I am not sure if this combination is actually valid. If it is not 
supposed to work together I can just drop -ffloat-store.

3. Should I go ahead and file a Bugzilla report? I have the -freport-bug 
preprocessed source ready to attach.


-- 
Regards,
Hemanth Kumar M D