4 ms·

Im a member of the wg14 and the Undefined beahviour study group. We are producinga technical rapport about UB and one thing we specificly point out is that stat

Im a member of the wg14 and the Undefined beahviour study group. We are producinga technical rapport about UB and one thing we specificly point out is that staticly known UB should be treated as an error, not as "this cant be called" aka "unreachable". From what i have seen LLVM sometimes issues poison when it should just issue an error. The implications can be quite severe. Instead of assuming that a UB is programmer error, it assumes its the intention of the programer that the code will never run, therfor it can use this information to make assumptions about branching behaviour.

pornel 2y ago
UB is a guaranteed compilation error in constexpr. However, in regular code UB may only become known after multiple optimization passes (e.g. constant propagation, inlining). It's difficult for the optimizer to meaningfully err at that time. The code may have been heavily modified by other optimization passes, which can add UB to the code (e.g. UB may have been data-dependent (1/x), but optimizer added a specialized copy of a function for x=0 where it became unconditional). The IR may have been generated by a non-C language that used UB/poison intentionally to guide optimizations.
JonChesterfield 2y ago
Undefined behaviour is the reason I can't use ISO C to do anything sensible in the domains of embedded programming or language implementation. Those are the exact domains that gcc with a lot of flags to disable the WG14 inventions excels at. I don't need static warnings that the compiler refused to do what I asked it to. I need the 'UB means arbitrary transforms of your code with a bias towards deletion' invention to go away. It's a dubious premise in C++ where it supports people writing clumsy application code. It's totally inappropriate for things like implementing a JIT.
- titzer 2y ago
  Pretty much all interesting low-level systems stuff is UB in C/C++ and has been for years. That's dumb. The reason we need low-level systems stuff is to bit-bang on hardware; put data in hardware formats; look at the low-level representation of things that we "shouldn't"--like integers, floats, objects, structs, stack frames; and implement the language runtime itself. The intent is usually pretty clear from what's written, and the mental model of the systems programmer is "I know I need to make the hardware do this thing". Compilers optimizing away UB and otherwise treating it as never going to happen actively get in the way. UB makes a systems language not a systems language anymore.
  - atiedebee 2y ago
    In my experience, the majority of behaviour you actually want to use is implementation defined as opposed to UB.
    - titzer 2y ago
      No, I really want to point into the stack and walk stack frames, look at the guts of objects, arrays, map memory, forge pointers to new code (because I wrote a JIT compiler), etc. That is brazen UB in C/C++ and compilers will do horrible things to you. See for example: https://github.com/titzer/virgil/blob/master/doc/tutorial/Ranges.md#off-heap-ranges https://github.com/titzer/virgil/blob/master/doc/tutorial/Ra...
      - gpderetta 2y ago
        If you really want guaranteed frame/stack layout I don't think there is any other way than writing your own compiler/IR. No optimizing compiler written in the last 50 years will give you such a guarantee. If you "just" want introspection, that's a little bit more reasonable; in principle something like dwarf unwind info could be extended for that. But, a) that a lot of work for an extremely niche problem and b) there is no guarantee that the in-memory representation of objects is stable at instruction boundaries, I think you would need something like GC write barriers.
        Gibbon1 2y ago
        With C there is the ABI which is platform specific but can't change without all hell breaking loose. Also after twenty terrible years for profilers frame pointer are returning. So the ABI allows you to do this sort of stuff reliably as long as the compiler isn't doing inane things with UB.
        gpderetta 2y ago
        The ABI doesn't mandate were locals are located on a stack frame thought so I'm not sure how would you inspect those. If you simply meant that you want rely on an ABI, then that's fine, although relying on those details might be UB for standard conforming code, it is obviously well defined for compilers that conform to the ABI. Just because it is undefined from a standard point of view, doesn't mean is still undefined for a specific compiler + platform. You will still need to use compilation firewalls and barriers to avoid aliasing or pointer provenance issues of course.
- rurban 2y ago
  I would be even fine with dead-code deletion when it carries a warning. But currently all dangerous UB decisions are totally silent, which is a nightmare

pornel 2y ago

UB is a guaranteed compilation error in constexpr. However, in regular code UB may only become known after multiple optimization passes (e.g. constant propagation, inlining). It's difficult for the optimizer to meaningfully err at that time. The code may have been heavily modified by other optimization passes, which can add UB to the code (e.g. UB may have been data-dependent (1/x), but optimizer added a specialized copy of a function for x=0 where it became unconditional). The IR may have been generated by a non-C language that used UB/poison intentionally to guide optimizations.

JonChesterfield 2y ago

Undefined behaviour is the reason I can't use ISO C to do anything sensible in the domains of embedded programming or language implementation. Those are the exact domains that gcc with a lot of flags to disable the WG14 inventions excels at. I don't need static warnings that the compiler refused to do what I asked it to. I need the 'UB means arbitrary transforms of your code with a bias towards deletion' invention to go away. It's a dubious premise in C++ where it supports people writing clumsy application code. It's totally inappropriate for things like implementing a JIT.

titzer 2y ago
Pretty much all interesting low-level systems stuff is UB in C/C++ and has been for years. That's dumb. The reason we need low-level systems stuff is to bit-bang on hardware; put data in hardware formats; look at the low-level representation of things that we "shouldn't"--like integers, floats, objects, structs, stack frames; and implement the language runtime itself. The intent is usually pretty clear from what's written, and the mental model of the systems programmer is "I know I need to make the hardware do this thing". Compilers optimizing away UB and otherwise treating it as never going to happen actively get in the way. UB makes a systems language not a systems language anymore.
- atiedebee 2y ago
  In my experience, the majority of behaviour you actually want to use is implementation defined as opposed to UB.
  - titzer 2y ago
    No, I really want to point into the stack and walk stack frames, look at the guts of objects, arrays, map memory, forge pointers to new code (because I wrote a JIT compiler), etc. That is brazen UB in C/C++ and compilers will do horrible things to you. See for example: https://github.com/titzer/virgil/blob/master/doc/tutorial/Ranges.md#off-heap-ranges https://github.com/titzer/virgil/blob/master/doc/tutorial/Ra...
    - gpderetta 2y ago
      If you really want guaranteed frame/stack layout I don't think there is any other way than writing your own compiler/IR. No optimizing compiler written in the last 50 years will give you such a guarantee. If you "just" want introspection, that's a little bit more reasonable; in principle something like dwarf unwind info could be extended for that. But, a) that a lot of work for an extremely niche problem and b) there is no guarantee that the in-memory representation of objects is stable at instruction boundaries, I think you would need something like GC write barriers.
      - Gibbon1 2y ago
        With C there is the ABI which is platform specific but can't change without all hell breaking loose. Also after twenty terrible years for profilers frame pointer are returning. So the ABI allows you to do this sort of stuff reliably as long as the compiler isn't doing inane things with UB.
        gpderetta 2y ago
        The ABI doesn't mandate were locals are located on a stack frame thought so I'm not sure how would you inspect those. If you simply meant that you want rely on an ABI, then that's fine, although relying on those details might be UB for standard conforming code, it is obviously well defined for compilers that conform to the ABI. Just because it is undefined from a standard point of view, doesn't mean is still undefined for a specific compiler + platform. You will still need to use compilation firewalls and barriers to avoid aliasing or pointer provenance issues of course.
rurban 2y ago
I would be even fine with dead-code deletion when it carries a warning. But currently all dangerous UB decisions are totally silent, which is a nightmare