7 ms·

Suggestions like this are unfortunately quite infeasible (they fall under the hat of "define all the behaviors"), and the talk I linked in the post goes into wh

Suggestions like this are unfortunately quite infeasible (they fall under the hat of "define all the behaviors"), and the talk I linked in the post goes into why: https://www.youtube.com/watch?v=yG1OZ69H_-o https://www.youtube.com/watch?v=yG1OZ69H_-o (I'm the post's author.)

naasking 4y ago
He's not trying to define all behaviours, he wants a static assertion that the compiler will compile certain behaviours in a specific way. Seems very different.
- obi1kenobi 4y ago
  That's why I said "falls under the hat of" :) I promise the talk is relevant. `-fwrapv` is an attempt toward doing such a thing for signed integer overflow specifically. I bet it's a pain to maintain because it significantly increases the surface area of the compiler that needs to be tested. I don't believe doing this for more cases is feasible at the level of the compiler. Things like CHERI where the hardware and OS help are much more viable, in my book: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
  - sanxiyn 4y ago
    Signed integer overflow flag is relatively painless to maintain, because compiler needs to be able to track it for unsigned integers anyway. That is, signed integer was modeled with a pair of flags (interpret bits as signed, can't overflow) and unsigned integer (interpret bits as unsigned, wrap on overflow), so signed integer under -fwrapv is just (interpret bits as signed, wrap on overflow).
dooglius 4y ago
I think it's pretty clearly feasible in the specific example GP gave, since -fwrapv does this for GCC and clang. In principle it should be do-able from code level with e.g. 'pragma gcc optimize("frapv")' (but the gcc docs for this say that this feature is for debugging only and doesn't always work).
Mathnerd314 4y ago
"goes into". https://youtu.be/yG1OZ69H_-o?t=1039 https://youtu.be/yG1OZ69H_-o?t=1039 You mean this slide of the Joker with title "Do I really look like the kind of language that would define its behavior?" As far as I can tell there is no reason LLVM couldn't compile a document like "On x86 division by zero throws a #DE exception. On ARM division by zero returns zero. On x86 shifting by more than 32 bits shifts by (cnt mod 32) bits. On ARM shifting by more than 32 bits clears all bits. [...]" that specifies all undefined behavior. The current "nasal demons" behavior is preferred in the name of performance on some SPEC benchmarks that nobody was asking for, screwing OS writers and anyone who expected sane language semantics.
nickitolas 4y ago
Could you elaborate on 13-16? I have no idea what you could possibly mean, and the linked blog post doesn't help. As far as I know UB needs to execute for it to apply and make a program invalid. The linked rust blog post is about how in rust, creating some values in and of itself is UB (It's not that there is unreachable UB later on that uses the invalid value, it's that there was already UB executed earlier in the program in the creation of the invalid value). I know there are some "global" UBs that do not need to "execute" at runtime, but those can simply be thought of as executing at compile time.

naasking 4y ago

He's not trying to define all behaviours, he wants a static assertion that the compiler will compile certain behaviours in a specific way. Seems very different.

obi1kenobi 4y ago
That's why I said "falls under the hat of" :) I promise the talk is relevant. `-fwrapv` is an attempt toward doing such a thing for signed integer overflow specifically. I bet it's a pain to maintain because it significantly increases the surface area of the compiler that needs to be tested. I don't believe doing this for more cases is feasible at the level of the compiler. Things like CHERI where the hardware and OS help are much more viable, in my book: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
- sanxiyn 4y ago
  Signed integer overflow flag is relatively painless to maintain, because compiler needs to be able to track it for unsigned integers anyway. That is, signed integer was modeled with a pair of flags (interpret bits as signed, can't overflow) and unsigned integer (interpret bits as unsigned, wrap on overflow), so signed integer under -fwrapv is just (interpret bits as signed, wrap on overflow).

dooglius 4y ago

I think it's pretty clearly feasible in the specific example GP gave, since -fwrapv does this for GCC and clang. In principle it should be do-able from code level with e.g. 'pragma gcc optimize("frapv")' (but the gcc docs for this say that this feature is for debugging only and doesn't always work).

Mathnerd314 4y ago

"goes into". https://youtu.be/yG1OZ69H_-o?t=1039 https://youtu.be/yG1OZ69H_-o?t=1039 You mean this slide of the Joker with title "Do I really look like the kind of language that would define its behavior?" As far as I can tell there is no reason LLVM couldn't compile a document like "On x86 division by zero throws a #DE exception. On ARM division by zero returns zero. On x86 shifting by more than 32 bits shifts by (cnt mod 32) bits. On ARM shifting by more than 32 bits clears all bits. [...]" that specifies all undefined behavior. The current "nasal demons" behavior is preferred in the name of performance on some SPEC benchmarks that nobody was asking for, screwing OS writers and anyone who expected sane language semantics.

nickitolas 4y ago

Could you elaborate on 13-16? I have no idea what you could possibly mean, and the linked blog post doesn't help. As far as I know UB needs to execute for it to apply and make a program invalid. The linked rust blog post is about how in rust, creating some values in and of itself is UB (It's not that there is unreachable UB later on that uses the invalid value, it's that there was already UB executed earlier in the program in the creation of the invalid value). I know there are some "global" UBs that do not need to "execute" at runtime, but those can simply be thought of as executing at compile time.