[Bug fortran/100743] New: Segmentation fault passing a polymorphic as an optional argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100743 Bug ID: 100743 Summary: Segmentation fault passing a polymorphic as an optional argument Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jhaiduce at gmail dot com Target Milestone: --- The following program crashes with a segmentation fault: ``` module my_exceptions implicit none type::error_container end type error_container type, abstract::base_exception end type base_exception type, extends(base_exception)::exception end type exception contains function new_exception() type(exception)::new_exception end function new_exception subroutine throw(status,exc) type(error_container), intent(inout), optional::status class(base_exception)::exc end subroutine throw subroutine test_throw(status) class(error_container), intent(inout), optional::status call throw(status,new_exception()) end subroutine test_throw end module my_exceptions program test use my_exceptions, ONLY: error_container, test_throw implicit none type(error_container)::status call test_throw() end program test ``` It works as expected when compiled with ifort. With gfortran it produces a segmentation fault. The problem occurs with multiple versions of gfortran (have tried 4.9.4, 7.5.0, 10.2.0, 10.3.0, 11.1.0). The segmentation fault does not occur if the optional status argument is declared as non-polymorphic type (i.e. ```type(error_container)``` instead of ```class(error_container)```).
[Bug fortran/100814] New: Fortran memory error on assignment from polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100814 Bug ID: 100814 Summary: Fortran memory error on assignment from polymorphic variable Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jhaiduce at gmail dot com Target Milestone: --- The following code produces a memory error when compiled with recent versions of gfortran: ``` module distributed_array implicit none type :: darray_segment integer::rank integer::offset integer::length real(kind=8), allocatable::data(:) contains end type darray_segment type :: darray type(darray_segment), allocatable::segments(:) end type darray contains function new_darray(segments) class(darray_segment), intent(in)::segments(:) type(darray)::new_darray new_darray%segments = segments end function new_darray end module distributed_array program test_darray use distributed_array, ONLY: darray, darray_segment, new_darray implicit none integer, parameter::np_src = 4 integer, parameter::np_dest = 3 type(darray)::src_darray type(darray)::dest_darray type(darray_segment)::src_segments(np_src) type(darray_segment)::dest_segments(np_dest) src_darray = new_darray(src_segments) dest_darray = new_darray(dest_segments) end program test_darray ``` The above code runs without error when compiled with gfortran 4.9.4 and 10.2, but when compiled with gfortran 10.3 and 11.1 it produces the following output: ``` darray_test: malloc.c:2385: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x7f727c59fbf0 in ??? #1 0x7f727c59ee45 in ??? #2 0x7f727c20d83f in ??? at /build/glibc-vjB4T1/glibc-2.28/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 #3 0x7f727c20d7bb in __GI_raise at ../sysdeps/unix/sysv/linux/raise.c:51 #4 0x7f727c1f8534 in __GI_abort at /build/glibc-vjB4T1/glibc-2.28/stdlib/abort.c:79 #5 0x7f727c255a67 in __malloc_assert at /build/glibc-vjB4T1/glibc-2.28/malloc/malloc.c:298 #6 0x7f727c257e6e in sysmalloc at /build/glibc-vjB4T1/glibc-2.28/malloc/malloc.c:2382 #7 0x7f727c2592c8 in _int_malloc at /build/glibc-vjB4T1/glibc-2.28/malloc/malloc.c:4133 #8 0x7f727c25a3e2 in __GI___libc_malloc at /build/glibc-vjB4T1/glibc-2.28/malloc/malloc.c:3049 #9 0x401f10 in __distributed_array_MOD_new_darray at /test/src/test/darray_tests.F90:23 #10 0x402933 in test_darray at /test/src/test/darray_tests.F90:44 #11 0x402aaf in main at /test/src/test/darray_tests.F90:31 ``` The code also runs without error when compiled with ifort 2021.2. The problem appears to be triggered by the assignment `new_darray%segments = segments`. The error can be prevented by changing the declaration `class(darray_segment), intent(in)::segments(:)` to `type(darray_segment), intent(in)::segments(:)` (replacing class with type), or by replacing the assignment with an explicit allocation: `allocate( new_darray%segments, source= segments )`.
[Bug fortran/110987] Segmentation fault after finalization of a temporary variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987 John Haiducek changed: What|Removed |Added CC||jhaiduce at gmail dot com --- Comment #5 from John Haiducek --- Created attachment 57326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57326&action=edit Additional test case This is an additional test case, which appears to trigger the same bug under slightly different circumstances.
[Bug fortran/110987] Segmentation fault after finalization of a temporary variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987 --- Comment #6 from John Haiducek --- I encountered what appears to be the same bug under slightly different conditions; I've attached the corresponding code (see attachment named "Additional test case"). In this code the crash occurs when finalizing an object of a type that inherits from a parent type, where the child type has no data members of its own. There are several workarounds that prevent the segmentation fault in this test: - Create the object with the default constructor rather than using a custom constructor - Add a data member to the child type - Remove the final routine from the child type I posted the code in the attached "Additional test case" on the Fortran Discourse (see discussion at https://fortran-lang.discourse.group/t/segmentation-fault-when-finalizing-an-inherited-type-with-custom-constructor/7319). >From the discussion it was determined that this code triggers a segmentation fault with the following compiler/OS combinations: - gfortran 13.2.0 on Ubuntu 23.10 and FreeBSD 14.0 - gfortran 13.2.1 on Fedora 38 - gfortran 13.2.0-13.2.1 on MacOS (arm) The segmentation fault does not occur on the following compiler/OS combinations: - gfortran 11.4.0 on Ubuntu 23.10 - gfortran 12.2.0 on FreeBSD 14.0 - gfortran 14.0.1 experimental on Windows (but in this case there are still indications of incorrect behavior; no segfault occurred but a print statement added to the end of the code did not produce any output) The program also reportedly runs as expected when compiled with ifort.
