Why are these constructs using pre and post-increment undefined behavior?

C has the concept of undefined behavior, i.e. some language constructs are syntactically valid but you can't predict the behavior when the code is run.

As far as I know, the standard doesn't explicitly say why the concept of undefined behavior exists. In my mind, it's simply because the language designers wanted there to be some leeway in the semantics, instead of i.e. requiring that all implementations handle integer overflow in the exact same way, which would very likely impose serious performance costs, they just left the behavior undefined so that if you write code that causes integer overflow, anything can happen.

So, with that in mind, why are these "issues"? The language clearly says that certain things lead to undefined behavior. There is no problem, there is no "should" involved. If the undefined behavior changes when one of the involved variables is declared volatile, that doesn't prove or change anything. It is undefined; you cannot reason about the behavior.

Your most interesting-looking example, the one with

u = (u++);

is a text-book example of undefined behavior (see Wikipedia's entry on sequence points).

Just compile and disassemble your line of code, if you are so inclined to know how exactly it is you get what you are getting.

This is what I get on my machine, together with what I think is going on:

$ cat evil.cvoid evil(){  int i = 0;  i+= i++ + ++i;}$ gcc evil.c -c -o evil.bin$ gdb evil.bin(gdb) disassemble evilDump of assembler code for function evil:   0x00000000 <+0>:   push   %ebp   0x00000001 <+1>:   mov    %esp,%ebp   0x00000003 <+3>:   sub    $0x10,%esp   0x00000006 <+6>:   movl   $0x0,-0x4(%ebp)  // i = 0   i = 0   0x0000000d <+13>:  addl   $0x1,-0x4(%ebp)  // i++     i = 1   0x00000011 <+17>:  mov    -0x4(%ebp),%eax  // j = i   i = 1  j = 1   0x00000014 <+20>:  add    %eax,%eax        // j += j  i = 1  j = 2   0x00000016 <+22>:  add    %eax,-0x4(%ebp)  // i += j  i = 3   0x00000019 <+25>:  addl   $0x1,-0x4(%ebp)  // i++     i = 4   0x0000001d <+29>:  leave     0x0000001e <+30>:  retEnd of assembler dump.

(I... suppose that the 0x00000014 instruction was some kind of compiler optimization?)

I think the relevant parts of the C99 standard are 6.5 Expressions, §2

Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.

and 6.5.16 Assignment operators, §4:

The order of evaluation of the operands is unspecified. If an attempt is made to modify the result of an assignment operator or to access it after the next sequence point, the behavior is undefined.