Weekend projects: getting silly with C

Post by jstimpfle » Mon, Jul 01, 2024, 2:41 PM UTC

jstimpfle wrote: post #99

kazinator wrote: post #94

Earlier quoted context omitted.

Compilers don't prove UB; they assume absence of UB. That, plus a modicum of reasoning like "if this were to be evaluated, it would be UB" (therefore, let's assume that is not evaluated).

Let's not get pedantic about what "proving UB" actually means -- that might lead to philosophic discussions about sentient compilers. Fact is that in this instance, the compiler did not remove a basic black of code (including or excluding "observeable side-effects" leading up to the point of UB happening). It would not be valid for the compiler to assume that the path is never taken in this case, even assuming that U…

Post by jstimpfle » Mon, Jul 01, 2024, 3:19 PM UTC

gpderetta wrote: post #96

jstimpfle wrote: post #92

Earlier quoted context omitted.

Thanks for the example. But again I can't see a problem. The compiler does not actually prove UB in this case, so I suppose this doesn't qualify as applying (mis-) optimizations silently based on UB. Or what did I miss?

The compiler is moving a potentially UB operation above a side effect. This contradicts uecker non-time-traveling-ub and it is potentially a GCC bug. If you want an example of GCC removing a side effect that happens-before provable subsequent UB: https://godbolt.org/z/PfoT8E8PP but I don't find it terribly interesting as the compiler warns here.

  extern volatile int x;
  int ub() {
      int r = x;
      r += 1/0;
      return r;
  }

  ub:
        mov     eax, DWORD PTR x[rip]
        ud2

Post by jstimpfle » Mon, Jul 01, 2024, 3:34 PM UTC

gpderetta wrote: post #102

jstimpfle wrote: post #99

Earlier quoted context omitted.

Let's not get pedantic about what "proving UB" actually means -- that might lead to philosophic discussions about sentient compilers. Fact is that in this instance, the compiler did not remove a basic black of code (including or excluding "observeable side-effects" leading up to the point of UB happening). It would not be valid for the compiler to assume that the path is never taken in this case, even assuming that U…

> The issue discussed is that based on assumptions about UB, the compiler emits code that does not correspond to the source in an intuitive way, for example a branch of code is entirely removed, including any observeable side-effects that logically happened before the UB. That's literally what happens in my example: the div is hoisted above the volatile read which is an observable side effect. The practical effect is…

Post by gpderetta » Mon, Jul 01, 2024, 4:49 PM UTC

jstimpfle wrote: post #104

jstimpfle wrote: post #103

Earlier quoted context omitted.

In your godbolt extern volatile int x; int ub() { int r = x; r += 1/0; return r; } and the output is ub: mov eax, DWORD PTR x[rip] ud2 I don't see what is the side effect that you say is removed here? As for the earlier example (hoisting the division out of the loop), I was going to write a wall of text explaining why I find the behaviour totally intuitive and in line with what I'd expect. But we can make it simpler:…

I think this one better illutrates the point you were making: https://godbolt.org/z/qbfhb6dKo Here I've inserted an increment of the volatile (i.e. a write access) at the start of the loop. If the divisor is 0, in the optimized version with the division hoisted out of the loop, the increment will never actually happen, not even once. Whereas it should in fact happen 1x at the beginning of the first loop iteration wit…

  extern volatile int x;
  int ub(int d, int c) {
    int r;
    x += 3;
    r += x;
    int _div = d / c;
    r += _div;

    for (int 2 = 0; i