https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
--- Comment #27 from Markus Trippelsdorf <trippels at gcc dot gnu.org> --- (In reply to James Greenhalgh from comment #26) > (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. As far as I can tell the kernel is the only project where this issue ever popped up. The fix is straightforward. It just needs to be send to the correct kernel maintainer. Why do you think this case is any different from any other buggy application code that needs adjustments as gcc improves?
