Re: Undefined Behavior Optimizations in C

Alexei A. Frounze <alexfrunews@gmail.com> schrieb:


> I believe in a case like this a modern C/C++ compiler reasons that x must be
> less than the maximum representable value and it generates code according
> to this, possibly removing dead code that depends on x being the maximum
> representable value. If the compiler's assumption that x is less than the
> maximum is wrong, it's perfectly fine, it's UB, any "broken" code generated
> is allowed.


There are cases when compilers don't even use this knowledge.


Take the function


int add (int a, int b)
{
        return a+b;
}


on an instruction set architecture which has only 64-bit
arithmetic, such as POWER. This is translated by gcc,
with optimization, to


                add 3,3,4
                extsw 3,3
                blr


(which is an addition followed by a sign extension). The POWER ABi
specifies that all values passed in registers are sign-extended,
so the content of a register has the same value independent of
the width of the signed integer it is being considered as.


So, the compiler would be within its right to _not_ extend the sign
of the result, because it could assume that no overflow occurs.
This, however, would result in a violation of the ABI, so the
compiler puts in the extra instruction just in case. If you
replace int by long in the example above, the sign extension
instruction is not generated.


By comparision, MIPS gcc translates this to


                jr $31
                addu $2,$4,$5


(note use of the delay slot), so no explicit sign extension is done,
and the value returned in the register might have a different value
if interpreted as a 64-bit value.

Return to the comp.compilers page.
Search the comp.compilers archives again.