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

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

[kernel test robot]

Hi Tamir,

FYI, the error/warning still remains.

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
config: xtensa-randconfig-002-20260403 (https://download.01.org/0day-ci/archive/20260403/202604030636.NqjaJvYp-lkp@intel.com/config)
compiler: xtensa-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260403/202604030636.NqjaJvYp-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Fixes: 9bfa52dac27a ("printf: convert test_hashed into macro")
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604030636.NqjaJvYp-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from <command-line>:
   lib/tests/printf_kunit.c: In function 'errptr.part.2':
>> include/linux/compiler_types.h:617:38: error: call to '__compiletime_assert_304' declared with attribute error: BUILD_BUG_ON failed: IS_ERR(PTR)
     _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
                                         ^
   include/linux/compiler_types.h:598:4: note: in definition of macro '__compiletime_assert'
       prefix ## suffix();    \
       ^~~~~~
   include/linux/compiler_types.h:617:2: note: in expansion of macro '_compiletime_assert'
     _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
     ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
    #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                        ^~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
     BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
     ^~~~~~~~~~~~~~~~
   lib/tests/printf_kunit.c:758:2: note: in expansion of macro 'BUILD_BUG_ON'
     BUILD_BUG_ON(IS_ERR(PTR));
     ^~~~~~~~~~~~


vim +/__compiletime_assert_304 +617 include/linux/compiler_types.h

eb5c2d4b45e3d2d Will Deacon 2020-07-21  603  
eb5c2d4b45e3d2d Will Deacon 2020-07-21  604  #define _compiletime_assert(condition, msg, prefix, suffix) \
eb5c2d4b45e3d2d Will Deacon 2020-07-21  605  	__compiletime_assert(condition, msg, prefix, suffix)
eb5c2d4b45e3d2d Will Deacon 2020-07-21  606  
eb5c2d4b45e3d2d Will Deacon 2020-07-21  607  /**
eb5c2d4b45e3d2d Will Deacon 2020-07-21  608   * compiletime_assert - break build and emit msg if condition is false
eb5c2d4b45e3d2d Will Deacon 2020-07-21  609   * @condition: a compile-time constant condition to check
eb5c2d4b45e3d2d Will Deacon 2020-07-21  610   * @msg:       a message to emit if condition is false
eb5c2d4b45e3d2d Will Deacon 2020-07-21  611   *
eb5c2d4b45e3d2d Will Deacon 2020-07-21  612   * In tradition of POSIX assert, this macro will break the build if the
eb5c2d4b45e3d2d Will Deacon 2020-07-21  613   * supplied condition is *false*, emitting the supplied error message if the
eb5c2d4b45e3d2d Will Deacon 2020-07-21  614   * compiler has support to do so.
eb5c2d4b45e3d2d Will Deacon 2020-07-21  615   */
eb5c2d4b45e3d2d Will Deacon 2020-07-21  616  #define compiletime_assert(condition, msg) \
eb5c2d4b45e3d2d Will Deacon 2020-07-21 @617  	_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
eb5c2d4b45e3d2d Will Deacon 2020-07-21  618  

:::::: The code at line 617 was first introduced by commit
:::::: eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5 compiler.h: Move compiletime_assert() macros into compiler_types.h

:::::: TO: Will Deacon <will@kernel.org>
:::::: CC: Will Deacon <will@kernel.org>

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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 Fri, Apr 3, 2026 at 4:45 AM kernel test robot <lkp@intel.com> wrote:
>
> Hi Tamir,
>
> FYI, the error/warning still remains.
>
> 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
> config: xtensa-randconfig-002-20260403 (https://download.01.org/0day-ci/archive/20260403/202604030636.NqjaJvYp-lkp@intel.com/config)
> compiler: xtensa-linux-gcc (GCC) 8.5.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260403/202604030636.NqjaJvYp-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Fixes: 9bfa52dac27a ("printf: convert test_hashed into macro")
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202604030636.NqjaJvYp-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
>    In file included from <command-line>:
>    lib/tests/printf_kunit.c: In function 'errptr.part.2':
> >> include/linux/compiler_types.h:617:38: error: call to '__compiletime_assert_304' declared with attribute error: BUILD_BUG_ON failed: IS_ERR(PTR)
>      _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>                                          ^
>    include/linux/compiler_types.h:598:4: note: in definition of macro '__compiletime_assert'
>        prefix ## suffix();    \
>        ^~~~~~
>    include/linux/compiler_types.h:617:2: note: in expansion of macro '_compiletime_assert'
>      _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>      ^~~~~~~~~~~~~~~~~~~
>    include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
>     #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
>                                         ^~~~~~~~~~~~~~~~~~
>    include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
>      BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
>      ^~~~~~~~~~~~~~~~
>    lib/tests/printf_kunit.c:758:2: note: in expansion of macro 'BUILD_BUG_ON'
>      BUILD_BUG_ON(IS_ERR(PTR));
>      ^~~~~~~~~~~~
>
>
> vim +/__compiletime_assert_304 +617 include/linux/compiler_types.h
>
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  603
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  604  #define _compiletime_assert(condition, msg, prefix, suffix) \
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  605     __compiletime_assert(condition, msg, prefix, suffix)
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  606
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  607  /**
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  608   * compiletime_assert - break build and emit msg if condition is false
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  609   * @condition: a compile-time constant condition to check
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  610   * @msg:       a message to emit if condition is false
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  611   *
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  612   * In tradition of POSIX assert, this macro will break the build if the
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  613   * supplied condition is *false*, emitting the supplied error message if the
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  614   * compiler has support to do so.
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  615   */
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  616  #define compiletime_assert(condition, msg) \
> eb5c2d4b45e3d2d Will Deacon 2020-07-21 @617     _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> eb5c2d4b45e3d2d Will Deacon 2020-07-21  618
>
> :::::: The code at line 617 was first introduced by commit
> :::::: eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5 compiler.h: Move compiletime_assert() macros into compiler_types.h
>
> :::::: TO: Will Deacon <will@kernel.org>
> :::::: CC: Will Deacon <will@kernel.org>
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki

I used an LLM to investigate this, including bisecting GCC. Here's
what we found:

> I think this is a pre-existing GCC bug, and commit 9bfa52dac27a
> ("printf: convert test_hashed into macro") is only the trigger.
>
> What changed in that commit is that test_hashed() became a macro, so
> errptr() now contains the local char buf[64] and the
> plain_hash_to_buffer() / test() logic directly instead of calling an
> out-of-line helper. With the reported xtensa randconfig, that changes
> GCC's IPA inlining/splitting decisions enough to expose a compiler bug.
>
> The actual failure mode is:
>
> BUILD_BUG_ON(IS_ERR(PTR));
>
> in lib/tests/printf_kunit.c. PTR is not an ERR_PTR on xtensa 32-bit, so
> the assertion is logically false. But with CONFIG_TRACE_BRANCH_PROFILING=y
> and CONFIG_PROFILE_ALL_BRANCHES=y, IS_ERR()'s unlikely() and the
> BUILD_BUG_ON() condition expand into branch-profiling counter updates.
> GCC 8.5 then IPA-splits errptr(), outlines the cold assert arm into
> errptr.part.*, and leaves that clone with an unconditional call to
> _compiletime_assert(), so the build fails even though the path is
> unreachable.
>
> I confirmed that -fno-partial-inlining or -DDISABLE_BRANCH_PROFILING
> makes the failure go away.
>
> I also bisected GCC with a reproducer that forces
> --param=max-inline-insns-auto=30 so the bug is not hidden by unrelated
> inlining heuristic changes. GCC 11.5.0 still reproduces, GCC 12.1.0
> does not, and the first real fix appears to be:
>
> 76fe494230477a69f8fa8c8ca2d493acaf343eb1
> Fix tree-optimization/101941: IPA splitting out function with error attribute

Human note: That change was motivated by exactly this kind of
compilation failure in the kernel [0].

[0] https://github.com/gcc-mirror/gcc/commit/76fe494230477a69f8fa8c8ca2d493acaf343eb1

>
> That commit teaches ipa-split not to split basic blocks containing calls
> to functions with attribute((error)) or attribute((warning)),
> which is exactly what goes wrong here.
>
> 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.
> 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.
>
> 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?

Cheers.

Tamir

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]

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

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

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