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).
