[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

2022-01-25 Thread sandra at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from sandra at gcc dot gnu.org ---
Marking this as fixed.

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

2022-01-25 Thread mscfd at gmx dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342

--- Comment #8 from martin  ---
Seems to work fine with current master. Not even valgrind complains.

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

2021-10-22 Thread dominiq at lps dot ens.fr via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342

--- Comment #7 from Dominique d'Humieres  ---
> Has this bug been fully fixed now, so that we can close it?

It seems so.

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

2021-10-22 Thread sandra at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #6 from sandra at gcc dot gnu.org ---
Has this bug been fully fixed now, so that we can close it?

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

2021-05-04 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

2021-02-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:5159b88ef1a1774ec8851c6b92794ae2bf6e0b74

commit r11-7362-g5159b88ef1a1774ec8851c6b92794ae2bf6e0b74
Author: Paul Thomas 
Date:   Wed Feb 24 16:00:51 2021 +

Fortran: Fix memory problems with assumed rank formal args [PR98342].

2021-02-24  Paul Thomas  

gcc/fortran
PR fortran/98342
* trans-expr.c (gfc_conv_derived_to_class): Add optional arg.
'derived_array' to hold the fixed, parmse expr in the case of
assumed rank formal arguments. Deal with optional arguments.
(gfc_conv_procedure_call): Null 'derived' array for each actual
argument. Add its address to the call to gfc_conv_derived_to_
class. Access the 'data' field of scalar descriptors before
deallocating allocatable components. Also strip NOPs before the
calls to gfc_deallocate_alloc_comp. Use 'derived' array as the
input to gfc_deallocate_alloc_comp if it is available.
* trans.h : Include the optional argument 'derived_array' to
the prototype of gfc_conv_derived_to_class. The default value
is NULL_TREE.

gcc/testsuite/
PR fortran/98342
* gfortran.dg/assumed_rank_21.f90 : New test.

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

2020-12-18 Thread mscfd at gmx dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342

--- Comment #4 from martin  ---
Just checked the patch and it works great, except that I can now easily produce
an ICE by changing (in sel_rank)

   type(tuple), dimension(..), intent(in) :: x

to

   class(*), dimension(..), intent(in) :: x

The ICE is
fc_get_descriptor_field, at fortran/trans-array.c:140
0x613e94 gfc_get_descriptor_field
../../gcc-repo/gcc/fortran/trans-array.c:140
0x75cd35 gfc_conv_descriptor_data_get(tree_node*)
../../gcc-repo/gcc/fortran/trans-array.c:159
0x76b769 gfc_conv_array_data(tree_node*)
../../gcc-repo/gcc/fortran/trans-array.c:2985
0x76b769 structure_alloc_comps
../../gcc-repo/gcc/fortran/trans-array.c:8559
0x76d9ca gfc_deallocate_alloc_comp(gfc_symbol*, tree_node*, int, int)
../../gcc-repo/gcc/fortran/trans-array.c:9681
0x797535 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc-repo/gcc/fortran/trans-expr.c:6457
0x79088b gfc_trans_assignment_1
../../gcc-repo/gcc/fortran/trans-expr.c:10930
0x757f33 trans_code
../../gcc-repo/gcc/fortran/trans.c:1888
0x781504 gfc_generate_function_code(gfc_namespace*)
../../gcc-repo/gcc/fortran/trans-decl.c:6880
0x6fd5ce translate_all_program_units
../../gcc-repo/gcc/fortran/parse.c:6351
0x6fd5ce gfc_parse_file()
../../gcc-repo/gcc/fortran/parse.c:6620
0x75503f gfc_be_parse_file
../../gcc-repo/gcc/fortran/f95-lang.c:212


Not sure whether this is an entirely new problem or related to the patch. At
least trans-expr.c6457 is just about 20 lines below the place where the patch
add the lines.

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

2020-12-18 Thread pault at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342

--- Comment #3 from Paul Thomas  ---
Created attachment 49793
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49793&action=edit
Fix for the PR

This regtests OK. Testcase:

! { dg-do run }
!
! Test the fix for PR98342.
!
! Contributed by Martin Stein  
!
module mod
implicit none
private
public get_tuple, sel_rank

! we need to encapsulate the allocatable in a derived type
type, public :: tuple
   integer, dimension(:), allocatable :: t
! with pointer there is no failure
! integer, dimension(:), pointer :: t
end type tuple

contains

function sel_rank(x) result(s)
   character(len=:), allocatable :: s
   type(tuple), dimension(..), intent(in) :: x
   select rank (x)
   rank (0)
  s = '0'
   rank (1)
  s = '1'
   rank default
  s = '?'
   end select
! this is printed as expected
!   print *, 'rank: ', s
end function sel_rank

function get_tuple(t) result(a)
   type(tuple) :: a
   integer, dimension(:), intent(in) :: t
   allocate(a%t, source=t)
end function get_tuple

end module mod


program alloc_rank
   use mod
   implicit none

   integer, dimension(1:3) :: x
   character(len=:), allocatable :: output
   type(tuple) :: z

   x = [1,2,3]
! this should print '0' (as a tuple itself has rank 0)
   output = sel_rank(get_tuple(x))   ! runtime: Error in `./alloc_rank.x':
 ! munmap_chunk(): invalid pointer
 ! (memory freed not malloc'ed)
   if (output .ne. '0') stop 1

   output = sel_rank([get_tuple(x)]) ! This worked OK
   if (output .ne. '1') stop 2

   deallocate(output)
end program alloc_rank

Paul

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

2020-12-17 Thread pault at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-12-17
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Googling on munmap_chunk(): invalid pointer reveals that this is quite a
frequent problem.

It originates from the call

out = sel_rank(get_tuple(x))

rather than what happens in either function. Somewhere a free is bein done on
memory that is not malloc'ed.

Bizarrely,

out = sel_rank([get_tuple(x)])

as does

z = get_tuple(x) ! z appropriately declared of course!
out = sel_rank(z)

valgrind confirms this:
snip
==535157== Invalid free() / delete / delete[] / realloc()
==535157==at 0x483A9F5: free (vg_replace_malloc.c:538)
==535157==by 0x40343A: MAIN__ (pr98342.f90:48)
==535157==by 0x4035BA: main (pr98342.f90:40)
==535157==  Address 0x1ffeffede0 is on thread 1's stack
==535157==  in frame #1, created by MAIN__ (pr98342.f90:39)
==535157== 
snip

The problem arises somewhere in trans-expr.c(gfc_conv_procedure_call).

I am on to it :-)

Paul

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

2020-12-17 Thread mscfd at gmx dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342

--- Comment #1 from martin  ---
This does not the require the recent patch proposed for bug 97694 and bug
97723. It also fails with gfortran 10.1.0.