[Bug fortran/97024] New: Overriding finalization on polymorphic types triggers ICE error in generate_finalization_wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97024 Bug ID: 97024 Summary: Overriding finalization on polymorphic types triggers ICE error in generate_finalization_wrapper Product: gcc Version: 10.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: --- Created attachment 49209 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49209&action=edit Minimum working example The attached MWE contains declarations of two derived types, one inheriting from the other. The child type contains a finalization procedure. An allocatable object of the parent class is created, and assigned to an object of the child class. This triggers an internal compiler error. GCC version: 10.5.1 System type: MacOS 10.14.6 Output from gcc -v: Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1 Apple clang version 11.0.0 (clang-1100.0.33.17) Target: x86_64-apple-darwin18.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin GCC command line: gfortran -o test.o -c test.f90 GCC compiler output: f951: internal compiler error: in generate_finalization_wrapper, at fortran/class.c:2009 libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See <https://github.com/Homebrew/homebrew-core/issues> for instructions. Adding -save-temps to the command line produced an empty file named 'test.s'
[Bug fortran/97024] Overriding finalization on polymorphic types triggers ICE error in generate_finalization_wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97024 --- Comment #1 from John Haiducek --- This bug shows some similarity to 92587 and 82996, but I suspect they are distinct. 92587 had a much more complicated MWE and the OP was unable to reduce it to a single file. 82996 did not involve class polymorphism, which seems to be required to trigger this bug. Someone with better knowledge of the compiler might be able to identify a common cause however.
[Bug fortran/97024] Overriding finalization on polymorphic types triggers ICE error in generate_finalization_wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97024 --- Comment #2 from John Haiducek --- For the sake of convenience (so there are links to click) the above-mentioned bugs were bug 92587 and bug 82996.
[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.
