[Bug fortran/46978] New: TRANSPOSE corrupts structure and memory

[Bug fortran/46978] New: TRANSPOSE corrupts structure and memory

[m.a.hulsen at tue dot nl]

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

           Summary: TRANSPOSE corrupts structure and memory
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: m.a.hulsen@tue.nl


Created attachment 22783
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22783
the source files and Makefile

I found a serious issue with the TRANSPOSE intrinsic function, possibly when
combined with the reshape intrinsic.
I tried to create a small sample program, but I was unsuccessful.
Therefore I decided to start from the failing big program and made it as small
as possible but still showing the issue. It turned out to be very tricky and
there are still 4275 lines of code left.
However, all of the code in mods.f90 is necessary to build the structure mesh
and is fine. The problem appears at a single line in the small main program
after building the mesh structure.

The corruption is related to the statement:

   mesh%objects(1)%coor = transpose ( reshape ( a, (/2,nno/) ) )

at line 113 in the file mainprog.f90, which corrupt other parts of the
structure mesh. In particular the parts mesh%blocks(2)%elements and
mesh$blocks(3)%elements are overwritten. For example:
mesh%blocks(3)%elements before:
          1           1           1           1           1          21
22          23          24          25
mesh%blocks(3)%elements after:
          1           1           1           1           1          21
22          23           0  1072693248

If I remove the stop statement at line 124, I also get a message:
*** glibc detected *** mainprog: double free or corruption (!prev):
0x00000000008fe440 ***
with a corresponding backtrace.

If I uncomment lines 5, 6 and 7 in mainprog.f90, and basically
replacing the intrinsic transpose with my own version, the problem is gone.

Note, that it runs fine with gfortran from 6th June 2010 (from Tobias Burnus’
homepage), g95, ifort, Lahey/Fujitsu and nagfor.

[Bug fortran/46978] TRANSPOSE corrupts structure and memory

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2010-12-16 10:20:47 UTC ---
It works for me on powerpc-apple-darwin9, revision 167865, and
x86_64-apple-darwin10.5.0, revision 167880, in both 32 and 64 bit modes,
with/without '-Ofast -g'. Could you provide the output of 'gfortran -v'?

Note that valgrind reports

==64764== Memcheck, a memory error detector
==64764== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==64764== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==64764== Command: a.out
==64764== 
 mesh%blocks(1)%elements
           1           1           1           1           1           1       
   1           1           1           1           2           2           2   
       2           1           2           3           4           5         
11          12          13          14          15           1           2     
     4           5
 mesh%blocks(2)%elements
           1           1           1           1           1           1       
   1           1           1           1           2           2           6   
       7           8           9          10          16          17         
18          19          20           3           6
 mesh%blocks(3)%elements
           1           1           1           1           1          21       
  22          23          24          25
 mesh%blocks(4)%elements
           1           1           1           1           1          26       
  27          28          29          30
==64764== Invalid write of size 8
==64764==    at 0x100002696: MAIN__ (main.f90:113)
==64764==  Address 0x100773b40 is 0 bytes after a block of size 208 alloc'd
==64764==    at 0x100063915: malloc (vg_replace_malloc.c:236)
==64764==    by 0x1000242DB:
__meshgen_construct_m_MOD_add_to_mesh_object_geometry (mod.f90:2014)
==64764== 
 mesh%blocks(1)%elements
           1           1           1           1           1           1       
   1           1           1           1           2           2           2   
       2           1           2           3           4           5         
11          12          13          14          15           1           2     
     4           5
 mesh%blocks(2)%elements
           1           1           1           1           1           1       
   1           1           1           1           2           2           6   
       7           8           9          10          16          17         
18          19          20           3           6
 mesh%blocks(3)%elements
           1           1           1           1           1          21       
  22          23          24          25
 mesh%blocks(4)%elements
           1           1           1           1           1          26       
  27          28          29          30
==64764== 
==64764== HEAP SUMMARY:
==64764==     in use at exit: 3,116 bytes in 136 blocks
==64764==   total heap usage: 1,507 allocs, 1,371 frees, 3,127,743 bytes
allocated
==64764== 
==64764== LEAK SUMMARY:
==64764==    definitely lost: 3,028 bytes in 135 blocks
==64764==    indirectly lost: 0 bytes in 0 blocks
==64764==      possibly lost: 0 bytes in 0 blocks
==64764==    still reachable: 88 bytes in 1 blocks
==64764==         suppressed: 0 bytes in 0 blocks
==64764== Rerun with --leak-check=full to see details of leaked memory
==64764== 
==64764== For counts of detected and suppressed errors, rerun with: -v
==64764== ERROR SUMMARY: 9 errors from 1 contexts (suppressed: 0 from 0)

where the line 113 of main.f90 is

      mesh%objects(1)%coor = transpose ( reshape ( a, (/2,nno/) ) )

and the line 2014 of mods.f90 is the last line of the allocate

    allocate ( &
      mesh%objects(newobject)%coor(nnodes,mesh%objects(newobject)%ndim), &
      mesh%objects(newobject)%refcoor(nnodes,mesh%objects(newobject)%ndim), &
      mesh%objects(newobject)%grpelm(nnodes,2) )

I did not look further to the code

[Bug fortran/46978] TRANSPOSE corrupts structure and memory

[m.a.hulsen at tue dot nl]

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

--- Comment #2 from Martien Hulsen <m.a.hulsen at tue dot nl> 2010-12-16 10:33:03 UTC ---
(In reply to comment #1)

> with/without '-Ofast -g'. Could you provide the output of 'gfortran -v'?

[martien@laptop18 ~]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/martien/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/martien/gcc-trunk
--enable-languages=c,fortran --enable-checking=release --disable-bootstrap :
(reconfigured) ../gcc/configure --prefix=/home/martien/gcc-trunk
--enable-languages=c,fortran --enable-checking=release --disable-bootstrap
Thread model: posix
gcc version 4.6.0 20101216 (experimental) (GCC)

[Bug fortran/46978] [4.6 Regression] TRANSPOSE corrupts structure and memory

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |burnus at gcc dot gnu.org
   Target Milestone|---                         |4.6.0
            Summary|TRANSPOSE corrupts          |[4.6 Regression] TRANSPOSE
                   |structure and memory        |corrupts structure and
                   |                            |memory

[Bug fortran/46978] [4.6 Regression] TRANSPOSE corrupts structure and memory

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-16 14:48:53 UTC ---
Reduced test case:

program elastic2
  implicit none
  type mesh_t
    real, allocatable, dimension(:,:) :: coor
  end type mesh_t
  type(mesh_t) :: mesh3
  real, allocatable, dimension(:) :: a
  integer :: nno
  nno = 13
  call two(mesh3, nno)
  allocate(a(2*nno))
  a = 1
  mesh3%coor = transpose ( reshape ( a, (/2,nno/) ) )
contains
  subroutine two(x,nno)
    type(mesh_t) :: x
    integer :: nno
    allocate(x%coor(nno,2))
    x%coor = 99
  end subroutine
end program elastic2

[Bug fortran/46978] [4.6 Regression] TRANSPOSE corrupts structure and memory

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
                 CC|                            |jakub at gcc dot gnu.org

[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org
            Summary|[4.6 Regression] TRANSPOSE  |[4.6 Regression] TRANSPOSE
                   |corrupts structure and      |with RESHAPE and ALLOCATE:
                   |memory                      |Segfault

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-16 21:31:43 UTC ---
Further reduced test case. The ALLOCATE of A with a non-constant bound and a
RESHAPE with a non-constant bound are crucial ingredients - as is the TRANSFER.
(The purpose of "TWO" is to make the dump a tad more readable.)

Works: 2010-09-09-r164046
Fails: 2010-09-28-r164677

Thus, a good candidate would be the TRANSFER rewriting patch for PR 45648.

The program crashes with:
*** glibc detected *** ./a.out: free(): invalid pointer: 0x0000000000604040 ***

program elastic2
  implicit none
  real, allocatable, dimension(:,:) :: coor
  real, allocatable, dimension(:) :: a
  integer :: nno
  nno = 3
  allocate(a(2*nno))
  call two()
  coor = transpose ( reshape ( a, (/2,nno/) ) )
contains
  subroutine two()
    allocate(coor(3,2))
    coor = 99
    a = 12
  end subroutine
end program elastic2

[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault

[mikael at gcc dot gnu.org]

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

--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> 2010-12-17 19:28:36 UTC ---
(In reply to comment #4)
> Thus, a good candidate would be the TRANSFER rewriting patch for PR 45648.
> 
You mean the TRANSPOSE rewriting patch.
I was hoping not to be the culprit before I looked at the ChangeLog myself. :-(


Thanks for reducing, I'm taking a look.

[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault

[mikael at gcc dot gnu.org]

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

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> 2010-12-19 15:47:14 UTC ---
This seems to be the problem :
the front-end generates a transposed descriptor for a non-intrinsic function. 
If the function is an intrinsic, the descriptor is filled in the library, and
it is not transposed.

[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault

[mikael at gcc dot gnu.org]

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

--- Comment #7 from Mikael Morin <mikael at gcc dot gnu.org> 2010-12-20 23:24:54 UTC ---
This seems to fix it, though I find it somewhat suspicious. 

Index: trans-array.c
===================================================================
--- trans-array.c    (révision 164205)
+++ trans-array.c    (copie de travail)
@@ -851,8 +851,8 @@ gfc_trans_create_temp_array (stmtblock_t * pre, st
          of the descriptor fields.  */
       tmp = fold_build2_loc (input_location,
         MINUS_EXPR, gfc_array_index_type,
-        gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[n]),
-        gfc_conv_descriptor_lbound_get (desc, gfc_rank_cst[n]));
+        gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[dim]),
+        gfc_conv_descriptor_lbound_get (desc, gfc_rank_cst[dim]));
       loop->to[n] = tmp;
       continue;
     }


I remember making this change back and forth, and indeed, it reverts part of
revision 164112, but the regression is at revision 164205. Strange.

[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault

[mikael at gcc dot gnu.org]

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

--- Comment #8 from Mikael Morin <mikael at gcc dot gnu.org> 2010-12-20 23:29:34 UTC ---
(In reply to comment #6)
> This seems to be the problem :
> the front-end generates a transposed descriptor for a non-intrinsic function. 
> If the function is an intrinsic, the descriptor is filled in the library, and
> it is not transposed.

It may not be the problem after all.

[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2010.12.22 12:37:08
         AssignedTo|unassigned at gcc dot       |mikael at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault

[m.a.hulsen at tue dot nl]

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

--- Comment #9 from Martien Hulsen <m.a.hulsen at tue dot nl> 2010-12-23 09:13:05 UTC ---
(In reply to comment #7)
> This seems to fix it, though I find it somewhat suspicious. 

With this change all my test cases run fine again. Thanks.

[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault

[mikael at gcc dot gnu.org]

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

--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> 2010-12-23 13:35:57 UTC ---
Author: mikael
Date: Thu Dec 23 13:35:53 2010
New Revision: 168206

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168206
Log:
2010-12-23  Mikael Morin  <mikael.morin@gcc.gnu.org>

    PR fortran/46978
    Revert part of revision 164112
    * trans-array.c (gfc_trans_create_temp_array):
    Set loop n'th upper bound from (possibly transposed) array's dim bounds.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c

[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault

[mikael at gcc dot gnu.org]

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

--- Comment #11 from Mikael Morin <mikael at gcc dot gnu.org> 2010-12-23 13:39:10 UTC ---
Author: mikael
Date: Thu Dec 23 13:39:06 2010
New Revision: 168207

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168207
Log:
2010-12-23  Mikael Morin  <mikael@gcc.gnu.org>

    PR fortran/46978
    * gfortran.dg/transpose_intrinsic_func_call_1.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/transpose_intrinsic_func_call_1.f90
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #12 from Mikael Morin <mikael at gcc dot gnu.org> 2010-12-23 13:43:08 UTC ---
Fixed. 

Thanks for the bug report.