[Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 Bug #: 52117 Summary: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sphirsh...@yahoo.com This snippet of code gives incorrect results for the reshaped array. If the arrays are NOT allocated, but explicitly dimensioned, the correct result is obtained. + PROGRAM RESHAPEIT INTEGER, PARAMETER :: n1=2, n2=2, n3=2 INTEGER:: m1, m2, m3, lc REAL, ALLOCATABLE :: A(:,:), B(:,:,:) REAL :: val ALLOCATE (A(n1,n2*n3), B(n1,n2,n3)) ! INITIALIZE A val = 0 lc = 0 DO m3=1,n3 DO m2=1,n2 lc = lc+1 DO m1=1,n1 val = val+1 A(m1, lc) = val END DO END DO END DO B = RESHAPE(A, SHAPE(B)) lc = 0 DO m3=1,n3 DO m2=1,n2 lc = lc+1 DO m1=1,n1 PRINT *,'A(',m1,',',lc,') = ',A(m1,lc),' B = ',B(m1,m2,m3) END DO END DO END DO DEALLOCATE(A, B) PAUSE END PROGRAM RESHAPEIT ++
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #2 from steven hirshman 2012-02-06 15:37:35 UTC --- Thank you for the information. THe work-around works with the newer (4.6.2) compiler, but is unrecognized by older versions of gcc that are in use on - for example - NERSC computers. Is there a FIX other than the workaround planned, that will be backwards compatible with older compilers? Also, the B(:) fails on some platforms, I'm told by some of my co-workers. From: burnus at gcc dot gnu.org To: sphirsh...@yahoo.com Sent: Friday, February 3, 2012 3:41 PM Subject: [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 Tobias Burnus changed: What |Removed |Added Status|UNCONFIRMED |RESOLVED CC| |burnus at gcc dot gnu.org Resolution| |DUPLICATE --- Comment #1 from Tobias Burnus 2012-02-03 20:41:32 UTC --- Work around: -fno-realloc-lhs Or add "(:)" B(:) = RESHAPE(A, SHAPE(B)) Solution: Update - it has just been fixed in the last days. Thanks for the report! *** This bug has been marked as a duplicate of bug 52012 ***
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #4 from steven hirshman 2012-02-06 19:45:53 UTC --- Thanks. I tried the -std=f95 flag and it gave the same (wrong) answer as without it, in the test code I sent you. What is not Fortran95 compatible with the code snippet I sent you? From: burnus at gcc dot gnu.org To: sphirsh...@yahoo.com Sent: Monday, February 6, 2012 12:45 PM Subject: [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #3 from Tobias Burnus 2012-02-06 17:45:36 UTC --- (In reply to comment #2) > Thank you for the information. THe work-around works with the newer (4.6.2) > compiler, but is unrecognized by older versions of gcc that are in use on > - for example - NERSC computers. Well, the bug is related to (re)allocation on assignment (a Fortran 2003 features), which is new in GCC 4.6. Thus, both the flag -f(no-)realloc-lhs but also the bug is only in GCC 4.6 (and 4.7). You could also use "-std=f95", which implies -fno-realloc-lhs with GCC 4.6/4.7 but is also supported in older gfortrans; however, you need to have a code which follows Fortran 95 close enough to be compilable with that flag. > Is there a FIX other than the workaround planned, that will be backwards > compatible with older compilers? The actual bug has been fixed on both the GCC 4.6 branch (on 2012-02-03) and on the GCC 4.7 trunk (on 2012-02-02). Thus, if you have a newer version of GCC 4.6/4.7, you are also not affected. (Cf. the nightly build from http://gcc.gnu.org/wiki/GFortranBinaries ) See bug 52012 for details. > Also, the B(:) fails on some platforms, I'm told by some of my co-workers. Can you provides more details? Using "B(:) =" prevents the (re)allocation of the left-hand side and thus it should also prevent the bug. In particular: - How does it fail? At compile time? At run time? With which error? - Which version/platform of the compiler are you using? - Is that with the code of comment 0 with only "B = RESHAPE..." changed to "B(:) = RESHAPE..." or is it for some other code?
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #8 from steven hirshman 2012-02-07 16:18:33 UTC --- Thank you. I didn't catch the PAUSE problem. It now runs correctly with the -std=f95 flag, which is what we'll use. Thanks for your helpful responses. From: burnus at gcc dot gnu.org To: sphirsh...@yahoo.com Sent: Tuesday, February 7, 2012 9:36 AM Subject: [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #7 from Tobias Burnus 2012-02-07 14:36:48 UTC --- (In reply to comment #6) > It compiles/links with the -std:f95 flag, but gives the same wrong results > [qsh@swim SIESTA]$ gfortran -std=f95 reshape.f90 > reshape.f90:37.11: > PAUSE > 1 > Error: Deleted feature: PAUSE statement at (1) > [qsh@swim SIESTA]$ a.out Well, you do not use -std=f95: As the compilation fails with an "ERROR", thus no new "a.out" file is produced. If you then start "a.out", a previously compiled file is used. > (did not change B to B(:,:,:) since that is not a practical solution for us, > lots of reshapes in our code In Fortran 2003, an allocatable (array) on the LHS is automatically allocated (if unallocated) or reallocated (if the shape does not match). Unfortunately, the implementation had a bug, which could appear if the RHS consisted of only a call to an intrinsic function, located the run-time library (libgfortran). Unless you provide me with a time machine, there are only two choices: Avoiding a gfortran version with that bug by using a newer/older version. Or avoiding the (re)allocation on assignment using either compiler flags or modifying the code. The only solutions, I see, which do not require code changes are: - Use any GCC version before GCC 4.6.0; for instance GCC 4.5.x - Use GCC 4.6 older than 2010-11-28 - Use a GCC (any version) newer than 2012-02-03 - Use -fno-realloc-lhs (caveat: Flag not supported before GCC 4.6) - Use -std=f95 (caveat: Requires that the code compiles without error with -std=f95) I personally would use -fno-realloc-lhs [also due to performance reasons] and/or an compiler version without the bug. For completeness, also the following code changes are possible; except for the first one, they are not recommended: - Use an array spec for allocatable LHS, e.g. "B(:,:,:) = " - Don't use allocatables left of " = RESHAPE" - Make the expression on the RHS more complicated: add "+ 0" or surround with "( )". The first solution ("B(:,:,:) = ") has the advantage that it avoids additional checks whether the LHS is allocated and have the correct shape. With Fortran 2003/2008 compilers, adding it improves the performance minutely - and in hot loops it might even matter. That's the reason that gfortran has -fno-realloc-lhs, but also that other compiles have similar flags such as "-assume norealloc_lhs" or "-e w".
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #9 from steven hirshman 2012-02-10 20:00:47 UTC --- Tobias We have a problem in v4.6.2 with the following (using the std=f95 flag): There seems to have been a limitation in past versions of gfortran with allocatable components inside derived types. It was supposed to have been fixed, and should be no more a compiler bug. It is valid (language-legal) fortran 95 and 2003, so must be a compiler limitation or compiler bug. Other compiles are fine as well (g95, ifort, etc.). Do you know if this has indeed been fixed? From: burnus at gcc dot gnu.org To: sphirsh...@yahoo.com Sent: Friday, February 3, 2012 3:41 PM Subject: [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 Tobias Burnus changed: What |Removed |Added Status|UNCONFIRMED |RESOLVED CC| |burnus at gcc dot gnu.org Resolution| |DUPLICATE --- Comment #1 from Tobias Burnus 2012-02-03 20:41:32 UTC --- Work around: -fno-realloc-lhs Or add "(:)" B(:) = RESHAPE(A, SHAPE(B)) Solution: Update - it has just been fixed in the last days. Thanks for the report! *** This bug has been marked as a duplicate of bug 52012 ***
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #12 from steven hirshman 2012-02-11 12:08:02 UTC --- Thank you for your reply. I'll check with my coworker about that. From: burnus at gcc dot gnu.org To: sphirsh...@yahoo.com Sent: Saturday, February 11, 2012 6:40 AM Subject: [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #11 from Tobias Burnus 2012-02-11 11:40:36 UTC --- (In reply to comment #9) > We have a problem in v4.6.2 with the following (using the std=f95 flag): > There seems to have been a limitation in past versions of gfortran with > allocatable components inside derived types. Allocatable components in derived types is not allowed in Fortran 95 - it has only been later added as Technical Report (TR) 15581 and it is part of Fortran 2003. Thus, the flag -std=f95 does not work if you need allocatable components. Hence, you have to choose one of the other options listed as comment #7: > Unless you provide me with a time machine [...] > The only solutions, I see, which do not require code changes are: > > - Use any GCC version before GCC 4.6.0; for instance GCC 4.5.x > - Use GCC 4.6 older than 2010-11-28 > - Use a GCC (any version) newer than 2012-02-03 > - Use -fno-realloc-lhs (caveat: Flag not supported before GCC 4.6) > - Use -std=f95 (caveat: Requires that the code compiles without error with > -std=f95) > > I personally would use -fno-realloc-lhs [...] > > For completeness, also the following code changes are possible; except for > the first one, they are not recommended: > > - Use an array spec for allocatable LHS, e.g. "B(:,:,:) = " > - Don't use allocatables left of " = RESHAPE" > - Make the expression on the RHS more complicated: add "+ 0" or surround with > "( )".