4 ms·

That's from the spec POV. On x86 for example, signed int overflow is well defined.

morelisp 4y ago
Both "UB" and "IB" are terms defined in the language standards, and it's obvious that's what we're talking about here. x86 defines what specific instructions do, nothing so crass as "signed integer overflow" - that's part of why the language standard has to define it as such.
- torstenvl 4y ago
  Yeah, except that they effectively aren't part of the language standard. Possible behavior is to ignore UB, behave in a documented manner, or issue a compiler error. Not remove other code or any other nonsense optimizing compilers do. I'm not gonna wage a holy war against optimizing compilers, but let's not pretend that this is a language standard issue.
- tsimionescu 4y ago
  > x86 defines what specific instructions do, nothing so crass as "signed integer overflow" I don't understand what you mean. The x86 standard defines what happens if an `add` instruction is performed and the result overflows, possibly affecting the sign bit (what happens is that the OF flag is set, and the target register is set to the two's complement representation of the sum modulo 2^bitlength).
quietbritishjim 4y ago
That's irrelevant. A C compiler targetting x86 has no obligation at all to handle signed integer overflow in the same way the processor natively does. Because it is not an assembler - it is compiling against the theoretical C virtual machine. This is for the same sort of reason that unsigned overflow does have a well defined meaning in C, and will always do exactly that even for targets that do not natively do that (if necessary it would emulate that behaviour in software).
- rightbyte 4y ago
  > A C compiler targetting x86 has no obligation It kinda has an implied obligation to not screw with its users. And doing the same optimizations to fold bloated Cpp templates properly messes with my C code.
  - adgjlsfhk1 4y ago
    unfortunately for you, gcc and clang disagree with you.
- dooglius 4y ago
  Compiler developers may not think they have that obligation, but they should
  - kalkin 4y ago
    Should loop-invariant code motion be an allowed optimization only when the compiler can statically prove that a for loop's increment won't overflow?
    - dooglius 4y ago
      If it would result in different behavior in the event of an overflow (which I think is generally not the case), then no. A typical for loop (using <) can easily been seen to not overflow, so this is a rare case anyway. Loops using signed comparison with <= where the compiler can't rule overflow out should result in a compiler or linter warning.
      - kalkin 4y ago
        The inequality argument would seem to apply only to for loops with constant iteration counts, yeah? The compiler can't know that "i < n; i++" won't overflow if "i" could start out higher than "n". (wrong) I am not an expert on compiler optimization, but having reasoned through a few cases where a compiler is _unable_ to correctly make an obvious-seeming optimization, I tend to think that compiler writers have good reasons for the things they want to be able to assume.
josefx 4y ago
x86 also doesn't support 64 bit integers, so would those be entirely undefined behavior or simply compile time errors?
layer8 4y ago
It’s well-defined on x86, but the compiler is allowed to insert INTO instructions (which trigger an interrupt on overflow), which is effectively UB (as the interrupt routine is outside the scope of the C language).

Both "UB" and "IB" are terms defined in the language standards, and it's obvious that's what we're talking about here. x86 defines what specific instructions do, nothing so crass as "signed integer overflow" - that's part of why the language standard has to define it as such.

torstenvl 4y ago
Yeah, except that they effectively aren't part of the language standard. Possible behavior is to ignore UB, behave in a documented manner, or issue a compiler error. Not remove other code or any other nonsense optimizing compilers do. I'm not gonna wage a holy war against optimizing compilers, but let's not pretend that this is a language standard issue.
tsimionescu 4y ago
> x86 defines what specific instructions do, nothing so crass as "signed integer overflow" I don't understand what you mean. The x86 standard defines what happens if an `add` instruction is performed and the result overflows, possibly affecting the sign bit (what happens is that the OF flag is set, and the target register is set to the two's complement representation of the sum modulo 2^bitlength).

quietbritishjim 4y ago

That's irrelevant. A C compiler targetting x86 has no obligation at all to handle signed integer overflow in the same way the processor natively does. Because it is not an assembler - it is compiling against the theoretical C virtual machine. This is for the same sort of reason that unsigned overflow does have a well defined meaning in C, and will always do exactly that even for targets that do not natively do that (if necessary it would emulate that behaviour in software).

rightbyte 4y ago
> A C compiler targetting x86 has no obligation It kinda has an implied obligation to not screw with its users. And doing the same optimizations to fold bloated Cpp templates properly messes with my C code.
- adgjlsfhk1 4y ago
  unfortunately for you, gcc and clang disagree with you.
dooglius 4y ago
Compiler developers may not think they have that obligation, but they should
- kalkin 4y ago
  Should loop-invariant code motion be an allowed optimization only when the compiler can statically prove that a for loop's increment won't overflow?
  - dooglius 4y ago
    If it would result in different behavior in the event of an overflow (which I think is generally not the case), then no. A typical for loop (using <) can easily been seen to not overflow, so this is a rare case anyway. Loops using signed comparison with <= where the compiler can't rule overflow out should result in a compiler or linter warning.
    - kalkin 4y ago
      The inequality argument would seem to apply only to for loops with constant iteration counts, yeah? The compiler can't know that "i < n; i++" won't overflow if "i" could start out higher than "n". (wrong) I am not an expert on compiler optimization, but having reasoned through a few cases where a compiler is _unable_ to correctly make an obvious-seeming optimization, I tend to think that compiler writers have good reasons for the things they want to be able to assume.

josefx 4y ago

x86 also doesn't support 64 bit integers, so would those be entirely undefined behavior or simply compile time errors?

layer8 4y ago

It’s well-defined on x86, but the compiler is allowed to insert INTO instructions (which trigger an interrupt on overflow), which is effectively UB (as the interrupt routine is outside the scope of the C language).