[Bug target/56993] power gcc built 416.gamess generates wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #11 from Richard Biener --- .
[Bug target/56993] power gcc built 416.gamess generates wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 --- Comment #10 from H.J. Lu --- Created attachment 33517 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33517&action=edit Here is my spec 2006 patch I need this patch on x86.
[Bug target/56993] power gcc built 416.gamess generates wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-09-19 Ever confirmed|0 |1 --- Comment #9 from Dominique d'Humieres --- This has already been discussed for gfortran in PR44882 and PR53086 and seems related to PR53265.
[Bug target/56993] power gcc built 416.gamess generates wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 --- Comment #8 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #5) > common /a/ i(10) > subroutine foo (j) > common /a/ i(1) > Is that valid Fortran at all? No. Fortran 2008 (in 5.7.2.5) has: "Named common blocks of the same name shall be of the same size in all scoping units of a program in which they appear" That's not new as FORTRAN 77 (in 8.3.3) had: "Within an executable program, all named common blocks that have the same name must be the same size". The example has a named common block with name "A". Admittedly, that's not really the issue for the wrong code here - as one could simply turn it into a blank common: "but blocks of the same name shall be of the same size in at blank common blocks may be of different sizes." [continuation of F2008 quote]. > call foo (10) > end > subroutine foo (j) > common /a/ i(1) ... > do k = 1, j > l = l + i(k) > > Is that valid Fortran at all? In terms of the standard: No. Fortran 2008 explicitly states: "The value of a subscript in an array element shall be within the bounds for its dimension." (F2008, 6.5.3.) For Fortran 77, I could only find something less explicit: "The first element of the array has a subscript value of one; the second element has a subscript value of two; the last element has a subscript value equal to the size of the array." and "The size of an array is equal to the product of the sizes of the dimensions specified by the array declarator for that array name." Hence, I'd claim that anything but 1 is already invalid in Fortran 77. (Storage associations in general allows some tricks, such as with using EQUIVALENCE (cf. C/C++'s union) but this does not apply here.) In Fortran 66/77, it was alledgedly not uncommon to write "dimension(1)" for dummy/formal arguments - instead of using dimension(*) - and then to access array elements beyond the first one. (Also invalid back then.) However, for COMMON, that's new to me. (Not that I have much experience with pre-Fortran-90 code.) > If Fortran as language allows this, either everywhere, or for compatibility > in some mode, it would be better if such common blocks were modeled similarly > to C99 flexible array members with GNU extension of initializing that; Hmm, the big problem is where to draw a boundary and what to support. As such things were never allowed by the standard, it is difficult to decide what to support and using which flag. In real-world code, one can find tons of code which was invalid but worked - often for years and with different compilers - until it suddenly stopped doing so. It seems as if GCC/gfortran is in particular successful in doing so (judging from bug reports) - which implies that it seems to be better at exploiting optimization opportunities given by the language. A similar use to the one above would be: integer A integer B COMMON /foo/ A(5), B(7) and accessing A(8). That memory reference matches B(3) and is a valid memory address. (Fortran's storage association rules guarantee this.) Still, it exceeds "A" and is hence invalid according to the Fortran standard - and I assume also the middle end does not like A(8). I think for that memory access, the VLA trick wouldn't work. I try to avoid such legacy extensions as they are ill-defined. In any case, gfortran with -fcheck=bounds should reject this at run time - and using a compile-time array index it should do so already at compile time. > From the comments in unport.F, it looks like 416.gamess has commented out > even far uglier hacks, in particular using the COMMON /FPCOM / X(1) and then > when accessing it biasing index by some variable, which is initialized as a > difference between a heap region and the array in the common block. That > would be even worse for the middle-end and C semantics, dunno what Fortran > as language ever allowed and what needs to be (optionally?) tolerated to get > badly written code working. Well, I think in may cases, the early versions of the language - like the Fortran manuals from IBM - simply didn't state what would happen in that case. But back in the old days, for many the standard matched what their compiler did. For instance a loop like "do i = 5, 3": How often is it executed? (Fortran 66 didn't permit it - but one can still write it.) Answer: With some vendors once, with other vendors zero times. I think already Fortran 77 standardized this to execute zero times. As the execute-once version was common, several compilers (including Intel's current one, g77 and others) had a compile-time flag to permit this. (Actually, if I look at the code gfortran generates for a loop, it is written such that once-trip loops could be simply enabled, even though no flag exists to turn it on.) (In reply to Vladimir Makarov from comment #6) > Some SPEC benchmarks contain questionable code. It is true for SPEC2000 > and true for SPEC2006. So the PR is not a surprise for me. > >
[Bug target/56993] power gcc built 416.gamess generates wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #7 from ktkachov at gcc dot gnu.org --- > I'm afraid -fno-aggressive-loop-optimizations is the only thing to do for > such code (and probably more than that). Yeah, I use -fno-aggressive-loop-optimizations on gamess in my runs, I was getting miscompares otherwise
[Bug target/56993] power gcc built 416.gamess generates wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 --- Comment #6 from Vladimir Makarov --- Some SPEC benchmarks contain questionable code. It is true for SPEC2000 and true for SPEC2006. So the PR is not a surprise for me. Unfortunately, nobody from GCC community participates in SPEC org which chooses the benchmarks. Intel is a major player there (besides Sun in the past) and they mostly care only about their compilers. Also in SPEC2006 they made very difficult to change the benchmark code (by checking control sum of the code).
[Bug target/56993] power gcc built 416.gamess generates wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 Jakub Jelinek changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Looking at 416.gamess, I see mess like: $ cat /tmp/a.f90 common /a/ i(10) i(:) = 1 call foo (10) end $ cat /tmp/b.f90 subroutine foo (j) common /a/ i(1) l = 0 do k = 1, j l = l + i(k) end do print *, l end subroutine foo $ gfortran -o /tmp/a /tmp/a.f90 /tmp/b.f90 -O2 -Wall; /tmp/a; gfortran -o /tmp/b /tmp/a.f90 /tmp/b.f90 -O2 -Wall -fno-aggressive-loop-optimizations; /tmp/b; gfortran -o /tmp/c /tmp/a.f90 /tmp/b.f90; /tmp/c 1 10 10 Is that valid Fortran at all? To the middle-end, the array (at the end of) the COMMON block is represented as a structure containing a fixed bound array, so the middle-end (rightfully) thinks that only X(1) is valid, but X(2) and higher are undefined behavior. If Fortran as language allows this, either everywhere, or for compatibility in some mode, it would be better if such common blocks were modeled similarly to C99 flexible array members with GNU extension of initializing that; which is that the type of last RECORD_TYPE's FIELD_DECL should have NULL max bound, and only the VAR_DECL would have size reflecting the actual array size. Of course, only the last array in the COMMON block could be handled this way, if some (broken?) Fortran code still wants say COMMON /XX/ X(1), B, C, D, Y(20) and happily access X(2) as B, X(3) as C, X(4) as D, X(6) as Y(2) etc., then I'm afraid -fno-aggressive-loop-optimizations is the only thing to do for such code (and probably more than that). >From the comments in unport.F, it looks like 416.gamess has commented out even far uglier hacks, in particular using the COMMON /FPCOM / X(1) and then when accessing it biasing index by some variable, which is initialized as a difference between a heap region and the array in the common block. That would be even worse for the middle-end and C semantics, dunno what Fortran as language ever allowed and what needs to be (optionally?) tolerated to get badly written code working.
[Bug target/56993] power gcc built 416.gamess generates wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- I can see this as well; note that adding -fno-aggressive-loop-optimizations helped.
[Bug target/56993] power gcc built 416.gamess generates wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 --- Comment #3 from Carrot --- I don't have a reduced test case. But I have a reduced config file. ### ext = Linux64 backup_config = 0 makeflags = -j64 default=default=default=default: # Set the path that the compiler is located at. CC_PATH = /usr/local/google/carrot/bin/trunkbin/bin CC = $(CC_PATH)/gcc CXX = $(CC_PATH)/g++ FC = $(CC_PATH)/gfortran OPTIMIZE = -O2 -m64 CPORTABILITY = -DSPEC_CPU_LP64 CXXPORTABILITY = -DSPEC_CPU_LP64 FPPPORTABILITY = -DSPEC_CPU_LP64
[Bug target/56993] power gcc built 416.gamess generates wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 --- Comment #2 from Mikael Pettersson --- Can you provide a reduced test case?
[Bug target/56993] power gcc built 416.gamess generates wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 --- Comment #1 from Carrot --- I did some more experimentation on this benchmark. O0/O1 generates correct result, but O2/Os generates wrong result. So the problem should be in some optimization pass that is enabled in O2/Os while disabled in O1.
