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.
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.
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.
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.