Re: Undefined Behavior Optimizations in C

On Fri, 6 Jan 2023 10:33:29 -0800 (PST)
gah4 <gah4@u.washington.edu> wrote:
> It turns out, though, to have a fair number of statements like:
>
> IF(I.GT.0.AND.X(I).EQ.3) ...
>
> That is, test the subscript and use it in the same IF statement.
>
> Now, this would not be a problem at all in C, with short-circuit IF
> evaluation required, but even now Fortran doesn't do short
> circuit IF evaluation. ...


The analogous C code would be
        if (I > 0 && X[I] == 3) ...


.A C compiler would be "entitled" to ignore the I > 0 test if I has not
been initialised. If the array X has not been initialised or if it only has 1
element (so only X[0] is meaningful) then a C compiler could treat the
whole (I > 0 && X[I] == 3) expression as always false and not emit any code
for it. I don't know if these are the scenarios you have in mind when you say
"is one of the UB that C compilers do". In the first scenario the code would
be meaningless even from a human point of view. In scenarios 2 and 3 , the
code is meaningful if I is 0 when the expression is reached but then there
would be no need for the tests so the code would almost certainly have a bug.
So I find the behaviour of the C compilers perfectly intuitive regardless of
whether it produces a speed-up. If I is unitialised then likely you would
get a warning. For the other 2 scenarios , I'm not sure you would even if the C
compiler does something special like treat the expression as always false. A
warning would always be nice but I've heard it is hard to achieve , I think
because by the time in the compilation process certain optimisations are made
, the original code has been transformed too much for the compiler to make
the connection with some specific point in the source code.


[I'm pretty sure I don't want to use a C compiler that says aha, I know that
this code is buggy, so I will silently throw it away. -John]

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