Re: Undefined Behavior Optimizations in C

On Wednesday, January 18, 2023 at 3:55:49 PM UTC-8, David Brown wrote:


(snip)


> So if you have :
>
> int x, y;
>
> if (x + 1 > x) y++; // (a)
> if (x == INT_MAX) y = 10; // (b)


> From your example above, we can see that the compiler can transform (a)
> into "y++;" - there is no need for the conditional. But the compiler
> can /also/ transform (b) into ";" - it is allowed to reason that if x
> /were/ equal to INT_MAX, statement (a) would be undefined behaviour
> (even though it was transformed away) and there is no value for x which
> would result in "y = 10" being executed without also executing UB.


I am now wondering both how well compilers do this, and how well
people do this.


Note that the only case where, on all machines I use, the y++ is
not executed, is when x==INT_MAX. Now, it would be completely
different for:


if(x + 2 > x) y++; (a)


or


if(x == INT_MAX) y--;


For many years, C allowed for sign-magnitude and ones' complement
representation. Fixed point overflow was, then, at least machine
dependent as they overflow differently. Some machines have the
ability to enable an interrupt on fixed point overflow, but at least
for Fortran and C, it is normally disabled.


Now, C has unsigned int which you can use when you need specific
overflow behavior (except on some Unisys machines). Fortran does not,
and so people expect, and depend, on two's complement overflow. (The
Fortran standard allows for any integer radix greater than one, and
also for different sign representations. But often enough, people know
it is two's complement binary.)


As C allows for both UB and system-dependent behavior, and it is
hard for people to remember every case of each one, it is unreasonable
to me, to assume fixed point overflow is UB.


Dereference of pointers that might point to the wrong place, maybe.


The reason for the Fortran example above, mentioning short circuit
IF statements, was that Fortran programs, at least with IBM compilers,
could reliably fetch from element 0 of an array. With static allocation,
and data stored after code, there was no chance of element 0 being
outside the address space. Yes people shouldn't rely on it,
but sometimes they did.


Storing outside an array often enough leads to problems, but fetch
much less often.

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