3 ms·

> If the situation has not been ignored completely (for instance, the compiler analyzes for the absence of that type of undefined behavior and optimized based o

> If the situation has not been ignored completely (for instance, the compiler analyzes for the absence of that type of undefined behavior and optimized based on that) Except optimizing based on undefined behavior is also a form of ignoring the situation. For example, say you have code that can: 1. Execute Action A if undefined behavior is present, or 2. Execute Action B if undefined behavior is not present. A compiler could look at these two possibilities, see that one of them invokes undefined behavior, ignore that situation completely, and optimize the remaining path. And that would be perfectly in line with the wording of the standard. The interpretation you and other commentors who dislike optimizations based on UB favor is that "ignoring the situation" should mean "treat the code as if it was conforming". Both are valid readings of the standard, and the only way one will become the dominant reading would be for the standard to use less ambiguous wording.

kazinator 7y ago
> Except optimizing based on undefined behavior is also a form of ignoring the situation. That is illogical. 1. The optimizing is based on undefined behavior (your exact words). (Actually it is based on the assumption of freedom from a specific undefined behavior, but the assumption is somehow tied to that case of undefined behavior.) 2. The situation that is to be "ignored completely" is the undefined behavior. 3. So the "based on" and "ignore completely" both refer to the undefined behavior. 4. Contradiction: "based on" is quite opposite to "ignoring completely". You can only be doing one or the other. Also, you're neglecting to provide a plausible hypothesis as to why "permissible" had to be changed to "possible", if it makes no difference in meaning. I don't think that the original ANSI C committee would have signed off on that change. It's not an interpretation of existing committee intent, but a case of new people changing the language. The purpose of, say, numeric overflow being undefined is that implementations didn't agree on how it was handled. Compilers simply passed that on to the machine code. that's what it means to "ignore the situation completely": just compile the code, and let whatever happen in the translation. Programmers who understand the machine could infer the behavior anyway, for their platform. > see that one of them invokes undefined behavior, ignore that situation completely Removing something from consideration after evaluating it is not compatible with the wording "ignore completely". It might be compatible with "ignore"; I could swallow that much. Definitely with the "completely" though. The C89 authors added that adverb there for a reason. > And that would be perfectly in line with the wording of the standard. Well, with the current wording, not the historic wording in C89.
- aw1621107 7y ago
  > That is illogical. It's illogical because of poor wording on my part that didn't really match what I wanted to say, yes. Sorry about that. As you noted, a better phrasing might be "Optimizations based on ignoring executions that result in undefined behavior is also a form of ignoring the situation". Hopefully that better captures my intent. > Also, you're neglecting to provide a plausible hypothesis as to why "permissible" had to be changed to "possible", if it makes no difference in meaning. I didn't intend to explain that change in wording because in my opinion it doesn't make a difference as long as the "ignoring the situation" clause remains. > that's what it means to "ignore the situation completely": just compile the code, and let whatever happen in the translation. That's one interpretation. The other is to ignore the code that invokes undefined behavior and optimize as if it was not there. > Removing something from consideration after evaluating it is not compatible with the wording "ignore completely". I'm not sure I would necessarily agree that "completely" would preclude evaluating the situation at all, but my command of English is lacking. I think it actually wouldn't matter; given some code that may or may not exhibit UB, there are arguably two ways to end up with only one case to consider: 1. Ignore the code that exhibits UB 2. Ignore the UB and treat the code as conforming Evaluation of the options will have to take place either way, whether it is at compiler run time, compiler design/write time, both, or something else.
  - kazinator 7y ago
    I think the only fact that rescues this situation is that in the same paragraph, there is wording which assures the implementor that UB "imposes no requirements" (famous fact everyone basically knows). The later "permissible" is an unfortunate word that appears to give requirements. Without the "imposes no requirements" to contradict that word, it would be a lot more troublesome. I wrote a detailed reponse to the blogger, which is "awaiting moderation". I not only point out that the C89 wording is contradictory, which justifies the replacement of the word, but that all sorts of common, useful optimizations are predicated on the absence of the program's reliance on undefined behavior. If we cannot optimize based on the absence of undefined behavior, we cannot cache variables in registers or do CSE, or only in a lot fewer possible cases. At best we can do back-end things that just improve the compiler's output without regard for the original program (optimal allocation of real registers to pseudo-registers, peephole optimization, jump threading, ...)

kazinator 7y ago

> Except optimizing based on undefined behavior is also a form of ignoring the situation. That is illogical. 1. The optimizing is based on undefined behavior (your exact words). (Actually it is based on the assumption of freedom from a specific undefined behavior, but the assumption is somehow tied to that case of undefined behavior.) 2. The situation that is to be "ignored completely" is the undefined behavior. 3. So the "based on" and "ignore completely" both refer to the undefined behavior. 4. Contradiction: "based on" is quite opposite to "ignoring completely". You can only be doing one or the other. Also, you're neglecting to provide a plausible hypothesis as to why "permissible" had to be changed to "possible", if it makes no difference in meaning. I don't think that the original ANSI C committee would have signed off on that change. It's not an interpretation of existing committee intent, but a case of new people changing the language. The purpose of, say, numeric overflow being undefined is that implementations didn't agree on how it was handled. Compilers simply passed that on to the machine code. that's what it means to "ignore the situation completely": just compile the code, and let whatever happen in the translation. Programmers who understand the machine could infer the behavior anyway, for their platform. > see that one of them invokes undefined behavior, ignore that situation completely Removing something from consideration after evaluating it is not compatible with the wording "ignore completely". It might be compatible with "ignore"; I could swallow that much. Definitely with the "completely" though. The C89 authors added that adverb there for a reason. > And that would be perfectly in line with the wording of the standard. Well, with the current wording, not the historic wording in C89.

aw1621107 7y ago
> That is illogical. It's illogical because of poor wording on my part that didn't really match what I wanted to say, yes. Sorry about that. As you noted, a better phrasing might be "Optimizations based on ignoring executions that result in undefined behavior is also a form of ignoring the situation". Hopefully that better captures my intent. > Also, you're neglecting to provide a plausible hypothesis as to why "permissible" had to be changed to "possible", if it makes no difference in meaning. I didn't intend to explain that change in wording because in my opinion it doesn't make a difference as long as the "ignoring the situation" clause remains. > that's what it means to "ignore the situation completely": just compile the code, and let whatever happen in the translation. That's one interpretation. The other is to ignore the code that invokes undefined behavior and optimize as if it was not there. > Removing something from consideration after evaluating it is not compatible with the wording "ignore completely". I'm not sure I would necessarily agree that "completely" would preclude evaluating the situation at all, but my command of English is lacking. I think it actually wouldn't matter; given some code that may or may not exhibit UB, there are arguably two ways to end up with only one case to consider: 1. Ignore the code that exhibits UB 2. Ignore the UB and treat the code as conforming Evaluation of the options will have to take place either way, whether it is at compiler run time, compiler design/write time, both, or something else.
- kazinator 7y ago
  I think the only fact that rescues this situation is that in the same paragraph, there is wording which assures the implementor that UB "imposes no requirements" (famous fact everyone basically knows). The later "permissible" is an unfortunate word that appears to give requirements. Without the "imposes no requirements" to contradict that word, it would be a lot more troublesome. I wrote a detailed reponse to the blogger, which is "awaiting moderation". I not only point out that the C89 wording is contradictory, which justifies the replacement of the word, but that all sorts of common, useful optimizations are predicated on the absence of the program's reliance on undefined behavior. If we cannot optimize based on the absence of undefined behavior, we cannot cache variables in registers or do CSE, or only in a lot fewer possible cases. At best we can do back-end things that just improve the compiler's output without regard for the original program (optimal allocation of real registers to pseudo-registers, peephole optimization, jump threading, ...)