Re: Undefined Behavior Optimizations in C

On Friday, January 6, 2023 at 10:49:59 AM UTC-8, gah4 wrote:


(snip)


> 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 way Fortran did static allocation in 1977,
> there was pretty much no chance that you would access outside
> your address space evaluating X(0). There is a chance, though,
> that the value 3 is stored there.


(snip)


> [Both Fortran 66 and 77 could do short-circuit evaluation, but it's
> not required. I think most compilers did, since it was easy, but
> of course you couldn't count on it. -John]


Sorry, yes, you can't count on it.


But if you can't count on it, then you can't use it in standard programs.


But now that you mention it, I was compiling this last year with
gfortran, and ran into those, so it wasn't doing it. At least it wasn't
doing all of them. I would run the program with bounds check on,
and see where it failed.


Reminds me, though, of another one from years ago.


          DO 11 I=l,10
          DO 12 J=l,10
          IF (B(I}.LT.0.)GO TO 11
12 C(J)=SQRT(B(I)}
11 CONTINUE


comes from an IBM manual explaining the Fortran H optimizations.
It seems that the optimizer can move the SQRT out of the inner loop,
but not the test on B(I). This is actually documented, so isn't UB
anymore. (Well, not IBM UB.)


That is in an IBM manual from 1973.
[It's on page 65 of this 1967 edition. I guess they did data flow but not control flow.
http://bitsavers.org/pdf/ibm/360/fortran/C28-6602-3_OS_FORTRAN_IV_H_Programmers_Guide_1967.pdf
-John]

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