[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663 --- Comment #8 from fiesh at zefix dot tv --- Ok, thanks for the feedback!
[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Richard Biener --- So you'd use __gcc_bug_fixed () at compile-time (obviously) so to me a configure check in your software project that queries bugzilla would be feasible. At least I don't see how this is all useful given our bugzilla database is _very_ far from being a source you could automatically fill this information from. For this reason - WONTFIX.
[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed
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.
[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663 --- Comment #5 from Jonathan Wakely --- True, but I still think the list needs to be compiled in to the binaries statically. If that gave incorrect results in some cases (because a bug was thought to be fixed when the static list was generated, but was later reopened) then so be it. That's better than querying bugzilla during compilation, which is totally unacceptable.
[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Bugs are sometimes reopened etc., so the list isn't completely static.
[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663 --- Comment #3 from Jonathan Wakely --- (In reply to Eric Gallager from comment #2) > This sounds like it could be dangerous from a security context... currently > no network connection is needed to use gcc, it would be a major > disappointment if that changed... I think the suggestion is that the numbers are baked into the executable, not that Bugzilla is queried. The list of fixed bugs for a given revision of the source code is a static property, it doesn't need to be queried dynamically.
[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- This sounds like it could be dangerous from a security context... currently no network connection is needed to use gcc, it would be a major disappointment if that changed...
[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Sometimes bug reports don't get a bugzilla #. Also would you consider code generation (not wrong code but unoptimial code generation) get an entry? Could you provide a full example of where you think this would be useful?
