public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
@ 2012-02-03 20:32 sphirshman at yahoo dot com
  2012-02-03 20:43 ` [Bug fortran/52117] " burnus at gcc dot gnu.org
                   ` (11 more replies)
  0 siblings, 12 replies; 13+ messages in thread
From: sphirshman at yahoo dot com @ 2012-02-03 20:32 UTC (permalink / raw)
  To: gcc-bugs

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: unassigned@gcc.gnu.org
        ReportedBy: sphirshman@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
++++++++++++++++++++++++++++++++++++++++++++++++++++++


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
  2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
@ 2012-02-03 20:43 ` burnus at gcc dot gnu.org
  2012-02-06 15:38 ` sphirshman at yahoo dot com
                   ` (10 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-02-03 20:43 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |burnus at gcc dot gnu.org
         Resolution|                            |DUPLICATE

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 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 ***


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
  2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
  2012-02-03 20:43 ` [Bug fortran/52117] " burnus at gcc dot gnu.org
@ 2012-02-06 15:38 ` sphirshman at yahoo dot com
  2012-02-06 17:47 ` burnus at gcc dot gnu.org
                   ` (9 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: sphirshman at yahoo dot com @ 2012-02-06 15:38 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117

--- Comment #2 from steven hirshman <sphirshman at yahoo dot com> 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 <gcc-bugzilla@gcc.gnu.org>
To: sphirshman@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 <burnus at gcc dot gnu.org> changed:

          What    |Removed                    |Added
----------------------------------------------------------------------------
            Status|UNCONFIRMED                |RESOLVED
                CC|                            |burnus at gcc dot gnu.org
        Resolution|                            |DUPLICATE

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 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 ***


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
  2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
  2012-02-03 20:43 ` [Bug fortran/52117] " burnus at gcc dot gnu.org
  2012-02-06 15:38 ` sphirshman at yahoo dot com
@ 2012-02-06 17:47 ` burnus at gcc dot gnu.org
  2012-02-06 19:47 ` sphirshman at yahoo dot com
                   ` (8 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-02-06 17:47 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 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?


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
  2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
                   ` (2 preceding siblings ...)
  2012-02-06 17:47 ` burnus at gcc dot gnu.org
@ 2012-02-06 19:47 ` sphirshman at yahoo dot com
  2012-02-06 20:02 ` burnus at gcc dot gnu.org
                   ` (7 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: sphirshman at yahoo dot com @ 2012-02-06 19:47 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117

--- Comment #4 from steven hirshman <sphirshman at yahoo dot com> 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 <gcc-bugzilla@gcc.gnu.org>
To: sphirshman@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 <burnus at gcc dot gnu.org> 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?


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
  2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
                   ` (3 preceding siblings ...)
  2012-02-06 19:47 ` sphirshman at yahoo dot com
@ 2012-02-06 20:02 ` burnus at gcc dot gnu.org
  2012-02-07 11:44 ` hirshmansp at ornl dot gov
                   ` (6 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-02-06 20:02 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-06 20:01:15 UTC ---
(In reply to comment #4)
> 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?

I works for me both with GCC 4.6 and GCC 4.7 both with the current version but
also with a version which still had bug 52012.

Can you please answer the following question? You only kind of answered the
third question, namely that you used the original program (of comment 0).
Additional, could you provide more information about the version you used
("gfortran -v"), of interest are the complete of "Target" and of "gcc version".


(In reply to comment #3)
> Can you provides more details?
> 
> 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?


Example on my system for a 4.6 version which has still the bug:

$ gfortran-4.6 -v |& grep -E 'gcc version|Target'
Target: x86_64-suse-linux
gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) 

$ gfortran-4.6 -std=f95 test.f90 
test.f90:37.11:
      PAUSE
           1
Error: Deleted feature: PAUSE statement at (1)

And after commenting that line:

$ gfortran-4.6 -std=f95 test.f90
 A(           1 ,           1 ) =    1.00000000      B =    1.00000000    
 A(           2 ,           1 ) =    2.00000000      B =    2.00000000    
 A(           1 ,           2 ) =    3.00000000      B =    3.00000000    
 A(           2 ,           2 ) =    4.00000000      B =    4.00000000    
 A(           1 ,           3 ) =    5.00000000      B =    5.00000000    
 A(           2 ,           3 ) =    6.00000000      B =    6.00000000    
 A(           1 ,           4 ) =    7.00000000      B =    7.00000000    
 A(           2 ,           4 ) =    8.00000000      B =    8.00000000    

The output looks correct and is the same as with other compilers. However, if I
use the buggy version of the compiler without -std=f95, I get:

$ gfortran-4.6 hj4.f90  && ./a.out 
 A(           1 ,           1 ) =    1.00000000      B =    3.00000000    
 A(           2 ,           1 ) =    2.00000000      B =    4.00000000    
 A(           1 ,           2 ) =    3.00000000      B =    5.00000000    
 A(           2 ,           2 ) =    4.00000000      B =    6.00000000    
 A(           1 ,           3 ) =    5.00000000      B =    7.00000000    
 A(           2 ,           3 ) =    6.00000000      B =    8.00000000    
 A(           1 ,           4 ) =    7.00000000      B =    3.36311631E-44
 A(           2 ,           4 ) =    8.00000000      B =    9.62964972E-35


As written, using "(:)" - or to be more precise (it's a rank-3 array) -
"B(:,:,:) = ", -fno-realloc-lhs, or a newer version of the compiler solves the
problem as well.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
  2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
                   ` (4 preceding siblings ...)
  2012-02-06 20:02 ` burnus at gcc dot gnu.org
@ 2012-02-07 11:44 ` hirshmansp at ornl dot gov
  2012-02-07 14:37 ` burnus at gcc dot gnu.org
                   ` (5 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: hirshmansp at ornl dot gov @ 2012-02-07 11:44 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117

--- Comment #6 from hirshmansp at ornl dot gov 2012-02-07 11:43:29 UTC ---
Tobias

Here are the answers to your questions:


[qsh@swim SIESTA]$ gfortran -v|&grep -E 'gcc version|Target'

Target: x86_64-redhat-linux

gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)


It compiles/links with the -std:f95 flag, but gives the same wrong results (did
not change B to B(:,:,:) since that is not a practical solution for us, lots of
reshapes in our code:



[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

A(           1 ,           1 ) =    1.0000000      B =    3.0000000

A(           2 ,           1 ) =    2.0000000      B =    4.0000000

A(           1 ,           2 ) =    3.0000000      B =    5.0000000

A(           2 ,           2 ) =    4.0000000      B =    6.0000000

A(           1 ,           3 ) =    5.0000000      B =    7.0000000

A(           2 ,           3 ) =    6.0000000      B =    8.0000000

A(           1 ,           4 ) =    7.0000000      B =    0.0000000

A(           2 ,           4 ) =    8.0000000      B =    0.0000000

PAUSE

From: Steven Hirshman [mailto:sphirshman@yahoo.com]
Sent: Monday, February 06, 2012 8:02 PM
To: Hirshman, Steven Paul
Subject: Fw: [Bug fortran/52117] allocated arrays give incorrect results when
used with RESHAPE in gcc v4.6.2



----- Forwarded Message -----
From: burnus at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
To: sphirshman@yahoo.com
Sent: Monday, February 6, 2012 3:01 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 #5 from Tobias Burnus <burnus at gcc dot gnu.org<http://gnu.org/>>
2012-02-06 20:01:15 UTC ---
(In reply to comment #4)
> 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?

I works for me both with GCC 4.6 and GCC 4.7 both with the current version but
also with a version which still had bug 52012.

Can you please answer the following question? You only kind of answered the
third question, namely that you used the original program (of comment 0).
Additional, could you provide more information about the version you used
("gfortran -v"), of interest are the complete of "Target" and of "gcc version".


(In reply to comment #3)
> Can you provides more details?
>
> 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?


Example on my system for a 4.6 version which has still the bug:

$ gfortran-4.6 -v |& grep -E 'gcc version|Target'
Target: x86_64-suse-linux
gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux)

$ gfortran-4.6 -std=f95 test.f90
test.f90:37.11:
      PAUSE
          1
Error: Deleted feature: PAUSE statement at (1)

And after commenting that line:

$ gfortran-4.6 -std=f95 test.f90
A(          1 ,          1 ) =    1.00000000      B =    1.00000000
A(          2 ,          1 ) =    2.00000000      B =    2.00000000
A(          1 ,          2 ) =    3.00000000      B =    3.00000000
A(          2 ,          2 ) =    4.00000000      B =    4.00000000
A(          1 ,          3 ) =    5.00000000      B =    5.00000000
A(          2 ,          3 ) =    6.00000000      B =    6.00000000
A(          1 ,          4 ) =    7.00000000      B =    7.00000000
A(          2 ,          4 ) =    8.00000000      B =    8.00000000

The output looks correct and is the same as with other compilers. However, if I
use the buggy version of the compiler without -std=f95, I get:

$ gfortran-4.6 hj4.f90  && ./a.out
A(          1 ,          1 ) =    1.00000000      B =    3.00000000
A(          2 ,          1 ) =    2.00000000      B =    4.00000000
A(          1 ,          2 ) =    3.00000000      B =    5.00000000
A(          2 ,          2 ) =    4.00000000      B =    6.00000000
A(          1 ,          3 ) =    5.00000000      B =    7.00000000
A(          2 ,          3 ) =    6.00000000      B =    8.00000000
A(          1 ,          4 ) =    7.00000000      B =    3.36311631E-44
A(          2 ,          4 ) =    8.00000000      B =    9.62964972E-35


As written, using "(:)" - or to be more precise (it's a rank-3 array) -
"B(:,:,:) = ", -fno-realloc-lhs, or a newer version of the compiler solves the
problem as well.

--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
  2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
                   ` (5 preceding siblings ...)
  2012-02-07 11:44 ` hirshmansp at ornl dot gov
@ 2012-02-07 14:37 ` burnus at gcc dot gnu.org
  2012-02-07 16:18 ` sphirshman at yahoo dot com
                   ` (4 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-02-07 14:37 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 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".


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
  2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
                   ` (6 preceding siblings ...)
  2012-02-07 14:37 ` burnus at gcc dot gnu.org
@ 2012-02-07 16:18 ` sphirshman at yahoo dot com
  2012-02-10 20:01 ` sphirshman at yahoo dot com
                   ` (3 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: sphirshman at yahoo dot com @ 2012-02-07 16:18 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117

--- Comment #8 from steven hirshman <sphirshman at yahoo dot com> 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 <gcc-bugzilla@gcc.gnu.org>
To: sphirshman@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 <burnus at gcc dot gnu.org> 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".


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
  2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
                   ` (7 preceding siblings ...)
  2012-02-07 16:18 ` sphirshman at yahoo dot com
@ 2012-02-10 20:01 ` sphirshman at yahoo dot com
  2012-02-10 20:45 ` kargl at gcc dot gnu.org
                   ` (2 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: sphirshman at yahoo dot com @ 2012-02-10 20:01 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117

--- Comment #9 from steven hirshman <sphirshman at yahoo dot com> 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 <gcc-bugzilla@gcc.gnu.org>
To: sphirshman@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 <burnus at gcc dot gnu.org> changed:

          What    |Removed                    |Added
----------------------------------------------------------------------------
            Status|UNCONFIRMED                |RESOLVED
                CC|                            |burnus at gcc dot gnu.org
        Resolution|                            |DUPLICATE

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 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 ***


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
  2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
                   ` (8 preceding siblings ...)
  2012-02-10 20:01 ` sphirshman at yahoo dot com
@ 2012-02-10 20:45 ` kargl at gcc dot gnu.org
  2012-02-11 11:41 ` burnus at gcc dot gnu.org
  2012-02-11 12:08 ` sphirshman at yahoo dot com
  11 siblings, 0 replies; 13+ messages in thread
From: kargl at gcc dot gnu.org @ 2012-02-10 20:45 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
           Severity|critical                    |normal

--- Comment #10 from kargl at gcc dot gnu.org 2012-02-10 20:44:47 UTC ---
(In reply to comment #9)
> 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?

The audit trail for this PR is quite confusing, and the above
is too vague to even guess at what your problem is.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
  2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
                   ` (9 preceding siblings ...)
  2012-02-10 20:45 ` kargl at gcc dot gnu.org
@ 2012-02-11 11:41 ` burnus at gcc dot gnu.org
  2012-02-11 12:08 ` sphirshman at yahoo dot com
  11 siblings, 0 replies; 13+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-02-11 11:41 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> 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 
> "( )".


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
  2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
                   ` (10 preceding siblings ...)
  2012-02-11 11:41 ` burnus at gcc dot gnu.org
@ 2012-02-11 12:08 ` sphirshman at yahoo dot com
  11 siblings, 0 replies; 13+ messages in thread
From: sphirshman at yahoo dot com @ 2012-02-11 12:08 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117

--- Comment #12 from steven hirshman <sphirshman at yahoo dot com> 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 <gcc-bugzilla@gcc.gnu.org>
To: sphirshman@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 <burnus at gcc dot gnu.org> 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 
> "( )".


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2012-02-11 12:08 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-03 20:32 [Bug fortran/52117] New: allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 sphirshman at yahoo dot com
2012-02-03 20:43 ` [Bug fortran/52117] " burnus at gcc dot gnu.org
2012-02-06 15:38 ` sphirshman at yahoo dot com
2012-02-06 17:47 ` burnus at gcc dot gnu.org
2012-02-06 19:47 ` sphirshman at yahoo dot com
2012-02-06 20:02 ` burnus at gcc dot gnu.org
2012-02-07 11:44 ` hirshmansp at ornl dot gov
2012-02-07 14:37 ` burnus at gcc dot gnu.org
2012-02-07 16:18 ` sphirshman at yahoo dot com
2012-02-10 20:01 ` sphirshman at yahoo dot com
2012-02-10 20:45 ` kargl at gcc dot gnu.org
2012-02-11 11:41 ` burnus at gcc dot gnu.org
2012-02-11 12:08 ` sphirshman at yahoo dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).