On Wed, 2026-06-24 at 17:26 +0000, Joseph Myers wrote:
> On Thu, 18 Jun 2026, Joseph Myers wrote:
>
> > On Tue, 16 Jun 2026, Andrew Pinski wrote:
> >
> > > From: Carter Rennick <[email protected]>
> > >
> > > The definition of MAX_FIXED_MODE_SIZE did not account for MIPS supporting
> > > TImode, which causes an internal compiler error when building libstdc++.
> > > Upon further
> > > investigation, this definition appears to be a historical mistake.
> > >
> > > This patch removes the MAX_FIXED_MODE_SIZE override, which fixes the
> > > error.
> > >
> > > PR target/120144
> > >
> > > gcc/ChangeLog:
> > >
> > > * config/mips/mips.h (MAX_FIXED_MODE_SIZE): Remove.
> >
> > This introduces an ICE building libstdc++ for mips64-linux-gnu
> > (preprocessed source attached, not reduced).
> >
> > Note 1: there is a similar ICE also on GCC mainline, but only for certain
> > little-endian configurations, whereas with GCC 15 branch I see this for a
> > wider range of MIPS configurations used by build-many-glibcs.py, both BE
> > and LE. I'm not sure exactly when the ICE appeared on GCC mainline (the
> > build of glibc in my bot using GCC mainline was broken for a while because
> > of -Wconstant-logical-operand issues in glibc), but it wasn't introduced
> > by the commit being backported; it appeared some time later, so maybe
> > there is an interaction of multiple commits involved.
> >
> > Note 2: I haven't tested for this issue with GCC 16 branch.
>
> Having now tested with GCC 16 branch, I don't see the issue there (that
> is, I don't see any failures to build libstdc++ for MIPS configurations in
> build-many-glibcs.py with GCC 16 branch). Though it seems likely the
> underlying issue is present on GCC 16 branch as well as on GCC mainline
> and having been introduced to GCC 15 branch by the backport, even if
> latent on GCC 16 branch for the particular test of building libstdc++.
Ironically, the reduced test case for the ICE at -O0 is
int x(unsigned __int128 y)
{
return __builtin_ctzg(y);
}
i.e. the test case added in the patch...
--
Xi Ruoyao <[email protected]>
