[Bug fortran/116468] New: Segmentation fault at intrinsic assignment to allocatable array component of derived type with kind type parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116468 Bug ID: 116468 Summary: Segmentation fault at intrinsic assignment to allocatable array component of derived type with kind type parameter Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at archaeologic dot codes Target Milestone: --- A program compiled with gfortran terminates with a segmentation fault at an intrinsic assignment to an allocatable array component of a derived type with a kind type parameter. Please see below. I tried several workarounds, including replacing the intrinsic assignment with a type-bound defined assignment, a non-type-bound defined assignment, and a source allocation. I also tried compiling code below with gfortran 12, 13, and 14. The only workaround that eliminates the segmentation fault is switching to source allocation. The code below terminates normally with the NAG and LLVM Flang (Flang-new) compilers. % cat reproducer.f90 implicit none type foo_t(k) integer, kind :: k real(k), allocatable :: bar(:) end type type(foo_t(kind(0.))) foo foo%bar = [0.] end % gfortran reproducer.f90 % ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x102dfad2f #1 0x102df9d83 #2 0x194afa583 #3 0x1027c7f4b zsh: segmentation fault ./a.out % gfortran --version GNU Fortran (Homebrew GCC 14.1.0_2) 14.1.0
[Bug fortran/100650] Passing a derived-type array constructor to the reshape intrinsic gives incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100650 --- Comment #4 from Damian Rouson --- Thanks, Paul. No urgency. The workaround is simple and painless.
[Bug fortran/100650] Passing a derived-type array constructor to the reshape intrinsic gives incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100650 --- Comment #2 from Damian Rouson --- Is this related to PR 49324?
[Bug fortran/49324] Deep copy missing for array constructors of DT w/ allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324 Damian Rouson changed: What|Removed |Added CC||damian at archaeologic dot codes --- Comment #13 from Damian Rouson --- Is this related to 100650?
[Bug fortran/100650] Passing a derived-type array constructor to the reshape intrinsic gives incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100650 Damian Rouson changed: What|Removed |Added CC||damian at archaeologic dot codes --- Comment #1 from Damian Rouson --- Here's a shorter reproducer: % cat reshape-array-constructor.f90 type foo_t integer, allocatable :: bar(:) end type type(foo_t) foo(2,1) integer :: i, j, n(2,2,1) = reshape([-1,-1,1,1], [2,2,1]) foo = reshape([([(foo_t(merge(0, 1, n(:,i,j) > 0)), i=1,2)], j=1,1)], [2,1]) print *, merge(0, 1, n(:,1,1) > 0), foo(1,1)%bar print *, merge(0, 1, n(:,2,1) > 0), foo(2,1)%bar end % gfortran reshape-array-constructor.f90 % ./a.out 1 1 -358465392 24440 0 0 -358465392 24440 % gfortran --version GNU Fortran (Homebrew GCC 13.1.0) 13.1.0 Another workaround in the above example is to make n a constant array via integer, parameter :: n(*,*,*) = reshape([-1,-1,1,1], [2,2,1])
[Bug fortran/107406] New: lock_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107406 Bug ID: 107406 Summary: lock_type Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at archaeologic dot codes Target Milestone: --- gfortran 12.2 accepts the code below if the "allocatable" attribute is removed: % cat gfortran-lock-issue.f90 use iso_fortran_env type foo type(lock_type), allocatable :: bar end type type(foo) foobar[*] end % gfortran -fcoarray=single gfortran-lock-issue.f90 gfortran-lock-issue.f90:3:39: 3 | type(lock_type), allocatable :: bar | 1 Error: Allocatable component bar at (1) of type LOCK_TYPE must have a codimension The NAG compiler accepts the above code and I believe constraint C1608 in the Fortran 2018 standard makes the above code valid. Is this related to PR 92122?
[Bug fortran/105542] [F03] Orthogonal standard-conforming type finalization tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105542 --- Comment #2 from Damian Rouson --- Thanks for trying this, Jerry. Brad encountered a similar issue, which I think he resolved so I'll I'll ask him to comment here.
[Bug fortran/105542] New: [F03] Orthogonal standard-conforming type finalization tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105542 Bug ID: 105542 Summary: [F03] Orthogonal standard-conforming type finalization tests Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at archaeologic dot codes Target Milestone: --- In case it's useful to gfortran developers, the Reference-Counter repository (https://github.com/sourceryinstitute/reference-counter) contains a test/compiler_test.f90 file that separately tests each of the scenarios in which Fortran 2018 clause 7.5.6.3 requires type finalization to occur. One function tests each scenario. A comment near the top of each such function cites the paragraph number of the corresponding requirement. To download and run the tests on macOS or Linux with gfortran 12.1.0 and the Fortran Package Manager (fpm) already installed, execute the following commands: git clone https://github.com/sourceryinstitute/reference-counter cd reference-counter fpm test for which the trailing output is Running Tests Test that The compiler finalizes a non-allocatable object on the LHS of an intrinsic assignment finalizes an allocated allocatable LHS of an intrinsic assignment finalizes a target when the associated pointer is deallocated finalizes an object upon explicit deallocation finalizes a non-pointer non-allocatable array object at the END statement finalizes a non-pointer non-allocatable object at the end of a block construct finalizes a function reference on the RHS of an intrinsic assignment finalizes a specification expression function result finalizes an intent(out) derived type dummy argument finalizes an allocatable component object A ref_reference does not leak when constructed, assigned, and then explicitly freed A total of 11 test cases Failed Took 1.94e-4 seconds Test that The compiler finalizes a non-allocatable object on the LHS of an intrinsic assignment Expected |1| but got |0| finalizes an allocated allocatable LHS of an intrinsic assignment Expected |1| but got |0| finalizes a function reference on the RHS of an intrinsic assignment Expected |1| but got |0| finalizes a specification expression function result Expected |1| but got |0| 4 of 11 cases failed 4 of 11 assertions failed STOP 1 Execution failed for object " reference-counter-test " *cmd_run*:stopping due to failed executions STOP 1
[Bug fortran/65347] [F03] Final subroutine not called for function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65347 Damian Rouson changed: What|Removed |Added CC||damian at archaeologic dot codes --- Comment #3 from Damian Rouson --- I suspect the code below is a simpler reproducer (25 lines) of this bug % cat missing-finalization.f90 module object_m implicit none type object_t contains final :: count_finalizations end type contains subroutine count_finalizations(self) type(object_t) self print *,"finalization" end subroutine function new_object() type(object_t) new_object end function end module use object_m implicit none type(object_t) object object = new_object() end % gfortran missing-finalization.f90 % ./a.out % gfortran --version GNU Fortran (Homebrew GCC 11.2.0_3) 11.2.0
[Bug fortran/104404] New: Incorrect CFI_cdesc_t "type" member for assumed-type, assumed-rank complex dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104404
Bug ID: 104404
Summary: Incorrect CFI_cdesc_t "type" member for assumed-type,
assumed-rank complex dummy arguments
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at archaeologic dot codes
Target Milestone: ---
For an assumed-type, assumed-rank complex dummy argument in a C interface,
gfortran 11.2.0 passes a CFI_cdesc_t object with a "type" member that does not
match the corresponding CFI_type_float_Complex and CFI_type_double_Complex
values. Ian the case of a complex(c_float_complex) argument, passed "type"
member corresponds to CFI_type_double_Complex. For a complex(c_double_complex)
argument, the "type" member has a value that I don't recognize. Does anyone
know whether this has been fixed on the 12 branch?
% cat c_descriptor.c
#include
#include
void c_descriptor(CFI_cdesc_t* c)
{
printf("a_desc->type = %d \n", c->type);
printf("a_desc->elem_len = %d \n", c->elem_len);
printf("CFI_type_float_Complex = %d \n", CFI_type_float_Complex);
printf("CFI_type_double_Complex = %d \n", CFI_type_double_Complex);
}
% cat c_descriptor.c
#include
#include
void c_descriptor(CFI_cdesc_t* c)
{
printf("a_desc->type = %d \n", c->type);
printf("a_desc->elem_len = %d \n", c->elem_len);
printf("CFI_type_float_Complex = %d \n", CFI_type_float_Complex);
printf("CFI_type_double_Complex = %d \n", CFI_type_double_Complex);
}
(base) rouson@CLaSS adhoc % cat assumed-type.f90
module c_descriptor_m
implicit none
contains
module subroutine print_type_info(a)
type(*), intent(inout), contiguous, target :: a(..)
interface
subroutine c_descriptor(a) bind(C)
implicit none
type(*) a(..)
end subroutine
end interface
call c_descriptor(a)
end subroutine
end module
use c_descriptor_m
use iso_c_binding
implicit none
complex(c_float_complex) :: z_float = (0._c_float, 0._c_float)
complex(c_double_complex):: z_double = (0._c_double, 0._c_double)
print*, "- complex(c_float_complex) "
call print_type_info(z_float)
print*, "- complex(c_double_complex) ---"
call print_type_info(z_double)
end
% gfortran c_descriptor.c assumed-type.f90
% ./a.out
- complex(c_float_complex)
a_desc->type = 2052
a_desc->elem_len = 8
CFI_type_float_Complex = 1028
CFI_type_double_Complex = 2052
- complex(c_double_complex) ---
a_desc->type = 4100
a_desc->elem_len = 16
CFI_type_float_Complex = 1028
CFI_type_double_Complex = 2052
% gfortran --version
GNU Fortran (Homebrew GCC 11.2.0_3) 11.2.0
