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)

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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@intel.com> 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