https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
--- Comment #26 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> --- (In reply to dhowe...@redhat.com from comment #21) > (In reply to Markus Trippelsdorf from comment #20) > > *** Bug 78879 has been marked as a duplicate of this bug. *** > > Kernel bug or not, it should be noted that this means that you cannot use > gcc from r236831 to compile any kernel from the introduction and use of > ilog2() to the current day - and these kernel versions cannot be > retroactively fixed. This is really the crux of the issue. Even if we were to agree that this is a kernel bug, and even if that kernel bug has a fix, there is a lot of kernel code out there that won't ever carry that patch. As far as I can see the patch from Will Dacon you've linked above hasn't made it to a mainline tree, so the kernel bug continues to propagate around mainline and stable versions. If this were a clear case of GCC being right, I'd agree with the bug being closed, but GCC's documentation of __builtin_constant_p doesn't make clear just how unintuitive __builtin_constant_p semantics are. At best this is a grey area in need of documentation clarification, at worst this is GCC being "weird" for the sake of it. Pragmatically, the question is whether we think path specialization which turns a previously FALSE __b_c_p call TRUE is more likely to confuse our users than improve the code generation. Personally, I think it is confusing, but I appreciate we've not all agreed on that position.
