https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Kern Sibbald from comment #6) > As you say, everything has been said and in any case, it is clear that you > are going to stick with the current compiler behavior. What you have failed There is no 'we'. Individuals work on GCC, they implement changes because they fix something that they consider broken or because they are paid for it. I don't have an opinion on this particular case. I do think GCC could produce better diagnostics. It could also be smarter about its optimizations. It could also provide a -fboring option (https://lwn.net/Articles/669004/). But currently I don't have the time nor the money to do any of those, so there is no point in complaining loudly that people don't work on what I want. What I meant by posting those links is that almost every point in the discussion so far is already in the FAQ and you can find much better explanations in them than anyone can give you here (otherwise, we should extend the FAQs). > to understand is that I do very well understand that certain things are > "undefined". My complaint is that once you have decided that it is >From the FAQ: Undefined behavior is not decided nor defined by GCC, but by the committees that write the language standards. Quoting Steve Summit (maintainer of the C FAQ): "Perhaps we could, but not under the current Standard. [...] But the C Standard is under revision: perhaps, if this is important enough to you, you can convince the committee" > undefined, the compiler should at print a warning message and then leave the > code alone. This is what any reasonable compiler would do (IMO). Instead >From the FAQ: GCC attempts to diagnose some undefined behaviours, but this is not possible in all cases. If GCC missed a warning and you know how to implement it, please send even a rough working patch. Otherwise, just assume there is no easy/efficient way to diagnose that particular case. (That said, I think GCC should warn in this case, as it seems easy: https://gcc.gnu.org/bugzilla/PR71904. Clang does it. Probably the above paragraph should be rewritten: encourage users to open PRs, but cautioning them that diagnosing UB is hard/impossible in most cases) > the compiler disregards what the programmer has written and elides code. I > (personally) classify this this is bad decision making (not conservative) > because it made the "undefined behavior" worse by introducing bugs. Clearly From the FAQ: The reasons why the above are not reasonable requests are difficult to understand unless you are willing to learn '''in detail''' about how optimizing compilers work internally and the history of the programming languages. Steve Summit briefly discusses only part of the [[http://www.eskimo.com/~scs/readings/undef.950321.html|rationale behind undefined behaviors.]] (I just added this now to further explain this point and because people do not seem to bother to read Summit's text ;-) > this is my opinion and not yours, so let's let it drop there because it is > your project and your call. GCC belongs to whoever decides to contribute to it: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps If you think that better warnings are needed, you are free to contribute to that. If you have a clear idea how to make this UB behave consistently and do not impact optimization, then propose a patch. If you think that this case is so important that any optimization gains should be ignored, then become a middle-end maintainer. You said: > In both case, the assumptions you make are not valid and thus these > optimizations should not be made at low levels such as -O2 and below. If the assumptions were invalid, they would be invalid at any optimization level (and without optimization).
