Re: include/linux/compiler_types.h:617:38: error: call to '__compiletime_assert_304' declared with attribute error: BUILD_BUG_ON failed: IS_ERR(PTR)

[Tamir Duberstein]

On Sat, Apr 4, 2026 at 3:38 PM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>
> On Sat, Apr 04, 2026 at 12:04:02PM -0400, Tamir Duberstein wrote:
> > On Fri, Apr 3, 2026 at 4:45 AM kernel test robot <lkp@xxxxxxxxx> wrote:
> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > head:   5619b098e2fbf3a23bf13d91897056a1fe238c6d
> > > commit: 9bfa52dac27a20b43bcb73e56dc45aba6b9aaff1 printf: convert test_hashed into macro
> > > date:   9 weeks ago
>
> ...
>
> > I used an LLM to investigate this, including bisecting GCC. Here's
> > what we found:
>
> Have you talked to Max Filippov who is arch maintainer in kernel?
>
> ...
>
> > > So I see two possible mitigations:
> > >
> > > 1. Work around this in the test by avoiding IS_ERR() in that
> > >    BUILD_BUG_ON(), e.g. use the raw MAX_ERRNO range check instead:
> > >
> > >    BUILD_BUG_ON((unsigned long)PTR >= (unsigned long)-MAX_ERRNO);
> > >
> > >    That keeps the same build-time check but avoids routing a constant
> > >    expression through unlikely() under branch profiling, so GCC 8.5 no
> > >    longer trips over it.
>
> I believe it's close to "not an option" as it's a non-scalable change.
> If in the future IS_ERR() becomes something else (but still covers
> the same check) this will be in unsync and might trigger in a wrong
> circumstances (while I don't believe it will happen IRL).
>
> > > 2. Stop running xtensa randconfig with GCC versions older than the
> > >    ipa-split fix above, i.e. use GCC >= 12.1 for xtensa in LKP.
>
> This is also close to that "not an option" as we have Linux kernel wide
> minimum GCC requirement.
>
> Yes, theoretically any of the above is possible, but I dunno from where
> the pushback may come.
>
> > > I had a quick look at lkp-tests, but I don't see an xtensa-specific
> > > compiler selection policy there; make.cross appears to consume an
> > > already-chosen COMPILER value. So if the preferred mitigation is
> > > toolchain-side, that policy likely lives in the 0day/LKP scheduler or
> > > job-generation layer outside lkp-tests.
> > >
> > > One caveat on the reporting side: if other architectures are already
> > > using newer GCC, or if 0day suppresses duplicate reports after the first
> > > failing instance, that would explain why this only showed up as an
> > > xtensa GCC 8.5 report even though the underlying compiler bug is not
> > > xtensa-specific in principle.
> >
> > Human again.
> >
> > Petr, Andy: Would you like me to send a patch with the workaround?
> >
> > LKP folks: Is GCC 8.5 only used for xtensa, or are old compiler
> > versions also exercised by other architectures, and was this just the
> > first one to hit this condition? If the former, is it possible to bump
> > xtensa to GCC 12.1 or later?
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

I sent https://lore.kernel.org/all/20260405-printf-test-old-gcc-v1-1-76d24d9bb60e@xxxxxxxxxx/
with what I think is a reasonable workaround.