[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368

--- Comment #63 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #59)
> > We already warn about mismatches sizes at LTO link time
> 
> Confirmed
> 
> [Book15] f90/bug% gfc -c -O2 pr69368_a.f90 -flto
> [Book15] f90/bug% gfc -O2 pr69368_a.o pr69368_b.f90 -flto
> pr69368_a.f90:3:0: warning: type of 'blk' does not match original
> declaration [-Wlto-type-mismatch]
>        COMMON /BLK/ K(1)
>  
> pr69368_b.f90:3:0: note: 'blk' was previously declared here
>        COMMON /BLK/ K(64)
>  
> pr69368_b.f90:3:0: note: code may be misoptimized unless
> -fno-strict-aliasing is used
> 
> and the executable gives the expected output. IMO the second note is bogus
> (pr68717).
> 
> If I replace
> 
>        COMMON /BLK/ K(1)
> 
> with
> 
>        COMMON /BLK/ K(2)
> 
> the executable gives the expected output also for all the compiling options
> I have tried.
> 
> AFAICT the code (invalid for any value of I and J)
> 
>       FUNCTION FOO(I, J)
>       COMMON /BLK/ K(1)
>       FOO = K(I) + K(J) + K(2*I) + K(2*J)
>       END FUNCTION
> 
> is optimized as
> 
>       FOO = K(I) + K(I) + K(I) + K(I)
> 
> Although I know that a compiler can do whatever it deems suitable with
> invalid code, I don't understand the rationale of the above "optimization":
> it is as invalid as the original code.

There is obviously no "rationale".  Fact is that we don't exploit the
undefinedness explicitely but just as a side-effect of how CSE works in
DOM now.  This means we don't propagate '1' as the only valid value of I
but just CSE the last three loads to the first as we know they are the
same (without knowing the actual value).

> Another thing I don't understand is that the following code is not
> "optimized" while as invalid as the one above:
> 
>       INTEGER FUNCTION FOO(I, J, K)
>       INTEGER K(1)
>       FOO = K(I) + K(J) + K(2*I) + K(2*J)
>       END FUNCTION
> 
>       INTEGER FOO
>       INTEGER K(64)
>       DO I=1,64
>       K(I)=I
>       END DO
>       IF (FOO(5,12,K).NE.51) CALL ABORT
>       END

Sth to do with K being passed as a pointer and thus K being treated as
a "flexible array" (we can't know whether the caller passed the address
of a last member of a struct).