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 <[email protected]> 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: [email protected]
