[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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)

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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)

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

[neil.n.carlson at gmail dot com via Gcc-bugs]

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/94909] Rejects valid code for recursion where there is none

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94909

--- Comment #3 from Neil Carlson  ---
Richard, this is just a typical declaration of an abstract type. An extension
of this type will have to define the deferred dot_ function with an interface
that happens to match the interface of dot. The dot function will call that
dot_ function, not itself, so there is no evident recursion here in this unit
of code.

[Bug fortran/94909] New: Rejects valid code for recursion where there is none

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94909

Bug ID: 94909
   Summary: Rejects valid code for recursion where there is none
   Product: gcc
   Version: 9.3.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 compiler rejects the following valid code that contains no recursion.

module example
  type, abstract :: foo
  contains
procedure :: dot
procedure(dot), deferred :: dot_
  end type
contains
  function dot(a, b)
class(foo) :: a, b
dot = a%dot_(b)
  end function
end module

$ gfortran -c gfortran-20200501.f90 
gfortran-20200501.f90:13:10:

   13 | dot = a%dot_(b)
  |  1
Error: Function ‘dot’ at (1) cannot be called recursively, as it is not
RECURSIVE

[Bug fortran/94463] New: Bad object code / reference to undefined symbol

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94463

Bug ID: 94463
   Summary: Bad object code / reference to undefined symbol
   Product: gcc
   Version: 9.3.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 (two files) the compiler is generating a reference to
the undefined symbol __vtab_scalar_func_class_Scalar_func.3804. This is
probably meant to be a reference to the symbol
__scalar_func_class_MOD___vtab_scalar_func_class_Scalar_func
from file1.o

This error is present in all versions I've tried from 7.5, 8.3, to 9.3.

$ cat gfortran-20200402-file1.f90 
module scalar_func_class
  type, abstract :: scalar_func
  end type
end module

$ cat gfortran-20200402-file2.f90 
module material_model_type
contains
  subroutine alloc_phase_prop(func)
use scalar_func_class, only: scalar_func
class(scalar_func), allocatable, intent(out) :: func
  end subroutine
end module

module fubar
contains
  subroutine edit_short
use material_model_type, only: alloc_phase_prop
use scalar_func_class, only: scalar_func
class(scalar_func), allocatable :: f
call alloc_phase_prop(f)
  end subroutine
end module
end

$ gfortran gfortran-20200402-file?.f90
/usr/bin/ld: /tmp/ccAkiCLE.o: in function `__fubar_MOD_edit_short':
gfortran-20200402-file2.f90:(.text+0x1f): undefined reference to
`__vtab_scalar_func_class_Scalar_func.3804'
/usr/bin/ld: gfortran-20200402-file2.f90:(.text+0x8b): undefined reference to
`__vtab_scalar_func_class_Scalar_func.3804'
collect2: error: ld returned 1 exit status

[Bug fortran/89925] [9 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925

--- Comment #2 from Neil Carlson  ---
Right, when I said it failed on 8, I had misunderstood my colleague; he had
only tried 9.

[Bug fortran/89925] New: [8,9 Regression] Wrong array bounds from ALLOCATE with MOLD

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925

Bug ID: 89925
   Summary: [8,9 Regression] Wrong array bounds from ALLOCATE with
MOLD
   Product: gcc
   Version: 9.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: ---

My colleague passed this example on to me to report. This runs correctly with a
8.2.1 and 9 from Sept, but fails with the current 8 and 9 versions. I believe
it may be a result of the same bad commit(s) that caused PR89174 which I
reported. This example and the one from the other PR originate from the same
code.

module arraytest
  use, intrinsic :: iso_fortran_env
contains
  subroutine allocarray(moldarray)
real(real64), contiguous, intent(in) :: moldarray(0:,0:,0:)
real(real64), allocatable :: array(:,:,:)
integer :: lb1(3),lb2(3)

allocate(array,mold=moldarray)
lb1 = lbound(moldarray)
lb2 = lbound(array)
if (lb1(1).ne.lb2(1)) write(*,*) "ERROR"
  end subroutine
end module

program test
  use arraytest

  real(real64), allocatable, target :: array(:,:,:)
  allocate(array(5,5,5))
  call allocarray(array)
end program

[Bug fortran/89174] [8 Regression] Allocation segfault with CLASS(*) MOLD

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174

--- Comment #14 from Neil Carlson  ---
The comment for r268313 calls out a change to
gfc_find_and_cut_at_last_class_ref -- same function Thomas worked on for the
fix on the trunk.

[Bug fortran/89174] [8 Regression] Allocation segfault with CLASS(*) MOLD

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174

--- Comment #13 from Neil Carlson  ---
I've pinpointed were the regression was introduced on the 8 branch.
r268313 segfaults, but r268311 (the preceding change to 8) works fine.

[Bug fortran/87566] ICE with class(*) and select

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566

Neil Carlson  changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #12 from Neil Carlson  ---
The commit r265171 that fixed this issue also introduced a regression in 8.2
and 9, and certainly the 7 branch too if it was back-ported to it. See PR89174
for the example, which had worked correctly for 7, 8, and 9, but which now
segfaults on at least 8 and 9. I suppose it's too late revert that patch ...

[Bug fortran/89174] [8/9 Regression] Allocation segfault with CLASS(*) MOLD

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174

--- Comment #3 from Neil Carlson  ---
r265171 is the commit that broke the 9.0 trunk; r265171 segfaults but r265170
works correctly. I haven't been able to pinpoint where this stuff was
back-ported to the 8 branch, but it definitely was. This example used to work
for 7, 8, and 9.

[Bug fortran/89174] New: [8/9 Regression] Allocation segfault with CLASS(*) MOLD

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174

Bug ID: 89174
   Summary: [8/9 Regression] Allocation segfault with CLASS(*)
MOLD
   Product: gcc
   Version: 8.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: ---

Some relatively recent change (since ~Sept) has broken 8.2.1 and 9.0. Code that
contained the type of allocation given in the following example used to work
but now segfaults.

module mod
  type :: array_data
class(*), allocatable :: mold
  contains
procedure :: push
  end type
contains
  subroutine push(this, value)
class(array_data), intent(inout) :: this
class(*), intent(in) :: value
allocate(this%mold, mold=value) ! <== SEGFAULTS HERE
  end subroutine
end module

use mod
type(array_data) :: foo
call foo%push(42)
end

This example segfaults on the current 8.2.1 and 9.0, but works on 7.3.1. Here's
the output from valgrind:

$ valgrind ./a.out
==18450== Memcheck, a memory error detector
==18450== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==18450== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==18450== Command: ./a.out
==18450== 
==18450== Invalid read of size 2
==18450==at 0x4C31618: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1033)
==18450==by 0x400D9B: __mod_MOD_push (bug.f90:11)
==18450==by 0x400E17: MAIN__ (bug.f90:17)
==18450==by 0x400E4E: main (bug.f90:15)
==18450==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==18450== 

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x5a9f7cf in ???
#1  0x4c31618 in _vgr20181ZZ_libcZdsoZa_memcpyZAGLIBCZu2Zd2Zd5
at ../shared/vg_replace_strmem.c:1033
#2  0x400d9b in ???
#3  0x400e17 in ???
#4  0x400e4e in ???
#5  0x5a8bfe9 in ???
#6  0x400699 in ???
#7  0x in ???
==18450== 
==18450== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==18450==at 0x5A9F72E: raise (in /usr/lib64/libc-2.26.so)
==18450==by 0x5A9F7CF: ??? (in /usr/lib64/libc-2.26.so)
==18450==by 0x4C31617: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1033)
==18450==by 0x400D9B: __mod_MOD_push (bug.f90:11)
==18450==by 0x400E17: MAIN__ (bug.f90:17)
==18450==by 0x400E4E: main (bug.f90:15)

[Bug fortran/87625] [OOP] (re)allocate on assignment fails for polymorphic array

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87625

--- Comment #6 from Neil Carlson  ---
Yes, can this please be back-ported? Still broken on at least 8.

[Bug fortran/88169] Rejects USE rename of namelist group

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169

--- Comment #10 from Neil Carlson  ---
Also a remark about the output of comment 7 just in case someone is thinking it
ought to say "" (like I was expecting/hoping when I started experimenting
with the original example).  13.11.3.1 says

  1 Input for a namelist input statement consists of
(2) the character & followed immediately by the namelist-group-name as
specified in the NAMELIST statement,

and 13.11.4.1 says

  1 The form of the output produced by intrinsic namelist output shall be
suitable for input, [...]

So "" is correct (and what Intel and NAG both do as well).

[Bug fortran/88169] Rejects USE rename of namelist group

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169

--- Comment #9 from Neil Carlson  ---
Actually I think the usage in comment 8 is an intentional extension. There is a
test in the dg test suite that does exactly this if I remember correctly. The
test was namelist_use.f90. I was told that gfortran will give an error if
compiled with something like -std=f95. See
https://github.com/nncarlson/gfortran.dg/issues/3

[Bug fortran/88169] Rejects USE rename of namelist group

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169

--- Comment #5 from Neil Carlson  ---
Stated a bit more clearly, the question is, whether in

  The namelist-group-name shall not be a name accessed by use association.

the name (in the scope of the declaration) is accessed by use association,
or the name is accessed in another scope by use association.

[Bug fortran/88169] Rejects USE rename of namelist group

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169

--- Comment #4 from Neil Carlson  ---
I think the intent of

C8102 (R868) The namelist-group-name shall not be a name accessed by use
association.

is to say you can't define a namelist with a name accessed by use association.
That seems to fit best with the Note that references it.

However, I suppose it could be taken to mean that a namelist-group cannot be
accessed via use association. But that flies in the face of 14.2.2

  The USE statement provides the means by which a scoping unit accesses named
  data objects, derived types, procedures, abstract interfaces, generic
  identifiers, and namelist groups in a module.

which clearly indicates namelist groups can be accessed by use association.

[Bug fortran/88169] New: Rejects USE rename of namelist group

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169

Bug ID: 88169
   Summary: Rejects USE rename of namelist group
   Product: gcc
   Version: 8.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 current 8.2.1 compiler rejects this example,

  module foo_nml
real :: x
namelist /foo/ x
  end module

  program main
use foo_nml, only: bar => foo
x = 42
write(*,nml=bar)
  end program

with this error,

f951: Error: Namelist foo cannot be renamed by USE association to bar

I believe this is valid code. Section 11.2.2 par 2 (F2008) explicitly includes
namelist groups in the list of entities that may be accessed via use
association, and there is no subsequent restriction on a namelist group
appearing in a rename that I could find. FWIW, both the Intel and NAG compilers
accept this code as valid.

[Bug fortran/88043] Runtime Error when calling deferred member function

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88043

--- Comment #1 from Neil Carlson  ---
I've been poking at Zach's example and trimmed it down a bit:

In one file:

module typeA

  implicit none
  private

  type, abstract, public :: A
  contains
procedure :: call_sub
procedure(z), deferred :: sub
  end type

  abstract interface
subroutine z(this)
  import A
  class(A) :: this
end subroutine
  end interface

contains

  subroutine call_sub(this)
class(A) :: this
print *, 'CALL_SUB'
call this%sub
  end subroutine

end module

module typeB

  use typeA
  implicit none
  private

  type, extends(A), public :: B
  contains
procedure, non_overridable :: sub
procedure :: foo
  end type

contains

  subroutine sub(this)
class(B) :: this
print *, 'IN SUB'
  end subroutine

  subroutine foo(this)
class(B) :: this
print *, 'IN FOO!'
  end subroutine

end module

And in a separate file:

use typeB
type, extends(B) :: C
end type
type(C) :: x
call x%call_sub
end

The expected output is

  CALL SUB
  IN SUB

But instead we get

  CALL SUB
  IN FOO!

Remove the PRIVATE statement from typeA module and we get CALL_SUB calling
itself instead of SUB!

[Bug fortran/82996] ICE and segfault with derived type finalization

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996

--- Comment #10 from Neil Carlson  ---
A reader on c.l.f suggested this workaround for the bug. I'm sharing it here
because I think it may help to isolate where the problem is.  The suggestion
was to make the B array component allocatable and allocate it inside SUB. This
allows more control over when its finalizer is called. Here's a modified
version the runs without error (with -fsanitize=address,undefined) and valgrind
shows nothing amiss. (I'm using the 9.0 trunk)

module mod

  type foo
integer, pointer :: f(:) => null()
  contains
final :: foo_destroy
  end type

  type bar
type(foo), allocatable :: b(:)
  end type

contains

  elemental subroutine foo_destroy(this)
type(foo), intent(inout) :: this
if (associated(this%f)) deallocate(this%f)
  end subroutine

end module

program main

  use mod
  type(bar) :: x
  call sub(x) ! x%b not allocated
  call sub(x) ! x%b is allocated

contains

  subroutine sub(x)
type(bar), intent(out) :: x
allocate(x%b(2))
  end subroutine

end program

The interesting thing is that the finalizer works just fine when the %B
component is allocatable and allocated (the second call to SUB), but not when
it is not allocatable.

[Bug fortran/84539] ICE and segfault with assignment to CLASS(*) array

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84539

--- Comment #4 from Neil Carlson  ---
Update with 8.2.0

The ICE is gone, but a run time segfault remains:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f82986c06df in ???
#1  0x400754 in MAIN__
at gfortran-20180223a.f90:2
#2  0x400979 in main
at gfortran-20180223a.f90:7
Segmentation fault (core dumped)

[Bug fortran/86100] New: Spurious error with -fcheck=bounds and allocatable class(*) array components

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100

Bug ID: 86100
   Summary: Spurious error with -fcheck=bounds and allocatable
class(*) array components
   Product: gcc
   Version: 8.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: ---

When compiled with -fcheck=bounds, the following example gives a spurious
runtime bound mismatch error on the 'b=a' assignment statement:

type any_matrix
  class(*), allocatable :: m(:,:)
end type
type(any_matrix) :: a, b
allocate(a%m, source=reshape([3,5],shape=[1,2]))
b = a ! SPURIOUS RUNTIME ERROR with -fcheck=bounds
end

At line 6 of file gfortran-20180610.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array
'<>' (2/1)

Without the -fcheck=bounds option the assignment executes correctly (checked
via adding code to examine b%m).

There are no problems if the array component is rank-1, or if it is declared
integer instead of class(*). So this issue seems confined to allocatable
class(*) components of rank 2 (or greater?)

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213

Neil Carlson  changed:

   What|Removed |Added

Version|8.0.1   |8.1.1

--- Comment #27 from Neil Carlson  ---
Still present in 8.1.1 (nearly the 7th anniversary of the initial report!)

[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118

Neil Carlson  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|DUPLICATE   |---

--- Comment #6 from Neil Carlson  ---
It doesn't fix the test case of comment 4 (which I only gave as a mod to the
comment 0 example).  Here it is explicitly:

type :: any_vector
  class(*), allocatable :: v(:)
end type
type(any_vector) :: x, y
x%v = ['foo','bar']
select type (v => x%v)
type is (character(*))
  print '("orig=[""",a,''","'',a,''"]'')', v ! expect orig=["foo","bar"]
end select
y = x ! THIS ASSIGNMENT IS NOT BEING DONE CORRECTLY
select type (v => y%v)
type is (character(*))
  print '("copy=[""",a,''","'',a,''"]'')', v ! expect copy=["foo","bar"]
end select
end

$ gfortran --version
GNU Fortran (GCC) 8.1.1 20180521

$ gfortran gfortran-20171122b.f90 
$ ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f249667794f in ???
#1  0x0 in ???
Segmentation fault (core dumped)

[Bug fortran/84546] [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84546

--- Comment #6 from Neil Carlson  ---
Thank you, thank you Paul!

This also fixes my test case for PR83118 which I think must have been due to
the same underlying problem

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381

--- Comment #13 from Neil Carlson  ---
And one more missed file due to a line split between the "call" and "abort". 
Here's the patch:

diff --git a/overload_1.f90 b/overload_1.f90
index afd4f81..66fbea4 100644
--- a/overload_1.f90
+++ b/overload_1.f90
@@ -162,8 +162,7 @@ contains
 r2 = (/ a.eq.b, a.ne.b, a.lt.b, a.le.b, a.gt.b, a.ge.b /)
 if (any (r1.neqv.r2)) STOP 1
 if (any (r1.neqv. &
- (/ .false.,.true.,.true., .true., .false.,.false. /) )) call&
- & abort
+ (/ .false.,.true.,.true., .true., .false.,.false. /) )) STOP 3
   end subroutine checkt

   subroutine checku
@@ -177,7 +176,6 @@ contains
 r2 = (/ a.eq.b, a.ne.b, a.lt.b, a.le.b, a.gt.b, a.ge.b /)
 if (any (r1.neqv.r2)) STOP 2
 if (any (r1.neqv. &
- (/ .false.,.true.,.true., .true., .false.,.false. /) )) call&
- & abort
+ (/ .false.,.true.,.true., .true., .false.,.false. /) )) STOP 4
   end subroutine checku
 end program main

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381

--- Comment #12 from Neil Carlson  ---
Argh... here's the *correct* patch

diff --git a/literal_character_constant_1.inc
b/literal_character_constant_1.inc
index ba24966..40375cd 100644
--- a/literal_character_constant_1.inc
+++ b/literal_character_constant_1.inc
@@ -9,12 +9,12 @@ c A tab is between 8 and 9.
   write(fil,'(a)') c
 #ifdef LL_NONE
   if(fil.ne. "12345678 9")
- &  call abort
+ &  stop 1
 #else
   if(fil.ne.
  &"1234567  8  9"
  &)
- &  call abort
+ &  stop 2
 #endif
   end

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381

--- Comment #11 from Neil Carlson  ---
One more missed file, an include file included by
literal_character_constant_1_x.F.  Here's the patch:

diff --git a/literal_character_constant_1.inc
b/literal_character_constant_1.inc
index ba24966..8beea79 100644
--- a/literal_character_constant_1.inc
+++ b/literal_character_constant_1.inc
@@ -9,12 +9,12 @@ c A tab is between 8 and 9.
   write(fil,'(a)') c
 #ifdef LL_NONE
   if(fil.ne. "12345678 9")
- &  call abort
+ &  call stop 1
 #else
   if(fil.ne.
  &"1234567  8  9"
  &)
- &  call abort
+ &  call stop 2
 #endif
   end

[Bug fortran/84546] New: [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84546

Bug ID: 84546
   Summary: [7/8 Regression] Bad sourced allocation of CLASS(*)
with source with CLASS(*) component
   Product: gcc
   Version: 8.0.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 produces the expected result with 6.4.1, but not with the
latest 7 and 8 trunk.  The correct output is "foobar", but 7/8 produce "foob"

module any_vector_type

  type :: any_vector
class(*), allocatable :: vec(:)
  end type

  interface any_vector
procedure any_vector1
  end interface

contains

  function any_vector1(vec) result(this)
class(*), intent(in) :: vec(:)
type(any_vector) :: this
allocate(this%vec, source=vec)
  end function

end module

program main

  use any_vector_type
  implicit none

  class(*), allocatable :: x
  character(*), parameter :: vec(*) = ['foo','bar']

  allocate(x, source=any_vector(vec))

  select type (x)
  type is (any_vector)
select type (xvec => x%vec)
type is (character(*))
  print *, xvec ! EXPECT "foobar"
  if (any(xvec /= vec)) stop 1
end select
  end select

end program

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432

--- Comment #6 from Neil Carlson  ---
... and this would also be invalid

   type t(a)
  integer, len :: a = 3
  character(len=a) :: c = 'foo'
   end type

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432

--- Comment #5 from Neil Carlson  ---
No, both of those are valid. The constraint is on component initialization, and
type parameters are *not* components.  So something like this would be invalid
by F08:C458

   type t(a)
  integer, len :: a
  character(len=a) :: c = 'foo'
   end type

[Bug fortran/84543] New: undefined reference to __copy_INTEGER_4_.3788

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84543

Bug ID: 84543
   Summary: undefined reference to __copy_INTEGER_4_.3788
   Product: gcc
   Version: 8.0.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: ---

I stumbled across this problem while reducing an actual error to a minimal test
case (PR84539).  I wasn't going to bother reporting it (it seems a bit too
silly) but reconsidered. Maybe this means something significant to a developer;
I'll let you decide.

$ cat bug.f90
class(*), allocatable :: x
x = 42
end

$ gfortran bug.f90
/tmp/cclHGRhz.o:(.rodata+0x60): undefined reference to `__copy_INTEGER_4_.3788'
collect2: error: ld returned 1 exit status

And similar with a real or character value, and presumably with any of the
kinds that gfortran supports. The link error goes away if you add a TYPE IS
clause for the type of the value; e.g.

class(*), allocatable :: x
x = 42
select type (x)
type is (integer)
end select
end

[Bug fortran/83118] [7/8 Regression] Bad intrinsic assignment of class(*) array component of derived type

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118

--- Comment #4 from Neil Carlson  ---
Note that if the sourced allocation in the comment 0 test case

  allocate(x%v,source=['foo','bar'])

is replaced by the equivalent (I think) assignment

  x%v = ['foo','bar']

Then the code produces a run time segfault instead:

$ gfortran --version
GNU Fortran (GCC) 8.0.1 20180224 (experimental)

$ gfortran -g -fbacktrace bug.f90
$ ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f3c46fda94f in ???
#1  0x0 in ???
Segmentation fault (core dumped)

I think the problems here may be related to the simpler test cases in PR84539
which I just reported.

[Bug fortran/84539] ICE and segfault with assignment to CLASS(*) array

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84539

--- Comment #1 from Neil Carlson  ---
And same example but using character data. This compiles but gives a segfault
when run at the assignment statement.

class(*), allocatable :: x(:)
x = ['foo','bar']
select type (x)
type is (character(*))
  if (any(x /= ['foo','bar'])) stop 1
end select
end


$ gfortran -g gfortran-20180223b.f90 
$ ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f40a5b0894f in ???
#1  0x400853 in MAIN__
at gfortran-20180223b.f90:2
#2  0x4009fd in main
at gfortran-20180223b.f90:7
Segmentation fault (core dumped)

[Bug fortran/84539] New: ICE and segfault with assignment to CLASS(*) array

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84539

Bug ID: 84539
   Summary: ICE and segfault with assignment to CLASS(*) array
   Product: gcc
   Version: 8.0.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: ---

Here are some issues with array assignment to an allocatable CLASS(*) array
using the current 8.0 trunk.

class(*), allocatable :: x(:)
x = [4,2]
select type (x)
type is (integer)
  if (any(x /= [4,2])) stop 1
end select
end

$ gfortran -g -fbacktrace gfortran-20180223a.f90 
gfortran-20180223a.f90:1:0:

 class(*), allocatable :: x(:)

Error: conversion of register to a different size
VIEW_CONVERT_EXPR(_1);

_12 = VIEW_CONVERT_EXPR(_1);
gfortran-20180223a.f90:1:0: internal compiler error: verify_gimple failed
0xd2b9bd verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5247
0xaa7495 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12710
0xaa7684 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12800
0x925d17 cgraph_node::analyze()
../../gcc/cgraphunit.c:670
0x9286b3 analyze_functions
../../gcc/cgraphunit.c:1131
0x9294a2 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2691
Please submit a full bug report,

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213

Neil Carlson  changed:

   What|Removed |Added

Version|4.7.0   |8.0.1

--- Comment #26 from Neil Carlson  ---
Still present in 8.0

[Bug fortran/69563] Generic TBP incorrectly resolves to elemental

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69563

Neil Carlson  changed:

   What|Removed |Added

Version|6.0 |8.0.1

--- Comment #2 from Neil Carlson  ---
And still present in 8.0.

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072

--- Comment #22 from Neil Carlson  ---
I just verified with 8.0 trunk (r257868) that all three of my examples continue
to work as expected.

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432

Neil Carlson  changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #2 from Neil Carlson  ---
One of the corrigenda to F2003 (https://wg5-fortran.org/N1801-N1850/N1823.pdf)
added C447a:

"If component-initialization appears, every type parameter and array
bound of the component shall be an initialization expression."

Corresponds to F08:C458, except "initialization" replaces "colon or constant".
Not sure if there is anything significant between the two (probably is).

[Bug fortran/82996] ICE and segfault with derived type finalization

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996

--- Comment #9 from Neil Carlson  ---
With today's version (r257782) I'm still seeing the same thing Dominique
reported in comment 7, except that there is no longer any abort -- the programs
terminate successfully (0 exit code) despite the reported runtime error.  I'm
not sure what to make of that.

Example error:

 $ ./a.out
gfortran-20171114a.f90:48: runtime error: member access within misaligned
address 0x0060ab25 for type 'struct foo', which requires 8 byte alignment
0x0060ab25: note: pointer points here
 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00
00 00 00 00 00 00  00
 ^

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381

--- Comment #5 from Neil Carlson  ---
Thomas, I saw you generated a patch with "stop n".  I'd love to see how you did
it -- the regexp and counting magic.

[Bug testsuite/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381

Neil Carlson  changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #1 from Neil Carlson  ---
If the replacement could still be done mechanically (beyond my sed scripting
skills), it would be useful to replace occurrences of ABORT with a sequence of
stop statements; i.e., "stop 1", "stop 2", etc. Then a failure would point to a
specific location, and not one of several possible locations.

[Bug fortran/84218] ICE in free_expr0, at fortran/expr.c:451

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84218

Neil Carlson  changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #2 from Neil Carlson  ---
Note that the DATA statement

   data (x(j:i), i=1,2,2) /'a'/

is not valid Fortran.  Implied do objects, here x(j:i), are restricted by R538
(F08) to array elements, scalar structure component, or an implied-do.  x(j:i)
is an array section not an array element.  But this may be a language extension
that gfortran supports.

[Bug fortran/84122] Incorrect statement sequence in PDT definition

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84122

--- Comment #3 from Neil Carlson  ---
Here's a related invalid example that gfortran accepts:

module mod
type foo(dim)
  integer,len,public :: dim
  integer :: array(dim)
end type
end module

PUBLIC/PRIVATE attributes are not valid attributes for a type parameter
definition statement; see R431 and R433 (F08).

Gfortran does reject PRIVATE. but the error message
Error: PRIVATE attribute conflicts with LEN attribute at (1)
together with it allowing PUBLIC seems to betray that the PDT implementation
views type parameters as type components. The issue is not so much that PRIVATE
conflicts with LEN, as that type parameters do not have an accessibility
attribute.

[Bug fortran/84189] Internal procedure allowed as type bound procedure

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84189

Neil Carlson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Neil Carlson  ---
Sorry, this is completely bogus -- lack of sleep is my only excuse.

[Bug fortran/84189] New: Internal procedure allowed as type bound procedure

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84189

Bug ID: 84189
   Summary: Internal procedure allowed as type bound procedure
   Product: gcc
   Version: 8.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: ---

C465 (F08) prohibits an internal procedure from being a type bound procedure,
but gfortran mistakenly allows it when the TPB has the NOPASS attribute.

The following invalid example should fail to compile, but gfortran compiles it
without error.

module foobar
type :: foo
contains
  procedure, nopass :: bar
end type
contains
  subroutine bar
  end subroutine
end module

Note that the func_result_6.f90 testsuite problem, and perhaps others, use this
type of invalid code.

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143

--- Comment #2 from Neil Carlson  ---
(In reply to Dominique d'Humieres from comment #1)
> 
> gives 0. Should not it be 3?

Yeah. I noticed the same thing myself.  It is 3 if the type parameters are
removed.  I was intending to report it, but I thought I might have seen a
similar PR linked from the PDT meta bug and was going to look again before
doing so.

[Bug fortran/84143] New: Intrinsic output of PDT incorrectly includes type parameters

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143

Bug ID: 84143
   Summary: Intrinsic output of PDT incorrectly includes type
parameters
   Product: gcc
   Version: 8.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 continuing theme of the PDT implementation incorrectly regarding type
parameters as components (see PR84119, PR84120, PR84122), the current
implementation includes the type parameters when outputting a PDT:

type foo(k1,l1)
  integer,kind :: k1=1
  integer,len  :: l1=2
  integer :: n=3
end type

type(foo) :: x
character(8) :: string

write(string,'(*(i0))') x ! THIS SHOULD WRITE THE SINGLE DIGIT 3
if (len_trim(string) /= 1) stop 1
end

GFortran is bailing at the STOP 1 because it gets 3 for len_trim(string).
1.3.33 and R435 (F08) define what a component is. Type parameters R431 are
something else, and not included in the intrinsic output of the derived type.

I didn't check, but I'd guess the analogous incorrect thing occurs for input.

[Bug fortran/84120] Syntax for used for PDT constructors is incorrect

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84120

--- Comment #1 from Neil Carlson  ---
This explains the problem underlying PR82205

[Bug fortran/84122] New: Incorrect statement sequence in PDT definition

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84122

Bug ID: 84122
   Summary: Incorrect statement sequence in PDT definition
   Product: gcc
   Version: 8.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: ---

Here's yet another case of where the PDT implementation has not correctly
distinguished derived type parameters from the components of the type.
(c.f. PR84119 and PR84120)

R425 (F08) defines the sequence of statements in a derived type. First come
type parameter definitions, then optionally the PRIVATE statement, followed by
the definition of the type components.

So this is valid code

module mod
type foo(dim)
  integer,len :: dim
  private
  integer :: array(dim)
end type
end module

But gfortran rejects it with this error:

   private
 1
Error: PRIVATE statement at (1) must precede structure components

as it incorrectly considers the type parameters structure components.

[Bug fortran/84120] New: Syntax for used for PDT constructors is incorrect

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84120

Bug ID: 84120
   Summary: Syntax for used for PDT constructors is incorrect
   Product: gcc
   Version: 8.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 the PDT

type foo(dim)
  integer,len :: dim
  integer :: array(dim)
end type

While investigating how other compilers do on the gfortran testsuite programs,
I discovered that gfortran would use the following syntax for a constructor for
the PDT:

type(foo(2)) :: x
x = foo(2,[1,2])

This is absolutely wrong.  The correct constructor syntax is

x = foo(2)([1,2])

The PDT implementation appears to have the misconception that type parameters
are (in part) regular components, but that is not so, they are two separate
things. See PR84119 for some related references to the standard.  In particular
here, see R455 for the constructor syntax (F08 standard), and R453 for the
derived-type-spec (e.g. "foo(2)"). Note that 1.3.33 defines what a "component"
is, and it does not include type parameters.

To summarize, gfortran works with this invalid example (Intel and NAG properly
reject it)

type foo(dim)
  integer,len :: dim
  integer :: array(dim)
end type
type(foo(:)), allocatable :: x
x = foo(2,[1,2])
if (size(x%array) /= 2) stop 1
if (any(x%array /= [1,2])) stop 2
end

But gfortran rejects this corrected valid example (works with Intel and NAG):

type foo(dim)
  integer,len :: dim
  integer :: array(dim)
end type
type(foo(:)), allocatable :: x
x = foo(2)([1,2])
if (size(x%array) /= 2) stop 1
if (any(x%array /= [1,2])) stop 2
end

 x = foo(2)([1,2])
 1
Error: Invalid character in name at (1)

[Bug fortran/84119] New: Type parameter inquiry for PDT returns array instead of scalar

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84119

Bug ID: 84119
   Summary: Type parameter inquiry for PDT returns array instead
of scalar
   Product: gcc
   Version: 8.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: ---

There seems to be a misconception in the implementation of PDT that the type
parameters are (in part) just regular components of the type, so that for

type foo(a)
  integer, len :: a
end type
type(foo(a)) :: array(9)

the type inquiry array%a should give a rank-1 array of size 9. This is
incorrect. Type parameters are not components of the type. The F08 standard
clearly distinguishes between type parameter definition statements and
component definition statements. See R425, R431, R435, and in particular see
Note 6.7 which says "It [array%a, for example] is scalar even if designator is
an array."

Here's a test case that should pass.  GFortran will bail on both stop lines.

type :: vector(dim,kind)
  integer, len :: dim
  integer, kind :: kind
end type
type(vector(3,1)) :: a(10)
if (size(shape(a%dim)) /= 0) stop 1
if (size(shape(a%kind)) /= 0) stop 2
end

[Bug fortran/84093] Invalid nested derived type constructor not rejected

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84093

--- Comment #2 from Neil Carlson  ---
The forced cascade of keyword use is rather annoying, so perhaps someone was
thinking the current gfortran behavior is a useful extension, and it almost is.
But consider this example:

type :: parent
  type(parent), pointer :: next => null()
end type

type, extends(parent) :: child
  integer :: n
end type

type(child) :: c
type(parent), pointer :: p

allocate(p)
allocate(p%next)

c = child(parent=p,n=1)
if (.not.associated(c%next,p%next)) stop 1

c = child(p,1)
if (.not.associated(c%next,p)) stop 2

end

GFortran doesn't distinguish between the two constructor expressions, treating
the second the same as the first, when in fact they are quite different.

[Bug fortran/84093] New: Invalid nested derived type constructor not rejected

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84093

Bug ID: 84093
   Summary: Invalid nested derived type constructor not rejected
   Product: gcc
   Version: 8.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 allows invalid nested derived type constructors. Consider this
example:

type parent
  integer :: a, b
end type

type, extends(parent) :: child
  real :: x
end type

type(child) :: foo
foo = child(parent(1,2),3.0)

end

Note 4.59 and the preceding paragraphs (in F08 or F15 standard) are clear
that in this example parent(1,2) corresponds to the first component of
child, which is a, and gfortran should reject this illegal code.

The correct constructor must use keywords if one wants to use the parent
constructor:

foo = child(parent=parent(1,2), x=3.0)

Note that the extends_2.f03 testsuite program contains this error.

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149

--- Comment #7 from Neil Carlson  ---
Perhaps this modification of comment 2 code is clearer.

Put this in one file:

module mod1
  integer :: ncells
end module

module mod2
contains
  function get() result(array)
use mod1
real array(ncells)
array = 1.0
  end function
end module

And this in another (this is different):

subroutine sub
use mod2
s = sum(get())
end

This gives an ICE when compiled with 8.0.0 (20171222).

NCELLS is a valid specification expression.

A valid full program that calls SUB would have to define NCELLS before doing
so. However it is not required that the compiler know the value of NCELLS at
compile time.

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149

--- Comment #5 from Neil Carlson  ---
I disagree (in part) with comment 4.  Ncells is a valid specification statement
(see 7.1.11, par 2 (4), Fortran 2008).  Its value need not be known at compile
time; only when the get() function is executed.  If the code successfully
compiled then, yes, at run time it is not conforming because ncells was never
assigned a value.

Interestingly if the main program is modified to use mod1 (but still not define
ncells) then the ICE goes away.

use mod1
use mod2
s = sum(get())
end

So perhaps there is something here about mod1 going out of scope.  I forget how
that works, and seem to recall that some new standard was going to drop that
feature of the language.

However that aspect can be side stepped by just turning the main program into a
subprogram

subroutine sub
use mod2
s = sum(get())
end

This still gives an ICE and I believe is valid.  Both NAG and Intel compile
without error, fwtw.

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149

--- Comment #3 from Neil Carlson  ---
Unlike comment 0 code, comment 2 code also gives an ICE with 7.2.1 and 6.4.1

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149

--- Comment #2 from Neil Carlson  ---
Here's another example.  The ICE is coming at the same place, toplev.c:325, so
I think it may be the same underlying problem.  Like the original example, the
ICE occurs only when the main program is in a separate file.

module mod1
  integer :: ncells
end module

module mod2
contains
  function get() result(array)
use mod1
real array(ncells)
  end function
end module

With this in a separate file:

use mod2
s = sum(get())
end

Note that the ICE goes away if "use mod1" is moved up to the module scope.
Here's the traceback

$ gfortran gfortran-20171124f.f90 gfortran-20171124f-main.f90 
gfortran-20171124f-main.f90:2:0:

 s = sum(get())

internal compiler error: Segmentation fault
0xd6b98f crash_signal
../../gcc/toplev.c:325
0x90aeeb gfc_finish_var_decl
../../gcc/fortran/trans-decl.c:606
0x90a274 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1777
0x920387 gfc_conv_variable
../../gcc/fortran/trans-expr.c:2505
0x91c71a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7860
0x91ea0a gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*,
gfc_expr*)
../../gcc/fortran/trans-expr.c:4355
0x8ebd04 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*,
gfc_array_spec*)
../../gcc/fortran/trans-array.c:920
0x91a5b1 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:6024
0x91c6fa gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7852
0x8fa083 gfc_add_loop_ss_code
../../gcc/fortran/trans-array.c:2796
0x8faab5 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:5097
0x93ad87 gfc_conv_intrinsic_arith
../../gcc/fortran/trans-intrinsic.c:4197
0x93fd3f gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:9146
0x91c6fa gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7852
0x925065 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10018
0x8e45cf trans_code
../../gcc/fortran/trans.c:1828
0x90e7a8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6437
0x89d036 translate_all_program_units
../../gcc/fortran/parse.c:6091
0x89d036 gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x8e0eaf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/83149] New: ICE on SELECT CASE: crash_signal in toplev.c:325

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149

Bug ID: 83149
   Summary: ICE on SELECT CASE: crash_signal in toplev.c:325
   Product: gcc
   Version: 8.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 current 8.0 trunk gives an ICE on the following example, but only when then
the program units are in two separate files. Works fine with 7.2.1 and 6.4.1.

module mod
  character(8) string
contains
  function get_string() result(s)
character(len_trim(string)) s
s = string
  end function
end module

use mod
string = 'fubar'
select case (get_string())
case default
end select
end

Here's the traceback:

$ gfortran gfortran-20171124e.f90 gfortran-20171124e-main.f90 
gfortran-20171124e-main.f90:3:0:

 select case (get_string())

internal compiler error: Segmentation fault
0xd6b98f crash_signal
../../gcc/toplev.c:325
0x96852e gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2207
0x968ab7 gfc_get_function_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2969
0x907aed gfc_get_extern_function_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:2126
0x907ffd gfc_get_extern_function_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1974
0x91bb24 conv_function_val
../../gcc/fortran/trans-expr.c:3722
0x91bb24 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
../../gcc/fortran/trans-expr.c:6142
0x91c6fa gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7852
0x923a6a gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7952
0x957611 gfc_trans_character_select
../../gcc/fortran/trans-stmt.c:2819
0x95ee1c gfc_trans_select(gfc_code*)
../../gcc/fortran/trans-stmt.c:3158
0x8e48b7 trans_code
../../gcc/fortran/trans.c:1940
0x90e7a8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6437
0x89d036 translate_all_program_units
../../gcc/fortran/parse.c:6091
0x89d036 gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x8e0eaf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/79929] [7/8 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929

Neil Carlson  changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #22 from Neil Carlson  ---
I'm seeing these warning messages with essentially the same test case as
comment 0 using 8.0 (20171123) at -O1 and higher.

Same warning messages using 7.2.1 but only at -O2 and higher.

Even if these are bogus (I hope), they really need to be gotten rid of.

[Bug fortran/83148] New: [7.2 regression] ICE: crash_signal from toplev.c:325

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83148

Bug ID: 83148
   Summary: [7.2 regression] ICE: crash_signal from toplev.c:325
   Product: gcc
   Version: 8.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 gives an ICE with the current 8.0 trunk, but not with
7.2.1 or 6.4.1.

module fhypre
  use iso_c_binding, only: c_ptr, c_null_ptr
  use iso_c_binding, only: hypre_obj => c_ptr, hypre_null_obj => c_null_ptr
  private
  public :: hypre_obj, hypre_null_obj
end module

module hypre_hybrid_type
  use fhypre
  type hypre_hybrid
type(hypre_obj) :: solver = hypre_null_obj
  end type hypre_hybrid
end module

Here's the traceback

$ gfortran -c gfortran-20171124c.f90
f951: internal compiler error: Segmentation fault
0xd6b98f crash_signal
../../gcc/toplev.c:325
0xfb33fd tree_class_check(tree_node const*, tree_code_class, char const*, int,
char const*)
../../gcc/tree.h:3480
0xfb33fd wi::from_mpz(tree_node const*, __mpz_struct*, bool)
../../gcc/wide-int.cc:244
0x900284 gfc_conv_mpz_to_tree(__mpz_struct*, int)
../../gcc/fortran/trans-const.c:205
0x9008bf gfc_conv_constant(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-const.c:413
0x922b91 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:6833
0x9231ad gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7748
0x922cdf gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:6883
0x90a78b gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1819
0x90d340 gfc_create_module_variable
../../gcc/fortran/trans-decl.c:4943
0x8cf472 do_traverse_symtree
../../gcc/fortran/symbol.c:4157
0x910193 gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5415
0x8e88fc gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2180
0x89cf7b translate_all_program_units
../../gcc/fortran/parse.c:6078
0x89cf7b gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x8e0eaf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213

--- Comment #25 from Neil Carlson  ---
Here's another example similar to those above but even simpler IMHO and
involving a CLASS(*) pointer component

type box
  class(*), pointer :: uptr => null()
end type
integer, target :: n
call sub(box(n))
contains
  subroutine sub(b)
type(box), intent(in) :: b
  end subroutine
end

call sub(box(n))
 1
Error: Can't convert INTEGER(4) to CLASS(*) at (1)

This should work in F2003. GFortran seems to be fundamentally broken when it
comes to derived types with polymorphic pointer components and intrinsic
structure constructors.

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213

--- Comment #24 from Neil Carlson  ---
Ping.  This bug has been around for over 6 years now.

[Bug fortran/83146] ICE on SELECT CASE statement with associate name

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146

--- Comment #2 from Neil Carlson  ---
Turns out you don't need anything at all in the associate block to get an ICE:

type foo
  integer n
end type
type bar
  type(foo) array(2)
end type
type(bar) b
associate (n_array => b%array%n)
end associate
end

[Bug fortran/83146] ICE on SELECT CASE statement with associate name

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146

--- Comment #1 from Neil Carlson  ---
I thought that assigning the select case expression to a temporary integer and
using that variable in the select case statement would be a workaround, but no.
You can put anything unrelated to the associate name in the select case and you
still get an ICE.  It seems the the associate block itself is the problem. 
Here's the tweaked example

type foo
  integer n
end type
type bar
  type(foo) array(2)
end type
type(bar) b
integer :: m=0
associate (n_array => b%array%n)
  select case (m)
  case default
  end select
end associate
end

[Bug fortran/83146] New: ICE on SELECT CASE statement with associate name

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146

Bug ID: 83146
   Summary: ICE on SELECT CASE statement with associate name
   Product: gcc
   Version: 8.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 current 8.0 trunk gives an ICE on the following example.  6.4.1 also gives
an ICE.

type foo
  integer n
end type
type bar
  type(foo) array(2)
end type
type(bar) b
associate (n_array => b%array%n)
  select case (n_array(1))
  case default
  end select
end associate
end

Here's the traceback

$ gfortran -c gfortran-20171124.f90 
gfortran-20171124.f90:9:0:

   select case (n_array(1))

internal compiler error: in gfc_get_element_type, at fortran/trans-types.c:1231
0x5a5da8 gfc_get_element_type(tree_node*)
../../gcc/fortran/trans-types.c:1231
0x95d247 trans_associate_var
../../gcc/fortran/trans-stmt.c:1632
0x95d247 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:1890
0x8e48c7 trans_code
../../gcc/fortran/trans.c:1924
0x90e7a8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6437
0x89d036 translate_all_program_units
../../gcc/fortran/parse.c:6091
0x89d036 gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x8e0eaf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/83118] Bad intrinsic assignment of class(*) array component of derived type (8.0 regression)

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118

--- Comment #1 from Neil Carlson  ---
Note that the incorrect string "b" is not actually 1 character long, but 3
characters: a "b" followed by 2 non-printing characters.  Vim shows them as ^@

[Bug fortran/83118] New: Bad intrinsic assignment of class(*) array component of derived type (8.0 regression)

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118

Bug ID: 83118
   Summary: Bad intrinsic assignment of class(*) array component
of derived type (8.0 regression)
   Product: gcc
   Version: 8.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: ---

Intrinsic assignment of a derived type with allocatable CLASS(*) array
component is not being done correctly with version 8.0 when the dynamic type is
CHARACTER.

Version 6.4.1 gives the expected result:

orig=["foo","bar"]
copy=["foo","bar"]


But 8.0 (20171122) gives an incorrect result:

orig=["foo","bar"]
copy=["foo","b"]

Here's the code:

type :: any_vector
  class(*), allocatable :: v(:)
end type
type(any_vector) :: x, y
allocate(x%v,source=['foo','bar'])
select type (v => x%v)
type is (character(*))
  print '("orig=[""",a,''","'',a,''"]'')', v ! expect orig=["foo","bar"]
end select
y = x ! THIS ASSIGNMENT IS NOT BEING DONE CORRECTLY
select type (v => y%v)
type is (character(*))
  print '("copy=[""",a,''","'',a,''"]'')', v ! expect copy=["foo","bar"]
end select
end

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072

--- Comment #19 from Neil Carlson  ---
This fixes the code of comment 12 for me.  All the other test cases continue to
work as expected.  This can be closed as "fixed" as far as I'm concerned.
Thanks Paul!

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072

--- Comment #16 from neil.n.carlson at gmail dot com ---
I've confirmed Dominique's findings: Code in comments 0, 5, 11 are working now
with Paul's commit (Thanks!), but comment 12 code still gives an ICE.

Should I create a new PR for that example, or is it fine leaving this PR open?

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072

--- Comment #13 from neil.n.carlson at gmail dot com ---
Correction to Comment 11.  That example gives the *correct* result on 6.4.1

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072

--- Comment #12 from neil.n.carlson at gmail dot com ---
The second adds a select case and print to get at the result value before its
handed back.  This produces an ICE with 6.4.1, 7.2.1, and 8.0.0 (20171028)

character(3), target :: a = 'foo'
class(*), pointer :: b
b => ptr()
select type (b)
type is (character(*))
  print '(3a)', 'b="', b, '" (expect "foo")'
end select
contains
  function ptr()
class(*), pointer :: ptr
ptr => a
select type (ptr)
type is (character(*))
end select
  end function
end

Here's the traceback on 7.2.1:

gfortran-bug-20170812b.f90:46:0:

 character(3), target :: a = 'foo'

internal compiler error: in gfc_advance_chain, at fortran/trans.c:58
0x65d137 gfc_advance_chain(tree_node*, int)
../../gcc/fortran/trans.c:58
0x685eba gfc_class_len_get(tree_node*)
../../gcc/fortran/trans-expr.c:226
0x6c6364 trans_associate_var
../../gcc/fortran/trans-stmt.c:1778
0x6c6364 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:1831
0x65d6b7 trans_code
../../gcc/fortran/trans.c:1913
0x6c77d9 gfc_trans_select_type_cases
../../gcc/fortran/trans-stmt.c:2422
0x6c77d9 gfc_trans_select_type(gfc_code*)
../../gcc/fortran/trans-stmt.c:3133
0x65d747 trans_code
../../gcc/fortran/trans.c:1933
0x6c5e38 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:1824
0x65d6b7 trans_code
../../gcc/fortran/trans.c:1913
0x682847 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6332
0x682634 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5327
0x682634 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6261
0x616eb6 translate_all_program_units
../../gcc/fortran/parse.c:6074
0x616eb6 gfc_parse_file()
../../gcc/fortran/parse.c:6274
0x65a02f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072

--- Comment #11 from neil.n.carlson at gmail dot com ---
Paul, I'm organizing all my bug report examples, and ran across these two test
cases from September that I can't find I ever reported.  They are VERY similar
to the original example I posted, except the ICE occurs in a different file, so
I thought I'd add them here.  I can submit a separate PR if you think it more
appropriate.

The first compiles on 6.4.1, 7.2.1, and 8.0.0 (20171028). But produces an
incorrect result:

b="" (expect "foo")

character(3), target :: a = 'foo'
class(*), pointer :: b
b => ptr()
select type (b)
type is (character(*))
  print '(3a)', 'b="', b, '" (expect "foo")'
end select
contains
  function ptr()
class(*), pointer :: ptr
ptr => a
  end function
end

[Bug fortran/82996] ICE and segfault with derived type finalization

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996

--- Comment #8 from neil.n.carlson at gmail dot com ---
> If I remove 'elemental' for 'subroutine foo_destroy', the segfault is gone.

In that case the final procedure doesn't match the array component and wouldn't
be called.  I suspect that is why the segfault is gone.

[Bug fortran/83012] New: Simply contiguous pointer function not recognized as contiguous

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83012

Bug ID: 83012
   Summary: Simply contiguous pointer function not recognized as
contiguous
   Product: gcc
   Version: 8.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 pointer assignment "p => x%dataptr()" is rejected
because the compiler does not recognize the function result x%dataptr() as
contiguous when in fact it is simply contiguous by definition.  Note that there
is no error if the dummy variable x is declared as type(x) instead of class(x).

FWIW, the 6.4.1 compiler has no problems with this example.

module mod
  type :: foo
integer, pointer, contiguous :: p(:)
  contains
procedure :: dataptr
  end type
contains
  function dataptr(this) result(dp)
class(foo), intent(in) :: this
integer, pointer, contiguous :: dp(:)
dp => this%p
  end function
end module

subroutine bar(x)
  use mod
  class(foo) :: x
  integer, pointer, contiguous :: p(:)
  p => x%dataptr()
end subroutine

The error message:

$ gfortran --version
GNU Fortran (GCC) 8.0.0 20171115 (experimental)

$ gfortran -c bug.f90 
bug.f90:19:7:

   p => x%dataptr()
   1
Error: Assignment to contiguous pointer from non-contiguous target at (1)

[Bug fortran/82996] ICE and segfault with derived type finalization

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996

--- Comment #5 from neil.n.carlson at gmail dot com ---
I've built the svn trunk and tested the examples with it.  The ICEs with the
comment 2 and 3 examples are gone, as Dominique found.  The comment 1 example
continues to segfault when executed, as does the comment 2 example now.  The
comment 3 example executes without error.  I think Dominique swapped 2 and 3.