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

On Wed, 2026-05-13 at 09:09 +0530, Hemanth Kumar M D via Gcc-help wrote:
> Hi,
>=20
> 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=
=20
> test file and I'm trying to understand what's going on.
>=20
> The error is:
>=20
> =C2=A0=C2=A0 error: unrecognizable insn:
> =C2=A0=C2=A0 (insn (set (reg:V4SF)
> =C2=A0=C2=A0 =C2=A0 (unspec:V4SF [(mem:V4SF ...) (reg:V4SF)] UNSPEC_IEEE_=
MAX)))
> =C2=A0=C2=A0 during RTL pass: ira
> =C2=A0=C2=A0 internal compiler error: in extract_insn, at recog.cc:2892
>=20
> The flags being used are:
>=20
> =C2=A0=C2=A0 -m32 -march=3Dcore2 -mtune=3Dcore2 -msse3 -mfpmath=3Dsse
> =C2=A0=C2=A0 -O2 -ffloat-store -fstack-protector-strong -D_FORTIFY_SOURCE=
=3D2 -g
>=20
> Source file: piglit tests/spec/ext_framebuffer_multisample/fast-clear.c
>=20
> I did some digging and I think it might be related to the=20
> *minmax<mode>3_1 splitter in gcc/config/i386/sse.md. It looks like when=
=20
> -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=20
> immediate_operand case, so a MEM ends up inside the UNSPEC_IEEE_MAX node=
=20
> and IRA cannot match it against any pattern. I could be wrong though as=
=20
> I am still getting familiar with how the GCC backend works.
>=20
> I also came across PR116925 from October 2024 which fixed something=20
> similar in the *minmax<mode>3_2 splitter for -mavx -ffloat-store. Not=20
> sure if this is the same issue showing up in a different splitter or=20
> something separate.
>=20
> A few things I wanted to check:
>=20
> 1. Does this look like a real bug or am I reading the code wrong? Is it=
=20
> already tracked somewhere?

ICE is always a bug (once you've ruled out general system stability
issues like hardware flaws or insufficient RAM).

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

Even if it was not supported, the compiler shouldn't ICE.  IIUC with -
mfpmath=3Dsse, -ffloat-store should be unneeded (for the PR 323 thing).=20
But maybe my understanding is wrong and anyway it shouldn't ICE.

> 3. Should I go ahead and file a Bugzilla report? I have the -freport-bug=
=20
> preprocessed source=C2=A0ready to attach.

Yes, unless there's an existing bugzilla report for this.

--=20
Xi Ruoyao <[email protected]>