4 ms·

I'll bite. > int x = cond ? 2 : y; /* Is it legal to fold this to int x = 2; ? */ This is permissible (on typical hardware) only if the implementation choos

by a1369209993 5y ago

I'll bite. > int x = cond ? 2 : y; /* Is it legal to fold this to int x = 2; ? */ This is permissible (on typical hardware) only if the implementation chooses to 'initialize' y to 2 (possibly skipping the actual write if it is later overwritten), since doing otherwise would result in: int x1 = cond1 ? 2 : y; /* So int x1 = 2; */ int x2 = cond2 ? 3 : y; /* So int x2 = 3; */ No, no it may not do that. Edit1: actually, as vyodaiken points out, that's only valid in the first place if y is auto, not static. > Can this be lowered to int y = x; Sure; the compiler is free to implement dereference in a non-trapping manner if possible. > No one uses the result of the load, can I delete it? Yes, it's not volatile. > Can I hoist the load out of the loop? I don't think so; foo might write to z. > Note that all of the optimizations I'm alluding to here are ones that would have existed all the way back in the 1980s when C was being standardized, and these are pretty basic, pedestrian optimizations that you will cover in Compilers 101. Yep, some of the proposed optimizations (x1x2 and hoist) aren't actually available, but they all seem like reasonable things to consider. Edit, missed these: > A function marked _Noreturn returns. If written in C, the body of the function must include a return statement, and is thus a compile time error. If written in assembly, this is no different than overwriting your return address via buffer overflow and ending up in the middle of a function. The compiler should probably stick a trap instruction after the call instruction, though. > Or you alias two pointers marked restrict. `restrict` (formerly noalias) is not valid C[0] (or any language), no matter what the standard says; the compiler must emit a compile time error. 0: https://www.lysator.liu.se/c/dmr-on-noalias.html https://www.lysator.liu.se/c/dmr-on-noalias.html

tom_mellior 5y ago
> This is permissible (on typical hardware) Hardware doesn't define C semantics. C defines C semantics. I don't understand what your conditional example is trying to say, but you seem to assume that an uninitialized y is an actual uninitialized register or memory location. It's not. >> A function marked _Noreturn returns. > If written in C, the body of the function must include a return statement, and is thus a compile time error. It might contain a return statement that is never reached because the function goes into an infinite loop or exits/aborts the program or does a longjmp.
- a1369209993 5y ago
  > Hardware doesn't define C semantics. C defines C semantics. C does not define C sematics for undefined behaviour; that's what makes it undefined behaviour. > an uninitialized y is an actual uninitialized register or memory location. On typical hardware, yes.
  - tom_mellior 5y ago
    >> an uninitialized y is an actual uninitialized register or memory location. > On typical hardware, yes. Maybe you can help me identify the register or memory location for y in your example: https://gcc.godbolt.org/z/3b4z56Y87 https://gcc.godbolt.org/z/3b4z56Y87
    - a1369209993 5y ago
      Link is broken; says: > Without Javascript the regular website is not functional. To go to the noscript version Compiler Explorer click here "click here" goes to https://gcc.godbolt.org/noscript/z/3b4z56Y87 https://gcc.godbolt.org/noscript/z/3b4z56Y87, which has: int choose(int cond1, int cond2) { int y; int x1 = cond1 ? 2 : y; /* So int x1 = 2; */ int x2 = cond2 ? 3 : y; /* So int x2 = 3; */ return x1 + x2; } but no actual assembly. Based on context, I'll speculate that you have found a compiler bug, that the compiler writers will refuse to fix it, and that the varible y has been optimised out because it's unused after constant propagation, regardless of whether said compiler bug causes the constants being propagated to be incorrect.
      - tom_mellior 5y ago
        So on the one hand you're (rightly) saying that this function has no semantics under the rules of the C language, but on the other hand you're saying that the semantics that C compilers assign to it is a bug, and on the third hand you are saying that the hardware should assign semantics to it even though this code is not written in assembly language, so it's not clear what the hardware should assign semantics to? Got it.

tom_mellior 5y ago

> This is permissible (on typical hardware) Hardware doesn't define C semantics. C defines C semantics. I don't understand what your conditional example is trying to say, but you seem to assume that an uninitialized y is an actual uninitialized register or memory location. It's not. >> A function marked _Noreturn returns. > If written in C, the body of the function must include a return statement, and is thus a compile time error. It might contain a return statement that is never reached because the function goes into an infinite loop or exits/aborts the program or does a longjmp.

a1369209993 5y ago
> Hardware doesn't define C semantics. C defines C semantics. C does not define C sematics for undefined behaviour; that's what makes it undefined behaviour. > an uninitialized y is an actual uninitialized register or memory location. On typical hardware, yes.
- tom_mellior 5y ago
  >> an uninitialized y is an actual uninitialized register or memory location. > On typical hardware, yes. Maybe you can help me identify the register or memory location for y in your example: https://gcc.godbolt.org/z/3b4z56Y87 https://gcc.godbolt.org/z/3b4z56Y87
  - a1369209993 5y ago
    Link is broken; says: > Without Javascript the regular website is not functional. To go to the noscript version Compiler Explorer click here "click here" goes to https://gcc.godbolt.org/noscript/z/3b4z56Y87 https://gcc.godbolt.org/noscript/z/3b4z56Y87, which has: int choose(int cond1, int cond2) { int y; int x1 = cond1 ? 2 : y; /* So int x1 = 2; */ int x2 = cond2 ? 3 : y; /* So int x2 = 3; */ return x1 + x2; } but no actual assembly. Based on context, I'll speculate that you have found a compiler bug, that the compiler writers will refuse to fix it, and that the varible y has been optimised out because it's unused after constant propagation, regardless of whether said compiler bug causes the constants being propagated to be incorrect.
    - tom_mellior 5y ago
      So on the one hand you're (rightly) saying that this function has no semantics under the rules of the C language, but on the other hand you're saying that the semantics that C compilers assign to it is a bug, and on the third hand you are saying that the hardware should assign semantics to it even though this code is not written in assembly language, so it's not clear what the hardware should assign semantics to? Got it.