[Bug target/114487] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

2024-03-27 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487

--- Comment #12 from Sam James  ---
Ah, wait, no point with andrew's nicer testcase ;)

[Bug target/114487] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

2024-03-27 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487

--- Comment #11 from Sam James  ---
I'm going to upload the originals in case it offers more insight because the
return type isn't mismatched there.

[Bug target/114487] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

2024-03-27 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487

--- Comment #10 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > Created attachment 57823 [details]
> > testcase for non-lto
> > 
> > `-W -Wall -m32 -fwhole-program -march=i686  -O1` is enough
> 
> Note the only difference between this and the reduced LTO case is fix up of
> SDLTest_RandomUnitFloat return type so it would be more defined and then the
> additions of the #pragma and the use of `-fwhole-program` option instead of
> LTO (since LTO does a similar thing).

You can remove -fwhole-program if you make SDLTest_RandomUnitFloat static too
(since that is basically what -fwhole-program is doing after all) and you still
get the failure.

[Bug target/114487] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

2024-03-27 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> Created attachment 57823 [details]
> testcase for non-lto
> 
> `-W -Wall -m32 -fwhole-program -march=i686  -O1` is enough

Note the only difference between this and the reduced LTO case is fix up of
SDLTest_RandomUnitFloat return type so it would be more defined and then the
additions of the #pragma and the use of `-fwhole-program` option instead of LTO
(since LTO does a similar thing).

[Bug target/114487] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

2024-03-27 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487

--- Comment #8 from Andrew Pinski  ---
Created attachment 57823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57823=edit
testcase for non-lto

`-W -Wall -m32 -fwhole-program -march=i686  -O1` is enough

[Bug target/114487] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

2024-03-27 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487

--- Comment #7 from Sam James  ---
(You're right, by the way. The original fails with older GCC too. Sorry!)

[Bug target/114487] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

2024-03-27 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487

--- Comment #6 from Richard Biener  ---
I'd say ix86_function_sseregparm should be decided at a specific point and
recorded for later use.  Alternatively there needs to be a (target) IPA
phase where we can mark functions we cannot turn into sseregparm.

[Bug target/114487] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

2024-03-27 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
Ah.  But note in this case we only have a single ltrans unit.  We might be
confused by the fact that wrong prototype will result in a
call through a float(*)() type while the actual local function doesn't
use any FP registers and has void return.

OTOH the 'void' can be exchanged for 'float' in SDL_test_fuzzer.i and the
issue still reproduces (with a single LTRANS unit).

[Bug target/114487] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

2024-03-27 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487

--- Comment #4 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > Adding -msse to the second compilation works OK, removing -mfpmath=sse from
> > the first compilation also works OK.
> 
> Which makes this PR a LTO reincarnation of PR66047.

Please see the FIXME in ix86_function_sseregparm:

  /* Refuse to produce wrong code when local function with SSE enabled
 is called from SSE disabled function.
 FIXME: We need a way to detect these cases cross-ltrans partition
 and avoid using SSE calling conventions on local functions called
 from function with SSE disabled.  For now at least delay the
 warning until we know we are going to produce wrong code.
 See PR66047  */

[Bug target/114487] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

2024-03-27 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487

--- Comment #3 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #2)
> Adding -msse to the second compilation works OK, removing -mfpmath=sse from
> the first compilation also works OK.

Which makes this PR a LTO reincarnation of PR66047.

[Bug target/114487] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

2024-03-27 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487

--- Comment #2 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #1)

> (insn 6 5 0 (set (reg/v:SF 99 [ gamma ])
> (reg:SF 20 xmm0)) "testautomation-testautomation_pixels.i":15:17 -1
>  (nil))
> 
> I'm not sure what's wrong - looks like a target issue to me.

We are working with SFmode, so -msse is enough to trigger the bug.

This is known issue. GCC assumes that at least moves of all hard registers are
working, which is not the case when LTO-compiling
testautomation-testautomation_pixels.i with SDL_test_fuzzer.o (that enables and
uses XMM registers via -msse -mfpmath=sse).

It looks to me that the compiler hits this part in function_value_32 when
LTO-compiling:

--cut here--
  /* Override FP return register with %xmm0 for local functions when
 SSE math is enabled or for functions with sseregparm attribute.  */
  if ((fn || fntype) && (mode == SFmode || mode == DFmode))
{
  int sse_level = ix86_function_sseregparm (fntype, fn, false);
  if (sse_level == -1)
{
  error ("calling %qD with SSE calling convention without "
 "SSE/SSE2 enabled", fn);
  sorry ("this is a GCC bug that can be worked around by adding "
 "attribute used to function called");
}
  else if ((sse_level >= 1 && mode == SFmode)
   || (sse_level == 2 && mode == DFmode))
regno = FIRST_SSE_REG;
}
--cut here--

Adding -msse to the second compilation works OK, removing -mfpmath=sse from the
first compilation also works OK.

[Bug target/114487] ICE when building libsdl2 on -mfpmath=sse x86 with LTO

2024-03-27 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487

Richard Biener  changed:

   What|Removed |Added

Summary|[14 regression] ICE when|ICE when building libsdl2
   |building libsdl2 on |on -mfpmath=sse x86 with
   |-mfpmath=sse x86 with LTO   |LTO
  Known to fail||12.3.1, 13.2.1, 14.0, 7.5.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-27
   Keywords||lto
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I can confirm the ICE.  We're expanding

;; gamma_4 = SDLTest_RandomUnitFloat ();

(call_insn/u 5 4 6 (set (reg:SF 20 xmm0)
(call (mem:QI (symbol_ref:SI ("SDLTest_RandomUnitFloat") [flags 0x3] 
) [0
SDLTest_RandomUnitFloat S1 A8])
(const_int 0 [0]))) "testautomation-testautomation_pixels.i":15:17
-1
 (expr_list:REG_CALL_DECL (symbol_ref:SI ("SDLTest_RandomUnitFloat") [flags
0x3]  )
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(nil))

(insn 6 5 0 (set (reg/v:SF 99 [ gamma ])
(reg:SF 20 xmm0)) "testautomation-testautomation_pixels.i":15:17 -1
 (nil))

I'm not sure what's wrong - looks like a target issue to me.

I'll note -mmmx -msse isn't necessary, -msse2 is enough.  Likewise -fPIC
isn't required.  I've reproduced with -m32 added on x86_64.

GCC 13/12 are also broken the same way and GCC 7 doesn't terminate compiling.

So I'm not sure whether this is a regression (the reduced testcase, that is).
I can't find a version that works.