[Bug fortran/105807] ICE / error when defining a class containing polymorphic components

[abensonca at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105807

--- Comment #4 from Andrew Benson  ---
A possibly related case:

module tm

  type :: st
  end type st

  type :: resourceManager
 class  (*), pointer :: resource => null()
 integer   , pointer :: counter  => null()
  end type resourceManager

  interface resourceManager
 module procedure resourceManager
  end interface

  type :: wrap
 type(st), pointer :: obj => null()
 type(resourceManager) :: manager
  end type wrap

  interface wrap
 module procedure wrapConstructN
  end interface

contains

  function resourceManagerConstructor(resource) result(self)
implicit none
type(resourceManager) :: self
class(*), intent(in   ), pointer :: resource

self%resource => resource
allocate(self%counter)
self%counter=1
return
  end function resourceManagerConstructor

  function wrapConstructN(i) result(self)
implicit none
type(wrap) :: self
integer, intent(in   ) :: i
type(st), pointer :: st_

allocate(self%obj)
self%obj=st()
self%manager=resourceManager(self%obj)
return
  end function wrapConstructN

end module tm

$ gfortran -c bug.F90 -o bug -g
bug.F90:45:42:

   45 | self%manager=resourceManager(self%obj)
  |  1
internal compiler error: in fold_convert_loc, at fold-const.cc:2627
0x770b18 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc-git-unpatched/gcc/fold-const.cc:2627
0xa65649 gfc_trans_subcomponent_assign
../../gcc-git-unpatched/gcc/fortran/trans-expr.cc:9053
0xa667c9 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc-git-unpatched/gcc/fortran/trans-expr.cc:9246
0xa67531 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-git-unpatched/gcc/fortran/trans-expr.cc:9313
0xa6ae35 gfc_trans_assignment_1
../../gcc-git-unpatched/gcc/fortran/trans-expr.cc:11742
0xa1b307 trans_code
../../gcc-git-unpatched/gcc/fortran/trans.cc:1950
0xa4d81d gfc_generate_function_code(gfc_namespace*)
../../gcc-git-unpatched/gcc/fortran/trans-decl.cc:7674
0xa1f6d1 gfc_generate_module_code(gfc_namespace*)
../../gcc-git-unpatched/gcc/fortran/trans.cc:2370
0x9c73f5 translate_all_program_units
../../gcc-git-unpatched/gcc/fortran/parse.cc:6708
0x9c73f5 gfc_parse_file()
../../gcc-git-unpatched/gcc/fortran/parse.cc:7027
0xa1804f gfc_be_parse_file
../../gcc-git-unpatched/gcc/fortran/f95-lang.cc:229
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/109066] New: Segfault when using defined assignment

[abensonca at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066

Bug ID: 109066
   Summary: Segfault when using defined assignment
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gcc dot gnu.org
  Target Milestone: ---

The following code (compiled using current trunk), when run, causes a segfault,
and valgrind complains about an invalid read. The code appears correct to me,
and runs correctly (no segfault, no warnings from valgrind) when compiled with
ifort.

module Input_Parameters_Bug
  public

  type :: resourceManager
 integer   :: counter=0 ! Remove this to resolve segfault
   contains
 procedure :: resourceManagerAssign
 generic   :: assignment(=) => resourceManagerAssign
  end type resourceManager

  type hdf5Object
 private
 type   (resourceManager) :: objectManager
   contains
 procedure :: openGroup =>IO_HDF5_Open_Group
! procedure :: h5Assign  ! Add this defined assignment to avoid segfault.
! generic   :: assignment(=) => h5Assign
  end type hdf5Object

  interface hdf5Object
 module procedure hdf5Constructor
  end interface hdf5Object

  type :: inputParameters
 private
 type(hdf5Object), pointer :: outputParameters => null() ! Make this
allocatable instead of pointer to resolve segfault
  end type inputParameters

  interface inputParameters
 module procedure inputParametersConstructorNode
  end interface inputParameters

contains

  subroutine resourceManagerAssign(to,from)
implicit none
class(resourceManager), intent(  out) :: to
class(resourceManager), intent(in   ) :: from
to%counter=from%counter+1
write (0,*) "ASSIGN",to%counter
return
  end subroutine resourceManagerAssign

  function hdf5Constructor() result(self)
implicit none
type(hdf5Object) :: self
return
  end function hdf5Constructor

  function IO_HDF5_Open_Group(inObject) result (self)
implicit none
type(hdf5Object) :: self
class(hdf5Object), intent(in   ) :: inObject
write (0,*) "OPEN"
return
  end function IO_HDF5_Open_Group

  subroutine h5Assign(to,from)
implicit none
class(hdf5Object), intent(  out) :: to
class(hdf5Object), intent(in   ) :: from
write (0,*) "ASSIGN H5"
to%objectManager=from%objectManager
return
  end subroutine h5Assign

  function inputParametersConstructorNode(outputParametersGroup) result(self)
implicit none
type(inputParameters) :: self
type(hdf5Object ), intent(in   ) :: outputParametersGroup
allocate(self%outputParameters)
write (0,*) "START"
self%outputParameters=outputParametersGroup%openGroup()
write (0,*) "STOP"
return
  end function inputParametersConstructorNode

end module Input_Parameters_Bug

program Test_Parameters_Bug
  use :: Input_Parameters_Bug
  implicit none
  type(hdf5Object)  :: outputFile
  type(inputParameters) :: testParameters
  outputFile=hdf5Object()
  write (0,*) "CALL"
  testParameters=inputParameters(outputFile)
end program Test_Parameters_Bug


$ gfortran bug.F90 -g
$ valgrind --track-origins=yes ./a.out 
==19625== Memcheck, a memory error detector
==19625== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==19625== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==19625== Command: ./a.out
==19625== 
 ASSIGN   1
 CALL
 START
 OPEN
==19625== Use of uninitialised value of size 8
==19625==at 0x4012DF:
__input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:73)
==19625==by 0x4017D4: MAIN__ (bug.F90:87)
==19625==by 0x401812: main (bug.F90:81)
==19625==  Uninitialised value was created by a stack allocation
==19625==at 0x401206:
__input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:67)
==19625== 

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x4e161ef in ???
#1  0x4012df in __input_parameters_bug_MOD_inputparametersconstructornode
at
/data001/abenson/Galacticus/galacticus_gfortranFinalization/bug.F90:73
#2  0x4017d4 in test_parameters_bug
at
/data001/abenson/Galacticus/galacticus_gfortranFinalization/bug.F90:87
#3  0x401812 in main
at
/data001/abenson/Galacticus/galacticus_gfortranFinalization/bug.F90:81
==19625== 
==19625== Process terminating with default action of signal 11 (SIGSEGV)
==19625==at 0x4E1613E: raise (in
/home/abenson/Galacticus/Tools/lib/libc-2.12.1.so)
==19625==by 0x4E161EF: ??? (in
/home/abenson/Galacticus/Tools/lib/libc-2.12.1.so)
==19625==by 0x4012DE:
__input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:73)
==19625==by 0x4017D4: MAIN__ (bug.F90:87)
==19625==by 0x401812: main (bug.F90:81)
==19625== 
==19625== HEAP SUMMARY:
==19625== in use at exit: 5,448 bytes in 18 blocks
==1962

[Bug fortran/102845] New: Memory leak with nested OpenMP parallelism

[abensonca at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102845

Bug ID: 102845
   Summary: Memory leak with nested OpenMP parallelism
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gcc dot gnu.org
  Target Milestone: ---

The following code seems to cause a memory leak when using nested OpenMP
parallelism when compiled and run with gfortran-12.

module nestedMod

  type :: n
 integer, allocatable, dimension(:) :: i
  end type n

contains

  subroutine nested()
implicit none
type(n), save :: a
!$omp threadprivate(a)

!$omp parallel
if (.not.allocated(a%i)) allocate(a%i(1))
!$omp end parallel
return
  end subroutine nested

end module nestedMod

program nestedLeak
  use :: OMP_Lib, only :  OMP_Set_Nested
  use :: nestedMod
  implicit none
  integer :: i,  unit, valueRSS
  character(len=80)  :: line
  call OMP_Set_Nested(.true.)
  !$omp parallel
  do i=1,1000
 call nested()
 !$omp single
 open(NEWUNIT=unit, FILE='/proc/self/status', ACTION='read')
 do
read (unit, '(a)', END=120) line
if (line(1:6) == 'VmRSS:') then
   read (line(7:), *) valueRSS
   exit
endif
 enddo
120  continue
 close(unit)
 write (0,*) i,valueRSS
 !$omp end single
  end do
  !$omp end parallel

end program


This calls a subroutine from within an OpenMP parallel region. That subroutine
then allocates within its own, nested parallel region. 

The output is (middle parts removed for brevity):

   1  197900
   2  376964
   3  385280
.
.
.
 998 1463436
 999 1466208
1000 1475456


If I set OMP_Set_Nested(.false.) instead then the output is instead:

   1  308304
   2  337852
   3  306816
.
.
.
 998  376840
 999  352196
1000  376848

Running this through valgrind (with the number of iterations reduced to 2 so it
doesn't take too long to run) the output is:

==25999== Memcheck, a memory error detector
==25999== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==25999== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==25999== Command: ./a.out
==25999== 
   1  291692
   2  298840
==25999== 
==25999== HEAP SUMMARY:
==25999== in use at exit: 19,850,144 bytes in 516 blocks
==25999==   total heap usage: 979 allocs, 463 frees, 20,201,536 bytes allocated
==25999== 
==25999== 4,800 bytes in 15 blocks are possibly lost in loss record 6 of 10
==25999==at 0x4810218: calloc (vg_replace_malloc.c:1117)
==25999==by 0x3810C11952: _dl_allocate_tls (in /lib64/ld-2.12.so)
==25999==by 0x55845EE: allocate_stack (allocatestack.c:570)
==25999==by 0x55845EE: pthread_create@@GLIBC_2.2.5 (pthread_create.c:453)
==25999==by 0x4EFA4D3: gomp_team_start (team.c:841)
==25999==by 0x4EF251C: GOMP_parallel (parallel.c:169)
==25999==by 0x4017C8: MAIN__ (nested_leak.F90:29)
==25999==by 0x4017FF: main (nested_leak.F90:23)
==25999== 
==25999== 120,000 bytes in 3 blocks are possibly lost in loss record 8 of 10
==25999==at 0x480B7AB: malloc (vg_replace_malloc.c:380)
==25999==by 0x40188E: __nestedmod_MOD_nested._omp_fn.0 (nested_leak.F90:15)
==25999==by 0x4EF9E09: gomp_thread_start (team.c:108)
==25999==by 0x5583C39: start_thread (pthread_create.c:301)
==25999==by 0x586A61C: clone (clone.S:115)
==25999== 
==25999== 19,080,000 bytes in 477 blocks are definitely lost in loss record 10
of 10
==25999==at 0x480B7AB: malloc (vg_replace_malloc.c:380)
==25999==by 0x40188E: __nestedmod_MOD_nested._omp_fn.0 (nested_leak.F90:15)
==25999==by 0x4EF9E09: gomp_thread_start (team.c:108)
==25999==by 0x5583C39: start_thread (pthread_create.c:301)
==25999==by 0x586A61C: clone (clone.S:115)
==25999== 
==25999== LEAK SUMMARY:
==25999==definitely lost: 19,080,000 bytes in 477 blocks
==25999==indirectly lost: 0 bytes in 0 blocks
==25999==  possibly lost: 124,800 bytes in 18 blocks
==25999==still reachable: 645,344 bytes in 21 blocks
==25999== suppressed: 0 bytes in 0 blocks
==25999== Reachable blocks (those to which a pointer was found) are not shown.
==25999== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==25999== 
==25999== For lists of detected and suppressed errors, rerun with: -s
==25999== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 4 from 4)

where valgrind claims the allocations in nested() are definitely lost.

I'm aware that valgrind can report "possibly lost" and "still reachable" blocks
of memory when OpenMP is used (e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36298) but this seems like an
actual memory leak as far as I can tell.

[Bug fortran/114535] New: ICE with elemental finalizer

[abensonca at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114535

Bug ID: 114535
   Summary: ICE with elemental finalizer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gcc dot gnu.org
  Target Milestone: ---

The following code (which must be in two files to trigger the error) causes an
ICE using the latest gfortran.

$ cat ice1.F90
module iv
  type, public :: vs
   contains
 final :: destructor
  end type vs
contains
 elemental subroutine destructor(s)
type(vs), intent(inout) :: s
  end subroutine destructor
end module iv

$ cat ice2.F90 module d
contains
  function en() result(dd)
use :: iv
type(vs) :: dd
return
  end function en
end module d

module ni
contains
  subroutine iss()
use :: d
return
  end subroutine iss
end module ni

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-git/configure
--prefix=/home/abenson/Galacticus/Tools_Devel --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240330 (experimental) (GCC)

$ gfortran -c ice1.F90 -o ice1.o   
$ gfortran -c ice2.F90 -o ice2.o  
ice2.F90:16:13: 
   16 | end module ni | 1
internal compiler error: in gfc_trans_call, at fortran/trans-stmt.cc:400   
0x78ddb6 gfc_trans_call(gfc_code*, bool,
tree_node*, tree_node*, bool)
../../gcc-git/gcc/fortran/trans-stmt.cc:400 0xaa8a1b trans_code
../../gcc-git/gcc/fortran/trans.cc:2431
0xb47c14 gfc_trans_simple_do
../../gcc-git/gcc/fortran/trans-stmt.cc:2521
0xb47c14 gfc_trans_do(gfc_code*, tree_node*)
../../gcc-git/gcc/fortran/trans-stmt.cc:2653
0xaa898a trans_code
../../gcc-git/gcc/fortran/trans.cc:2463
0xb485e9 gfc_trans_integer_select  
../../gcc-git/gcc/fortran/trans-stmt.cc:3199
0xb485e9 gfc_trans_select(gfc_code*)
../../gcc-git/gcc/fortran/trans-stmt.cc:3692
0xaa8957 trans_code
../../gcc-git/gcc/fortran/trans.cc:2475
0xadd6fb gfc_generate_function_code(gfc_namespace*)
../../gcc-git/gcc/fortran/trans-decl.cc:7879
0xaadbf1 gfc_generate_module_code(gfc_namespace*)
../../gcc-git/gcc/fortran/trans.cc:2785
0xa5113d translate_all_program_units
../../gcc-git/gcc/fortran/parse.cc:7086
0xa5113d gfc_parse_file()
../../gcc-git/gcc/fortran/parse.cc:7413
0xaa546f gfc_be_parse_file
../../gcc-git/gcc/fortran/f95-lang.cc:241
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

This only occurs if the FINAL subroutine is ELEMENTAL.

[Bug fortran/114535] [13/14 regression] ICE with elemental finalizer

[abensonca at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114535

--- Comment #3 from Andrew Benson  ---
Thanks Paul. The workaround is very helpful and lets me continue making
progress in the rest of my work for now. Thanks again!

[Bug fortran/110547] New: Improper finalization calls with OpenMP tasks

[abensonca at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110547

Bug ID: 110547
   Summary: Improper finalization calls with OpenMP tasks
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gcc dot gnu.org
  Target Milestone: ---

Here's an example code (highly simplified from the actual code I'm working
on) that causes seemingly wrong behavior resulting in calling a destructor when
it should not be called:

module taskerMod

   type :: tasker
  integer :: depth=-1
contains
  final ::taskerDestruct
  procedure :: compute => taskerCompute
   end type tasker

 contains

   subroutine taskerDestruct(self)
 !$ use :: OMP_Lib  
 implicit none
 type(tasker), intent(inout) :: self

 write (0,*) "DESTRUCT FROM DEPTH ",self%depth !$ ," :
",omp_get_thread_num()  
 return
   end subroutine taskerDestruct

   recursive subroutine taskerCompute(self)
 !$ use :: OMP_Lib  
 implicit none
 class(tasker), intent(inout) :: self

 !$omp atomic
 self%depth=self%depth+1
 write (0,*) "DEPTH ",self%depth !$ ," : ",omp_get_thread_num() 
 if (self%depth < 3) then
!$omp task untied   
call self%compute()
!$omp end task  
 end if
 return
   end subroutine taskerCompute

 end module taskerMod

 program testTasks
   use :: taskerMod
   implicit none
   type(tasker) :: tasker_

   tasker_=tasker(0)
   !$omp parallel   
   !$omp single 
   !$omp taskgroup  
   !$omp task untied
   call tasker_%compute()
   !$omp end task   
   !$omp end taskgroup  
   !$omp end single 
   !$omp end parallel   
 end program testTasks

Compiling without OpenMP results in the expected behavior:
$ gfortran test.F90
$ ./a.out
 DESTRUCT FROM DEPTH   -1
 DEPTH1
 DEPTH2
 DEPTH3

There's a call to the finalizer for the tasker class (on assignment), and then
it simply reports the 3 levels of recursion that I've set it to go through.

But, if I compile with OpenMP and run just a single thread (the same problem
occurs with multiple threads also):
$ gfortran test.F90 -fopenmp
$ ./a.out
 DESTRUCT FROM DEPTH   -1
 DEPTH1
 DEPTH2
 DESTRUCT FROM DEPTH2
 DEPTH3
 DESTRUCT FROM DEPTH3

I now see calls to the finalizer from the 2nd and 3rd recursive calls to the
taskerCompute function. Since self is intent(inout) to this function I
wouldn't expect it to be finalized.

This happens with versions 12.0.0, 13.0.1, and the current HEAD of the GCC git
repo. But, ifort, does not produce the extra finalizer calls when used to
compile the above with OpenMP.

[Bug fortran/110548] New: Segfault with optional argument and OpenMP tasks

[abensonca at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110548

Bug ID: 110548
   Summary: Segfault with optional argument and OpenMP tasks
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gcc dot gnu.org
  Target Milestone: ---

The following shows a segfault at run time resulting from use of an optional
argument in a function with OpenMP tasks:

module taskerMod

   type :: helper
   end type helper

   type :: tasker
  integer :: depth=-1
contains
  final ::taskerDestruct
  procedure :: compute => taskerCompute
   end type tasker

 contains

   subroutine taskerDestruct(self)
 !$ use :: OMP_Lib  
 implicit none
 type(tasker), intent(inout) :: self

 write (0,*) "DESTRUCT FROM DEPTH ",self%depth !$ ," :
",omp_get_thread_num()  
 return
   end subroutine taskerDestruct

   recursive subroutine taskerCompute(self,helper_)
 !$ use :: OMP_Lib  
 implicit none
 class(tasker), intent(inout)   :: self
 class(helper), intent(inout), optional :: helper_

 !$omp atomic   
 self%depth=self%depth+1
 write (0,*) "DEPTH ",self%depth !$ ," : ",omp_get_thread_num() 
 if (self%depth < 3) then
!$omp task untied   
call self%compute(helper_)
!$omp end task  
 end if
 return
   end subroutine taskerCompute

 end module taskerMod

 program testTasks
   use :: taskerMod
   implicit none
   type(tasker) :: tasker_
   type(helper) :: helper_

   tasker_=tasker(0)
   !$omp parallel   
   !$omp single 
   !$omp taskgroup  
   !$omp task untied
   call tasker_%compute()
   !$omp end task   
   !$omp end taskgroup  
   !$omp end single 
   !$omp end parallel   
 end program testTasks

$ gfortran test1.F90  -fopenmp
$ ./a.out
 DESTRUCT FROM DEPTH   -1
 DEPTH1

Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.

Backtrace for this error:
#0  0x2ac99289a1ef in ???
#1  0x401840 in ???
#2  0x2ac9925a9606 in GOMP_task
at ../../../gcc-git/libgomp/task.c:644
#3  0x401588 in ???
#4  0x40197b in ???
#5  0x2ac9925a77a4 in gomp_barrier_handle_tasks
at ../../../gcc-git/libgomp/task.c:1650
#6  0x2ac9925b058f in gomp_team_barrier_wait_end
at ../../../gcc-git/libgomp/config/linux/bar.c:116
#7  0x2ac9925aeffc in gomp_team_end
at ../../../gcc-git/libgomp/team.c:956
#8  0x401692 in ???
#9  0x4016cd in ???
#10  0x2ac992886d0c in ???
#11  0x401128 in ???
Segmentation fault

This appears to be due to the optional argument, helper_. If it is present in
the initial call, i.e.:
   call tasker_%compute(helper_)

then this runs without a segfault.

This happens with versions 12.0.0, 13.0.1, and the current HEAD of the GCC git
repo.

[Bug fortran/109066] Segfault when using defined assignment

[abensonca at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066

--- Comment #5 from Andrew Benson  ---
With apologies for the long delay in replying - thanks for pointing out that I
had the result of a constructor undefined. In this updated example I think that
constructor results are now correctly defined, but the segfault still occurs:

module bugMod

  type :: rm
 integer :: c=0
   contains
 procedure :: rma
 generic   :: assignment(=) => rma
  end type rm

  type :: lc
 type(rm) :: lm
  end type lc

contains

  subroutine rma(to,from)
implicit none
class(rm), intent(  out) :: to
class(rm), intent(in   ) :: from

return
  end subroutine rma

end module bugMod

program bug
  use bugMod
  implicit none
  type(lc), pointer :: i

  allocate(i)
  i=lc(rm())
end program bug


Compiling this with current trunk results in:

> ./a.out 

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f73ba23e6ef in ???
#1  0x401299 in bug
at /home/abenson/bug.F90:32
#2  0x401310 in main
at /home/abenson/bug.F90:27
Segmentation fault (core dumped)



Changing

  type(lc), pointer :: i

to 

type(lc), allocatable :: i

or removing the defined assignment makes the segfault go away.

For what it's worth, ifort compiles and runs this without any issue.

[Bug fortran/119802] New: Defined assignment not called for component of derived type

[abensonca at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119802

Bug ID: 119802
   Summary: Defined assignment not called for component of derived
type
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gcc dot gnu.org
  Target Milestone: ---

A type-bound assignment of an allocatable component of a derived type is not
called if the parent type does not use type-bound assignment:

module bugMod

  type :: rm
 integer :: c
   contains
 procedure :: rma
 generic   :: assignment(=) => rma
  end type rm

  type :: w
 type(rm), allocatable :: wc  ! "allocatable" attribute required for this
bug
   contains
 ! uncomment the following two lines - using defined assignment avoids this
bug
 ! procedure :: wa
 ! generic   :: assignment(=) => wa
  end type w

contains

  subroutine rma(to,from)
implicit none
class(rm), intent(  out) :: to
class(rm), intent(in   ) :: from

to%c=from%c+1
return
  end subroutine rma

  subroutine wa(to,from)
implicit none
class(w), intent(  out) :: to
class(w), intent(in   ) :: from

allocate(to%wc)
to%wc=from%wc
return
  end subroutine wa

end module bugMod

program bug
  use bugMod
  implicit none
  type(w) :: i

  i=w(rm(3))
  write (0,*) "expected 4, got ",i%wc%c
end program bug

$ gfortran bug.F90
$ ./a.out
 expected 4, got3

With ifort I get:
 expected 4, got4

[Bug fortran/110626] [13/14/15 regression] Duplicated finalization in derived

[abensonca at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110626

--- Comment #5 from Andrew Benson  ---
Thanks Paul. I'm always happy to be patient - I appreciate the huge amount of
work you put in to gfortran (and the many different priorities within that
work).

[Bug fortran/119812] New: Bogus rank and type mismatch errors with procedure pointer

[abensonca at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119812

Bug ID: 119812
   Summary: Bogus rank and type mismatch errors with procedure
pointer
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gcc dot gnu.org
  Target Milestone: ---

The following code causes bogus errors when compiled with the latest trunk
using the -Wall option:

module bugMod

  type :: c
 integer :: a
  end type c

  type, extends(c) :: c1
  end type c1

  type, extends(c) :: c2
  end type c2

  type :: s
 type(c1) :: c1_
 type(c2) :: c2_
   contains
 procedure :: map => map_
  end type s

contains

  subroutine mf(self)
implicit none
class(c), intent(inout) :: self

self%a=1
return
  end subroutine mf

  subroutine map_(self,mapFunction)
implicit none
class(s), intent(inout) :: self
procedure(mf), pointer :: mapFunction 

call mapFunction(self%c1_)
call mapFunction(self%c2_)
return
  end subroutine map_

end module bugMod


> gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/carnegie/nobackup/users/abenson/upstream/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/carnegie/nobackup/users/abenson/upstream --disable-multilib
--enable-checking=release --enable-host-shared --with-pic
--enable-languages=c,c++,fortran,jit,lto
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250410 (experimental) (GCC) 



> gfortran -c bugFP.F90  -Wall
bugFP.F90:36:30:

   35 | call mapFunction(self%c1_)
  |  2
   36 | call mapFunction(self%c2_)
  |  1
Warning: Different argument lists in external dummy subroutine mapfunction at
(1) and (2) [-Wexternal-argument-mismatch]
bugFP.F90:36:21:

   35 | call mapFunction(self%c1_)
  | 2
   36 | call mapFunction(self%c2_)
  | 1
Error: Type mismatch between actual argument at (1) and actual argument at (2)
(TYPE(c2)/TYPE(c1)).



The `mapFunction` procedure pointer uses subroutine `mf` as its interface,
which accepts a `class(c)` argument, such that either of the child types (`c1`
and `c2`) should be acceptable.

The error goes away if compiled without -Wall, or if the calls to `mapFunction`
are replaced with calls to `mf` directly.

This doesn't occur with gfortran 13.3.0 so appears to be a regression.