3 ms·

A compiler can’t know why you fucked up, it can’t even know that you fucked up, because UBs are just ways for it to infer and propagate constraints. If an opti

A compiler can’t know why you fucked up, it can’t even know that you fucked up, because UBs are just ways for it to infer and propagate constraints. If an optimising C compiler can’t rely on UBs not happening, its potential is severely cut down due to the dearth of useful information provided by C’s type system.

eru 4y ago
> A compiler can’t know why you fucked up, it can’t even know that you fucked up, because UBs are just ways for it to infer and propagate constraints. To be honest, that's just how compiler writers interpret UB these days. It's perfectly possible (in principle) to use lots of more sophisticated static and dynamic analysis to recover much of what C compiler just assume. You don't have to restrict yourself to what C's type system provides. (For an example of what's possible, have a look at all the great techniques employed to make JavaScript as fast as possible. They have basically no static types to work with at all.)
- masklinn 4y ago
  > For an example of what's possible, have a look at all the great techniques employed to make JavaScript as fast as possible. They have basically no static types to work with at all. I’m sure people will be very happy with a C JIT. That’s definitely what they use C for. JIT-ed code is full of runtime type and range assertions which bail if the compiler’s assumptions are incorrect.
  - eru 4y ago
    Oh, I didn't mean to imply that it would be practical. Only that it's possible and that the type system isn't the only thing you can rely on. Instead of just assuming that 'x > x + 1' is always true (for signed integers), the compiler could also do the heavy lifting of static analysis (for cases where that's possible).
    - littlestymaar 4y ago
      But you talked about JavaScript, where the “heavy lifting” is in fact “assume that it's always true, and switch back a less optimized version if the assumption turns out to be false”. That's exactly the kind of things you cannot do in C, because people use C in contexts were JIT isn't an option.
      - eru 4y ago
        Sorry, my general point and my example didn't perfectly match. For something better matching: have a look at things like Coverity for what you can recover with static analysis of existing C code.
    - Gibbon1 4y ago
      Frankly what I think it we should have a compramize. Make overflow on a signed int defined. Create a new type called unsafe_int where it is not. So then the compiler writers get to implement their pointless optimization pit traps. And everyone else can avoid those by banning unsafe_int.
      - eru 4y ago
        You can already compile with `-fno-strict-overflow` to get twos-complement overflow for signed integers. I meant to talk more abstractly about UB in general.
      - astrange 4y ago
        The signed integer overflow rule is extremely important for common optimizations, mostly related to loops like knowing if they're finite or rewriting their index directions. The way to start getting rid of it would be to add for...in... loops or something where the loop index can be a custom no-overflow type. And "defining" it is a lame approach to safety. If you make it wraparound, you now have silent wraparounds that can't be found by static analysis. You want unintended overflows to trap, not just be defined.
        eru 4y ago

eru 4y ago

> A compiler can’t know why you fucked up, it can’t even know that you fucked up, because UBs are just ways for it to infer and propagate constraints. To be honest, that's just how compiler writers interpret UB these days. It's perfectly possible (in principle) to use lots of more sophisticated static and dynamic analysis to recover much of what C compiler just assume. You don't have to restrict yourself to what C's type system provides. (For an example of what's possible, have a look at all the great techniques employed to make JavaScript as fast as possible. They have basically no static types to work with at all.)

masklinn 4y ago
> For an example of what's possible, have a look at all the great techniques employed to make JavaScript as fast as possible. They have basically no static types to work with at all. I’m sure people will be very happy with a C JIT. That’s definitely what they use C for. JIT-ed code is full of runtime type and range assertions which bail if the compiler’s assumptions are incorrect.
- eru 4y ago
  Oh, I didn't mean to imply that it would be practical. Only that it's possible and that the type system isn't the only thing you can rely on. Instead of just assuming that 'x > x + 1' is always true (for signed integers), the compiler could also do the heavy lifting of static analysis (for cases where that's possible).
  - littlestymaar 4y ago
    But you talked about JavaScript, where the “heavy lifting” is in fact “assume that it's always true, and switch back a less optimized version if the assumption turns out to be false”. That's exactly the kind of things you cannot do in C, because people use C in contexts were JIT isn't an option.
    - eru 4y ago
      Sorry, my general point and my example didn't perfectly match. For something better matching: have a look at things like Coverity for what you can recover with static analysis of existing C code.
  - Gibbon1 4y ago
    Frankly what I think it we should have a compramize. Make overflow on a signed int defined. Create a new type called unsafe_int where it is not. So then the compiler writers get to implement their pointless optimization pit traps. And everyone else can avoid those by banning unsafe_int.
    - eru 4y ago
      You can already compile with `-fno-strict-overflow` to get twos-complement overflow for signed integers. I meant to talk more abstractly about UB in general.
    - astrange 4y ago
      The signed integer overflow rule is extremely important for common optimizations, mostly related to loops like knowing if they're finite or rewriting their index directions. The way to start getting rid of it would be to add for...in... loops or something where the loop index can be a custom no-overflow type. And "defining" it is a lame approach to safety. If you make it wraparound, you now have silent wraparounds that can't be found by static analysis. You want unintended overflows to trap, not just be defined.
      - eru 4y ago