[Bug rtl-optimization/125078] m68k: ICE in cselib_record_set at cselib.cc:2727 on ML-KEM code with -O2 -fno-schedule-insns

[jeanmichel.hautbois at yoseli dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125078

--- Comment #4 from Jean-Michel Hautbois <jeanmichel.hautbois at yoseli dot org> ---
(In reply to Mikael Pettersson from comment #3)
> I can reproduce the ICE with gcc-15.2.0 built for m68k-unknown-linux-uclibc,
> but not with a similarly configured gcc-16.1.0. I haven't started bisecting
> yet.

Thanks Mikael for confirming, that narrowed it down nicely.

I bisected the gcc-15.2.0 -> gcc-16.1.0 range

First fixed commit:

  commit 9f9c8d63a5822378e18f3f8f188df21c6104e18e
  Author: Jan Hubicka <hubicka@ucw.cz>
  Date:   Fri Sep 26 12:39:07 2025 +0200
      Fix integer overflow in profile_count::probability_in
  (touches gcc/profile-count.h only)

So the ICE is a downstream symptom of the integer overflow in
profile_count::probability_in: the bogus profile data ends up tripping
postreload CSE in cselib_record_set. -fno-schedule-insns(2) changes the
RTL enough to expose it on ColdFire.

The fix is present on releases/gcc-16 (and thus gcc-16.1.0) but has NOT
been backported to the gcc-15 branch, which is why gcc-15.2.0 still ICEs.

I confirmed the fix on releases/gcc-15.2.0: a pristine 15.2.0 cross
compiler ICEs on the testcase, and applying just the profile_count::
probability_in hunk of 9f9c8d63 (replacing the unguarded

    ret.m_val = RDIV (m_val * profile_probability::max_probability,
                      overall.m_val);

with the safe_scale_64bit + cap variant) makes it compile cleanly.

Note that 9f9c8d63 does not cherry-pick onto gcc-15 as-is, but the
probability_in hunk above applies and resolves the ICE on its own.

Jan, would you consider backporting the probability_in overflow fix from
9f9c8d63 to releases/gcc-15?

CC: hubicka@ucw.cz