https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
--- Comment #6 from fiesh at zefix dot tv --- My suggestion would be to uniformly include the information about whether a bug has been closed, irrespective of its nature. So yes, un-optimal code generation might also be listed, and I think the use case of providing workaround code exists for it just like it exists for an ice-on-valid. As Jonathan already said, the list should be baked into the compiler. I'm not suggesting making compilation or even execution of GCC depend on some external database query; that's a horrid idea. As for the use cases: Along the years, I've often found myself to write code of the following nature: // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663 #if defined(__GNUC__) && !defined(__llvm__) && __GNUC__ <= 10 // The workaround code #else // The good code #endif We then re-visit these places on compiler updates in case the bug wasn't fixed for the major version. This can be about new features (as a concrete example, we have code that would like to use std::transform_reduce, so it could do it in compilers with 91495 closed), or about bugs (as a concrete example, we have a template with a template template parameter that leads to an internal compiler error. We have workaround code in there that uses copy and paste code to circumvent the issue, but once 92654 is fixed, I'd prefer the good code to be used automatically.) This would also allow requiring certain bugs be fixed with ifdef-error-endif constructs instead of depending on the compiler's version explicitly. I'm not claiming this is a feature request that's perfectly thought through, and maybe the cons outweigh the pros. But I'd like to put this up for discussion because I believe the current means of circumventing bugs is not great, and it largely isn't because the information about the bug numbers is lost needlessly.
