[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.
[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/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/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] 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/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/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/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/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/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/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] 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 #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 #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 #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/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/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/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/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/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/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] 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 #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 #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 #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/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/117774] New: ICE passing imaginary part of complex array to assumed rank dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117774 Bug ID: 117774 Summary: ICE passing imaginary part of complex array to assumed rank dummy Product: gcc Version: 14.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 compiler segfaults on the line where the imaginary part of a complex array is passed to an assumed-rank dummy argument. Interestingly it has no problem with passing the real part. module mod contains subroutine foo(r) real, intent(in) :: r(..) ! ASSUMED-RANK DUMMY end subroutine end module use mod complex :: x(3,10) call foo(x%re) ! COMPILES WITHOUT ERROR call foo(x%im) ! INTERNAL COMPILER ERROR end The traceback: $ gfortran gfortran-20241125.f90 gfortran-20241125.f90:11:40: 11 | call foo(x%im) ! INTERNAL COMPILER ERROR |1 internal compiler error: Segmentation fault 0xdff61f crash_signal ../../gcc/toplev.cc:319 0x8ae07b gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.cc:7149 0x8f8362 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.cc:425 0x870edb trans_code ../../gcc/fortran/trans.cc:2431 0x8a0ea4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7880 0x812d46 translate_all_program_units ../../gcc/fortran/parse.cc:7099 0x812d46 gfc_parse_file() ../../gcc/fortran/parse.cc:7413 0x86dc6f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:241
[Bug fortran/117797] New: [15 Regression] ICE in gfc_get_array_span
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117797 Bug ID: 117797 Summary: [15 Regression] ICE in gfc_get_array_span Product: gcc Version: 14.2.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 following example trips a recent regression. It segfaults with 13.3.1, 14.2.1, and 15, but not with 13.3.0 or 14.2.0. module foo type, public :: any_matrix private class(*), allocatable :: value(:,:) end type contains function bar(this) result(uptr) class(any_matrix), target, intent(in) :: this class(*), pointer :: uptr(:,:) uptr => this%value end function end module Here's the traceback: $ gfortran -c gfortran-20241126.f90 gfortran-20241126.f90:13:22: 13 | uptr => this%value | 1 internal compiler error: Segmentation fault 0x26ac91e internal_error(char const*, ...) ../../gcc/diagnostic-global-context.cc:517 0x115cb76 crash_signal ../../gcc/toplev.cc:322 0xacc686 gfc_get_array_span(tree_node*, gfc_expr*) ../../gcc/fortran/trans-array.cc:998 0xadb80e gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-array.cc:8097 0xb1be25 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:10801 0xac3837 trans_code ../../gcc/fortran/trans.cc:2336 0xafb4b0 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7961 0xac8ef1 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.cc:2753 0xa65fb5 translate_all_program_units ../../gcc/fortran/parse.cc:7164 0xa65fb5 gfc_parse_file() ../../gcc/fortran/parse.cc:7494 0xac034f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:241
[Bug fortran/119986] New: Complex array part references are being passed incorrectly to a procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986 Bug ID: 119986 Summary: Complex array part references are being passed incorrectly to a procedure Product: gcc Version: 15.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: --- The follow example outputs incorrect results. program main type :: my_type complex, allocatable :: phi(:) end type integer :: j type(my_type) :: x x%phi = [(cmplx(j,-j),j=1,4)] call fubar(x%phi%re, x%phi%im) contains subroutine fubar(u, v) real, intent(in) :: u(:), v(:) print *, 'phi%re:', u print *, 'phi%im:', v end subroutine end program The correct results should be phi%re: 1.00 2.00 3.00 4.00 phi%im: -1.00 -2.00 -3.00 -4.00 But the gfortran-5.1.0 compiled code outputs phi%re: 1. -1. 2. -2. phi%im: 1. -1. 2. -2. The correct real and imaginary part references are not being passed to the subroutine. Note that if the complex array is not a component of a derived type, but simply a local or dummy array, then the correct part references are passed.
[Bug fortran/119986] Complex array part references are being passed incorrectly to a procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986 --- Comment #4 from Neil Carlson --- (In reply to kargls from comment #3) > Also note, that the above generates the expected temporary arrays. A tangential question: Why is this expected? I would have naively thought that a dope vector with a stride of 2 (assuming the real and imaginary parts are interleaved) could have been created and passed without copying the actual array elements. Or does "creating array temporary" not necessarily mean data copying is occurring?
[Bug fortran/119994] Valid specification expression in block rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994 --- Comment #1 from Neil Carlson --- Here's a similar example using an internal subroutine. The rejected specification expression is also valid, as again THIS is accessible by host association. module foo type :: bar integer :: n end type contains subroutine init(this, n) type(bar), intent(out) :: this integer, intent(in) :: n this%n = n call sub contains subroutine sub real :: array(this%n) end subroutine end subroutine end module
[Bug fortran/119994] New: Valid specification expression in block rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994 Bug ID: 119994 Summary: Valid specification expression in block rejected Product: gcc Version: 15.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: --- The following example is rejected with the following error: 19 | real :: array(this%n) |1 Error: Dummy argument 'this' at (1) cannot be INTENT(OUT) module foo type :: bar integer :: n end type contains subroutine init(this, n) type(bar), intent(out) :: this integer, intent(in) :: n this%n = n block real :: array(this%n) end block end subroutine end module This is incorrect. THIS%N is an object designator with a base object (THIS) that is made accessible by host association (2018: 10.1.11 par 2, item 4) and thus is a restricted expression and a valid specification expression. The Intel compiler also gets this wrong, but NAG gets it correct.
[Bug fortran/119994] Valid specification expression in block rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994 --- Comment #4 from Neil Carlson --- (In reply to kargls from comment #3) > Note, Neil has asked on the J3 mailing list for clarification as there > seems to be a conflict on the requirements of a restricted expression. I think the list given in 10.11.1 needs to be understood as an "or" of items so I don't think of (2) and (4) as conflicting. The basic issue in my mind now is how to understand "accessed by host association" in (4). In the case of the internal subroutine I think it's very clearly host association. But it's less clear to me that the standard views access to entities outside a block as "host association". I look forward to what the folks on J3 have to say, especially Malcolm.
