[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #10 from Neil Carlson --- Thanks Harald for hunting this down! I've tested your patch on master with -fsanitize=address against my library that turned up these errors and it all looks good now. Is it possible to back port this to the 12 branch?
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #6 from Neil Carlson --- Here's a variation of the example involving arrays. I expect the source of the failure here is the same, but I want to be sure this example is also fixed by the eventual patch. program main call run contains subroutine run class(*), allocatable :: y(:) call foo(['fubar','fubar'], y) end subroutine subroutine foo(a, b) class(*), intent(in) :: a(:) class(*), allocatable :: b(:) b = a !allocate(b, source=a) ! VALGRIND REPORTS NO INVALID WRITES end subroutine end program Compiled with -fsanitize=address and executed gives this: ==1338704==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200072 at pc 0x7fb456a4c8d1 bp 0x7ffcfd375d50 sp 0x7ffcfd375500 WRITE of size 5 at 0x60200072 thread T0 #0 0x7fb456a4c8d0 in __interceptor_memmove ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:810 #1 0x4012d4 in __copy_character_1 /home/nnc/Codes/petaca/bugs/fubar.f90:1 #2 0x401c9f in foo /home/nnc/Codes/petaca/bugs/fubar.f90:11 #3 0x4023e8 in run /home/nnc/Codes/petaca/bugs/fubar.f90:6 #4 0x40137e in MAIN__ /home/nnc/Codes/petaca/bugs/fubar.f90:2 #5 0x4027a1 in main /home/nnc/Codes/petaca/bugs/fubar.f90:2 #6 0x7fb4563ff149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) #7 0x7fb4563ff20a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) #8 0x401184 in _start (/home/nnc/Codes/petaca/bugs/a.out+0x401184) 0x60200072 is located 0 bytes to the right of 2-byte region [0x60200070,0x60200072) allocated by thread T0 here: #0 0x7fb456abd69f in __interceptor_malloc ../../../../libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x401965 in foo /home/nnc/Codes/petaca/bugs/fubar.f90:11 #2 0x4023e8 in run /home/nnc/Codes/petaca/bugs/fubar.f90:6 #3 0x40137e in MAIN__ /home/nnc/Codes/petaca/bugs/fubar.f90:2 #4 0x4027a1 in main /home/nnc/Codes/petaca/bugs/fubar.f90:2 #5 0x7fb4563ff149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) #6 0x7fb4563ff20a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) #7 0x401184 in _start (/home/nnc/Codes/petaca/bugs/a.out+0x401184) SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:810 in __interceptor_memmove
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #4 from Neil Carlson --- Same results with 13.2.0 configured with --enable-valgrind-annotations. Here's the output with 13.2.0 and gfortran -g -O0 -fsanitize=address foo.f90 : ==1126830==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200071 at pc 0x7fb97cc6b21d bp 0x7ffcd7a79200 sp 0x7ffcd7a789c0 WRITE of size 27 at 0x60200071 thread T0 #0 0x7fb97cc6b21c in __interceptor_memmove ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:882 #1 0x4012ca in __copy_character_1 /home/nnc/Codes/petaca/bugs/foo.f90:1 #2 0x401a14 in foo /home/nnc/Codes/petaca/bugs/foo.f90:11 #3 0x401cf9 in run /home/nnc/Codes/petaca/bugs/foo.f90:6 #4 0x401374 in MAIN__ /home/nnc/Codes/petaca/bugs/foo.f90:2 #5 0x401fc6 in main /home/nnc/Codes/petaca/bugs/foo.f90:2 #6 0x7fb97c646149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: e0b579ca7024cf12a2686b60cf49d1d9e3ff6273) #7 0x7fb97c64620a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) (BuildId: e0b579ca7024cf12a2686b60cf49d1d9e3ff6273) #8 0x401194 in _start (/home/nnc/Codes/petaca/bugs/a.out+0x401194) 0x60200071 is located 0 bytes after 1-byte region [0x60200070,0x60200071) allocated by thread T0 here: #0 0x7fb97ccdc2ef in __interceptor_malloc ../../../../libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x4017c9 in foo /home/nnc/Codes/petaca/bugs/foo.f90:11 #2 0x401cf9 in run /home/nnc/Codes/petaca/bugs/foo.f90:6 #3 0x401374 in MAIN__ /home/nnc/Codes/petaca/bugs/foo.f90:2 #4 0x401fc6 in main /home/nnc/Codes/petaca/bugs/foo.f90:2 #5 0x7fb97c646149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: e0b579ca7024cf12a2686b60cf49d1d9e3ff6273) #6 0x7fb97c64620a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) (BuildId: e0b579ca7024cf12a2686b60cf49d1d9e3ff6273) #7 0x401194 in _start (/home/nnc/Codes/petaca/bugs/a.out+0x401194) SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:882 in __interceptor_memmove Shadow bytes around the buggy address: 0x601ffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601ffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601ffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x6020: fa fa 06 fa fa fa 07 fa fa fa 07 fa fa fa[01]fa 0x60200080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x60200100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x60200180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x60200200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x60200280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==1126830==ABORTING
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #3 from Neil Carlson --- Those results are with 12.3.0 configured with --enable-valgrind-annotations. I'm building 13.2.0 now with the same to see if more info is generated. (I don't typically use 13.x because it finalization is broken for our code after 12.)
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #1 from Neil Carlson --- I should add that I get the same results with gcc versions going back to at least gcc 11.
[Bug fortran/114827] New: Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
Bug ID: 114827
Summary: Valgrind reports errors with class(*) assignment
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
I'm trying to pin down a malloc corruption error ("malloc(): corrupted top
size") that happens during finalization of a derived type object. I'm still
working on paring things down to a reportable reproducer, but the traceback
hinted at a possible problem with the assignment of a class(*) variable to
another allocatable class(*) variable when the dynamic type of the rhs is
character. I've turned that bit into the following example which compiles and
runs without error, but when run under valgrind it reports several invalid
writes, which suggests to me that the executable is doing something wrong.
Note that if the assignment to the allocatable class(*) variable is replaced by
a sourced-allocation, the valgrind output is completely clean.
$ cat foo.f90
program main
call run
contains
subroutine run
class(*), allocatable :: y
call foo('fubarfubarfubarfubarfubarfu', y)
end subroutine
subroutine foo(a, b)
class(*), intent(in) :: a
class(*), allocatable :: b
b = a
!allocate(b, source=a) ! VALGRIND REPORTS NO INVALID WRITES
end subroutine
end program
$ gfortran -g -O0 foo.f90
$ valgrind -s ./a.out
==587107== Memcheck, a memory error detector
==587107== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==587107== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==587107== Command: ./a.out
==587107==
==587107== Invalid write of size 2
==587107==at 0x484F353: memmove (vg_replace_strmem.c:1410)
==587107==by 0x401230: __copy_character_1.0 (foo.f90:1)
==587107==by 0x401368: foo.1 (foo.f90:11)
==587107==by 0x4013E1: run.2 (foo.f90:6)
==587107==by 0x401258: MAIN__ (foo.f90:2)
==587107==by 0x401485: main (foo.f90:2)
==587107== Address 0x4e57ac0 is 0 bytes inside a block of size 1 alloc'd
==587107==at 0x484280F: malloc (vg_replace_malloc.c:442)
==587107==by 0x4012C2: foo.1 (foo.f90:11)
==587107==by 0x4013E1: run.2 (foo.f90:6)
==587107==by 0x401258: MAIN__ (foo.f90:2)
==587107==by 0x401485: main (foo.f90:2)
==587107==
==587107== Invalid write of size 1
==587107==at 0x484F383: memmove (vg_replace_strmem.c:1410)
==587107==by 0x401230: __copy_character_1.0 (foo.f90:1)
==587107==by 0x401368: foo.1 (foo.f90:11)
==587107==by 0x4013E1: run.2 (foo.f90:6)
==587107==by 0x401258: MAIN__ (foo.f90:2)
==587107==by 0x401485: main (foo.f90:2)
==587107== Address 0x4e57ada is 10 bytes after a block of size 16 in arena
"client"
==587107==
==587107==
==587107== HEAP SUMMARY:
==587107== in use at exit: 0 bytes in 0 blocks
==587107== total heap usage: 22 allocs, 22 frees, 13,585 bytes allocated
==587107==
==587107== All heap blocks were freed -- no leaks are possible
==587107==
==587107== ERROR SUMMARY: 27 errors from 2 contexts (suppressed: 0 from 0)
==587107==
==587107== 1 errors in context 1 of 2:
==587107== Invalid write of size 1
==587107==at 0x484F383: memmove (vg_replace_strmem.c:1410)
==587107==by 0x401230: __copy_character_1.0 (foo.f90:1)
==587107==by 0x401368: foo.1 (foo.f90:11)
==587107==by 0x4013E1: run.2 (foo.f90:6)
==587107==by 0x401258: MAIN__ (foo.f90:2)
==587107==by 0x401485: main (foo.f90:2)
==587107== Address 0x4e57ada is 10 bytes after a block of size 16 in arena
"client"
==587107==
==587107==
==587107== 26 errors in context 2 of 2:
==587107== Invalid write of size 2
==587107==at 0x484F353: memmove (vg_replace_strmem.c:1410)
==587107==by 0x401230: __copy_character_1.0 (foo.f90:1)
==587107==by 0x401368: foo.1 (foo.f90:11)
==587107==by 0x4013E1: run.2 (foo.f90:6)
==587107==by 0x401258: MAIN__ (foo.f90:2)
==587107==by 0x401485: main (foo.f90:2)
==587107== Address 0x4e57ac0 is 0 bytes inside a block of size 1 alloc'd
==587107==at 0x484280F: malloc (vg_replace_malloc.c:442)
==587107==by 0x4012C2: foo.1 (foo.f90:11)
==587107==by 0x4013E1: run.2 (foo.f90:6)
==587107==by 0x401258: MAIN__ (foo.f90:2)
==587107==by 0x401485: main (foo.f90:2)
==587107==
==587107== ERROR SUMMARY: 27 errors from 2 contexts (suppressed: 0 from 0)
[Bug fortran/112964] New: ICE for recursive subroutine with assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112964 Bug ID: 112964 Summary: ICE for recursive subroutine with assumed rank class(*) argument Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- I'm getting an internal compiler error with the following reduced example. Note that the ICE disappears if CLASS(*) is replaced by INTEGER, for example. call foo([1,2]) contains recursive subroutine foo(x) class(*), intent(in) :: x(..) integer :: n select rank (x) rank (0) rank (1) do n = 1, size(x,1) call foo(x(n)) end do end select end subroutine end And the output from compilation: $ gfortran -freport-bug gfortran-20231211.f90 gfortran-20231211.f90:10:20: 10 | call foo(x(n)) |1 internal compiler error: Segmentation fault 0xd0317f crash_signal ../../gcc/toplev.cc:314 0x82830b gfc_conv_class_to_class(gfc_se*, gfc_expr*, gfc_typespec, bool, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:1207 0x823dff gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.cc:6661 0x86bc82 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.cc:424 0x7ea3eb trans_code ../../gcc/fortran/trans.cc:2297 0x870a63 gfc_trans_simple_do ../../gcc/fortran/trans-stmt.cc:2492 0x870a63 gfc_trans_do(gfc_code*, tree_node*) ../../gcc/fortran/trans-stmt.cc:2624 0x7ea37a trans_code ../../gcc/fortran/trans.cc:2329 0x86ffd0 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.cc:2353 0x7ea337 trans_code ../../gcc/fortran/trans.cc:2325 0x8672c5 gfc_trans_select_rank_cases ../../gcc/fortran/trans-stmt.cc:3778 0x871b54 gfc_trans_select_rank(gfc_code*) ../../gcc/fortran/trans-stmt.cc:3833 0x7ea077 trans_code ../../gcc/fortran/trans.cc:2349 0x86ffd0 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.cc:2353 0x7ea337 trans_code ../../gcc/fortran/trans.cc:2325 0x818509 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7715 0x8182fc gfc_generate_contained_functions ../../gcc/fortran/trans-decl.cc:5830 0x8182fc gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7647 0x78f0fe translate_all_program_units ../../gcc/fortran/parse.cc:6720 0x78f0fe gfc_parse_file() ../../gcc/fortran/parse.cc:7026
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #9 from Neil Carlson --- Bug is still present in 13.2.0.
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #12 from Neil Carlson --- Paul, > [...] there are some humdingers going back a long way that I will take a look > at, > once I am done with associate. That would be great, thanks!
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #9 from Neil Carlson --- > > (i) Have I got the lot? > I believe so. > (ii) Are there existing PRs for the two most recent? > I always try to report the bugs at the same time they go into my "database". The first is here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033 But the second one I assumed was an opencoarrays problem; or at least I decided that was the place to start. My report is here: https://github.com/sourceryinstitute/OpenCoarrays/issues/748 But I never heard back from them -- the project has been effectively abandoned as far as I'm concerned -- and I had forgotten to follow up on it. However the problem may actually be on the gfortran side. You're welcome to enter a PR for it, or I can if you would prefer that. -Neil
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #7 from Neil Carlson --- > Was it as a result of the nagfor error, perhaps? If so, have you already sent > them a bug report? I actually didn't originally try that commented-out assignment with nagfor, but confirm that it gets it wrong as you said. I'll give you the honor of submitting a bug report. nagfor does get the ASSOCIATE part correct, which was what I was what I was after in the first place when I encountered this bug.
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #5 from Neil Carlson --- >> !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED > > I could have phrased the comment better. I expected that assignment to be okay > (i.e., not rejected) and it wasn't. Sorry for the confusion. Argh, I'm just making things worse. That assignment was okay and WAS what I expected.
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #4 from Neil Carlson --- Hi Paul, > !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED I could have phrased the comment better. I expected that assignment to be okay (i.e., not rejected) and it wasn't. Sorry for the confusion.
[Bug fortran/110224] New: Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 Bug ID: 110224 Summary: Rejects valid: function reference with data pointer result as lhs in assignment Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- According to 9.2 of the F18 standard, a function reference that returns a data pointer is a variable and can be used in variable definition contexts. In particular it can be used as the selector in an associate construct (11.1.3.1, C1101), however gfortran rejects this as invalid as shown by the following example module mod type :: foo real, pointer :: var contains procedure :: var_ptr end type contains function var_ptr(this) result(ref) class(foo) :: this real, pointer :: ref ref => this%var end function end module program main use mod type(foo) :: x associate (var => x%var_ptr()) var = 1.0 end associate !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED end program gfortran-20230612.f90:36:4: 36 | var = 1.0 |1 Error: ‘var’ at (1) associated to expression cannot be used in a variable definition context (assignment)
[Bug fortran/110033] rejects-valid: associate name corresponding to coarray selector should be considered a coarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033 --- Comment #1 from Neil Carlson --- This must be related to PR78152
[Bug fortran/110033] New: rejects-valid: associate name corresponding to coarray selector should be considered a coarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033 Bug ID: 110033 Summary: rejects-valid: associate name corresponding to coarray selector should be considered a coarray Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- In the following example, the associate name Y corresponds to a coarray. According to 11.1.3.3 par. 2 (f2018), Y should be regarded as a coarray, however gfortran rejects this as invalid. real :: x[*] associate (y => x) y[1] = 1.0 end associate end gfortran -fcoarray=lib gfortran-20230529.f90 gfortran-20230529.f90:18:4: 18 | y[1] = 1.0 |1 Error: Coarray designator at (1) but ‘y’ is not a coarray
[Bug fortran/110012] New: ICE involving parametrized polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110012 Bug ID: 110012 Summary: ICE involving parametrized polymorphic variable Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- I get an ICE with the following example: module pde_class type, abstract :: pde(npde) integer,len :: npde end type end module module navier_stokes_type use pde_class type, extends(pde) :: navier_stokes end type contains subroutine alloc_navier_stokes(p) class(pde(:)), allocatable :: p allocate(navier_stokes(npde=3) :: p) end subroutine end module module mfe_disc_type use pde_class type :: foo class(pde(:)), allocatable :: p end type end module $ gfortran gfortran-20230527.f90 -c f951: internal compiler error: in resolve_fl_derived, at fortran/resolve.cc:15532 0x699d67 resolve_fl_derived ../../gcc/fortran/resolve.cc:15532 0x79c3df resolve_symbol ../../gcc/fortran/resolve.cc:15916 0x7c7c32 do_traverse_symtree ../../gcc/fortran/symbol.cc:4190 0x7a77ce resolve_types ../../gcc/fortran/resolve.cc:17879 0x7aeb0c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17994 0x78dedf gfc_parse_file() ../../gcc/fortran/parse.cc:6861 0x7e63bf gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229 Please submit a full bug report, with preprocessed source (by using -freport-bug).
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #8 from Neil Carlson --- We've been bitten by what looks to be the same bug in our large Fortran code: 245 | end module kuprat_mapper_type | 1 Error: Contained procedure ‘__final_integer_set_type_wavl_Integer_set’ at (1) of a PURE procedure must also be PURE This one really had me baffled. The kuprat_mapper type has no component (or component of component) of the integer_set type, nor any pure procedures. At most, some procedure associated with the kuprat_mapper type has a local integer_set variable. In any event, the integer_set type does have a final procedure and it is pure! What's more baffling is why this error occurred at this point; the integer_set module compiled without error as did many other module files that use it. Note that the code compiles fine with the oneAPI ifort and NAG compilers (and also with gfortran 12.2 and earlier). I haven't attempted yet to try and pare things down to a reportable reproducer, but if it would help I could try to do so.
[Bug fortran/109846] [rejects valid] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 --- Comment #2 from Neil Carlson --- Amusing! I have a regression in 13.1 (which I need to create a reproducer for) where the workaround for a segfault is to use a RESULT variable -- just the opposite :-)
[Bug fortran/109846] New: [rejects valid] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 Bug ID: 109846 Summary: [rejects valid] Pointer-valued function reference rejected as actual argument Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Gfortran rejects the following example. module foo type :: parameter_list contains procedure :: sublist end type contains function sublist(this) result(slist) class(parameter_list), intent(inout) :: this class(parameter_list), pointer :: slist allocate(slist) end function end module program example use foo type(parameter_list) :: plist call sub(plist%sublist()) contains subroutine sub(plist) type(parameter_list), intent(inout) :: plist end subroutine end program With this error: 17 | call sub(plist%sublist()) | 1 Error: ‘sublist’ in variable definition context (actual argument to INTENT = OUT/INOUT) at (1) is not a variable It is accepted by both Intel OneAPI and NAG compilers. The sublist function returns a polymorphic pointer, which seems to be the source of the error. If it is modified to return a non-polymorphic pointer the example compiles without error. Alternatively, if the dummy argument intent is changed to intent(in) it also compiles without error. It is valid for a class(parameter_list) variable to be the actual argument for a type(parameter_list), intent(inout) dummy argument. So in light of 9.2/C902 (2018) I think this is a gfortran bug.
[Bug fortran/104630] New: module subroutine not accessible from submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104630 Bug ID: 104630 Summary: module subroutine not accessible from submodule Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Consider this minimal example. File module.f90: module modA private type, public :: typeA contains procedure :: foo end type interface module subroutine foo(this) class(typeA) :: this end subroutine end interface contains subroutine bar(this) type(typeA) :: this end subroutine end module File submodule.f90: submodule(modA) foo_impl contains module subroutine foo(this) class(typeA) :: this call bar(this) ! a module subroutine in the host module end subroutine end submodule File main.f90: use modA end The implementation of subroutine foo in the submodule should have access to subroutine bar defined in its host module but it apparently does not judging from the link error: $ gfortran module.f90 submodule.f90 main.f90 /usr/bin/ld: /tmp/ccEycu6t.o: in function `__moda_MOD_foo': gfortran-20220221-submodule.f90:(.text+0x17): undefined reference to `__moda_MOD_bar' collect2: error: ld returned 1 exit status If the 3 program units are combined into a single file, that will compile and link without error.
[Bug fortran/103394] Bad object code for structure constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103394 --- Comment #1 from Neil Carlson --- I've experimented some more and have reduced things further to this example. I'm not positive it captures everything that is going wrong in the original. program example type :: foo end type type :: bar type(foo), pointer :: fptr end type class(foo), pointer :: f allocate(foo :: f) call sub(bar(f)) contains subroutine sub(b) type(bar), intent(in) :: b if (.not.associated(b%fptr, f)) stop 1 end subroutine end program The example works correctly if "class(foo), pointer :: f" is replaced by "type(foo), pointer :: f", so it seems pretty clear that intrinsic structure constructor is not properly making the assignment "bar%fptr => f".
[Bug fortran/103394] New: Bad object code for structure constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103394 Bug ID: 103394 Summary: Bad object code for structure constructor Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Bad object code is being generated for the structure constructor expression in the example below. This occurs for the current 12.0 trunk and any of the earlier 9.x, 10.x and 11.x versions I've tried. It seems that things go wrong with the expression foo_vector_func(this) when both the foo_vector_func type is an extension and the variable this is also polymorphic. module foo_type type :: foo contains procedure :: alloc_foo_vector_func end type type, abstract :: vector_func end type type, extends(vector_func) :: foo_vector_func type(foo), pointer :: ptr end type contains subroutine alloc_foo_vector_func(this, vf) class(foo), intent(in), target :: this class(vector_func), allocatable, intent(out) :: vf allocate(vf, source=foo_vector_func(this)) ! DOESN'T WORK CORRECTLY !vf = foo_vector_func(this) ! DOESN'T WORK EITHER end subroutine end module program main use foo_type type(foo), target :: x class(vector_func), allocatable :: vf call x%alloc_foo_vector_func(vf) select type (vf) type is (foo_vector_func) if (.not.associated(vf%ptr, x)) stop 1 ! SHOULD NOT EXIT HERE end select end program
[Bug fortran/100815] [10.3, 11 regression] Segfault assigning to scalar allocatable polymorphic LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815 --- Comment #1 from Neil Carlson --- Actually it looks like the regression was introduced in 10.3. It works in 10.2 and earlier.
[Bug fortran/100815] New: [11 regression] Segfault assigning to scalar allocatable polymorphic LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815 Bug ID: 100815 Summary: [11 regression] Segfault assigning to scalar allocatable polymorphic LHS Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- The current head of the gcc-11 branch segfaults on the assignment statement in the following program. The program runs without error with the 10.x and 9.x compilers. type, abstract :: func end type type, extends(func) :: const_func real :: c = 0.0 end type type :: func_box class(func), allocatable :: f end type type :: foo type(func_box), allocatable :: farray(:) end type type(const_func) :: f type(foo) :: this allocate(this%farray(2)) this%farray(size(this%farray))%f = f end
[Bug fortran/93762] Truncation of deferred-length string when passing as optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93762 --- Comment #4 from Neil Carlson --- It would be great if somebody possessing the necessary skills could invest the time to fix this. For me this is bug breaks a common usage pattern of including optional stat, errmsg arguments to procedure interfaces.
