[Bug fortran/97123] double free detected in tcache 2 with recursive allocatable type

2020-09-20 Thread igor.gayday at mu dot edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97123

--- Comment #1 from Igor Gayday  ---
Might be related to Bug #90519.

[Bug fortran/97123] New: double free detected in tcache 2 with recursive allocatable type

2020-09-19 Thread igor.gayday at mu dot edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97123

Bug ID: 97123
   Summary: double free detected in tcache 2 with recursive
allocatable type
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor.gayday at mu dot edu
  Target Milestone: ---

Consider the following program:

program test_prg
  implicit none

  type :: recursive_block
type(recursive_block), allocatable :: subblocks(:, :)
  end type

  type(recursive_block) :: top_level
  top_level = init_recursive()
  deallocate(top_level % subblocks)

contains

  function init_recursive() result(res)
type(recursive_block) :: res
type(recursive_block), allocatable :: inner(:, :)

allocate(inner(1, 1))
allocate(inner(1, 1) % subblocks(1, 1))
res % subblocks = inner
  end function
end program

Compiled with gfortran 10.2, it crashes at runtime on deallocate(top_level %
subblocks) with the following message:
free(): double free detected in tcache 2

[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter

2020-09-14 Thread igor.gayday at mu dot edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046

--- Comment #5 from Igor Gayday  ---
I'd like to add that Gilles Gouaillardet is the author of the reproducer in my
original post.

[Bug fortran/97046] New: Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter

2020-09-14 Thread igor.gayday at mu dot edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046

Bug ID: 97046
   Summary: Bad interaction between lbound/ubound, allocatable
arrays and bind(C) subroutine with dimension(..)
parameter
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor.gayday at mu dot edu
  Target Milestone: ---

Consider the following code:

MODULE FOO
INTERFACE
SUBROUTINE dummyc(x0) BIND(C, name="sync")
type(*), dimension(..) :: x0
END SUBROUTINE
END INTERFACE
contains
SUBROUTINE dummy(x0)
type(*), dimension(..) :: x0
call dummyc(x0)
END SUBROUTINE
END MODULE

PROGRAM main
USE FOO
IMPLICIT NONE
integer :: before(2), after(2)

INTEGER, parameter :: n = 1

DOUBLE PRECISION, ALLOCATABLE :: buf(:)
DOUBLE PRECISION :: buf2(n)

ALLOCATE(buf(n))
before(1) = LBOUND(buf,1)
before(2) = UBOUND(buf,1)
CALL dummy (buf)
after(1) = LBOUND(buf,1)
after(2) = UBOUND(buf,1)

if (before(1) .NE. after(1)) stop 1
if (before(2) .NE. after(2)) stop 2

before(1) = LBOUND(buf2,1)
before(2) = UBOUND(buf2,1)
CALL dummy (buf2)
after(1) = LBOUND(buf2,1)
after(2) = LBOUND(buf2,1)

if (before(1) .NE. after(1)) stop 3
if (before(2) .NE. after(2)) stop 4

END PROGRAM

lbound() and ubound() of an allocatable array return different values 
before and after a Fortran subroutine with dimension(..) parameter (that 
in turns invokes a bind(C) subroutine) is invoked.

Note that if the main program directly CALL dummyc(buf) (instead of 
dummy(buf)), then the error does not occur.

gcc versions 9.2.0, 10.2.0 and the latest master branch are all affected.

In particular, this causes issues with mpi_f08 module, see:
https://stackoverflow.com/questions/63824065/lbound-of-an-array-changes-after-call-to-mpi-gatherv-when-using-mpi-f08-module

This might be a duplicate of Bug #94070.

[Bug fortran/97045] New: A wrong column is selected when addressing individual elements of unlimited polymorphic dummy argument

2020-09-14 Thread igor.gayday at mu dot edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97045

Bug ID: 97045
   Summary: A wrong column is selected when addressing individual
elements of unlimited polymorphic dummy argument
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor.gayday at mu dot edu
  Target Milestone: ---

Consider the following Fortran program:

program test_prg
  implicit none
  integer :: i
  integer, allocatable :: arr(:, :)

  arr = reshape([(i, i = 1, 100)], [10, 10])
  do i = 1, 3
print *, 'Column', i
call write_array(arr(1:2, i)) 
  end do

contains

  subroutine write_array(array)
class(*), intent(in) :: array(:)
integer :: i

do i = 1, size(array)
  select type (elem => array(i))
type is (integer)
  print '(I0)', elem
  end select
end do
  end subroutine


  subroutine write_array_alt(array)
class(*), intent(in) :: array(:)
integer :: i

select type (array)
  type is (integer)
print '(I0)', array
end select
  end subroutine

end program

Compiled with gfortran 9.3.0 (and 10.2), the program prints:

 Column   1
1
2
 Column   2
21
22
 Column   3
41
42

As you can see, it skips every other column. If I replace the call to
write_array with the call to write_array_alt, where I select type of the whole
array and not individual elements, then every column is printed, as expected.

This issue was originally reported here:
https://stackoverflow.com/questions/63841012/a-wrong-column-is-selected-when-addressing-individual-elements-of-unlimited-poly