Compare: --------------- type t character(len=:, kind=4), pointer :: str2 end type t type(t) :: var character(len=:, kind=4), pointer :: str str(1:1) = 4_"a" str(1:2) = 4_"bc" var%str2(1:1) = 4_"d" var%str2(1:2) = 4_"ef" end --------------- The dump shows that 'str' is properly handled: (*str)[1]{lb: 1 sz: 4} = "a\x00\x00"[1]{lb: 1 sz: 4}; __builtin_memmove ((void *) str, (void *) &"b\x00\x00\x00c\x00\x00"[1]{lb: 1 sz: 4}, 8); But the component reference ignores the kind=4: *(character(kind=1) *) var.str2 = 100; __builtin_memmove ((void *) var.str2, (void *) &"ef"[1]{lb: 1 sz: 1}, 2);
The problem seems more serious. type t character(len=:, kind=4), pointer :: str2 end type t type(t) :: var character(len=:, kind=4), pointer :: str print *, kind(str), kind(var%str2) str(1:1) = 4_"a" end result % ./a.out 4 4 Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
(In reply to Dominique d'Humieres from comment #1) > The problem seems more serious. > > type t > character(len=:, kind=4), pointer :: str2 > end type t > type(t) :: var > character(len=:, kind=4), pointer :: str > > print *, kind(str), kind(var%str2) > str(1:1) = 4_"a" > end > > result > > % ./a.out > 4 4 Yes, there is a serious problem with the Fortran code! str is an undefined pointer. The line 'str(1:1) = 4_"a"' is invalid.
(In reply to kargl from comment #2) > (In reply to Dominique d'Humieres from comment #1) > > The problem seems more serious. > > > > type t > > character(len=:, kind=4), pointer :: str2 > > end type t > > type(t) :: var > > character(len=:, kind=4), pointer :: str > > > > print *, kind(str), kind(var%str2) > > str(1:1) = 4_"a" > > end > > > > result > > > > % ./a.out > > 4 4 > > Yes, there is a serious problem with the Fortran code! > > str is an undefined pointer. The line 'str(1:1) = 4_"a"' > is invalid. In fact, after a quick scan of the Fortran 2018 standard. The PR is likely invalid. Allocation on assignment applies to ALLOCATABLE variables not undefined or disassociated pointers. Yep. Definitely invalid. Fortran 2018, 10.2.1.2 Intrinsic assignment statement p. 160 If the variable is a pointer, it shall be associated with a definable target such that the type, type parameters, and shape of the target and expr conform.
Remove "wrong-code" keyword.
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548779.html
The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>: https://gcc.gnu.org/g:f48bffe70cba310461ec19ffcd07c573a6b86575 commit r11-1654-gf48bffe70cba310461ec19ffcd07c573a6b86575 Author: Tobias Burnus <tobias@codesourcery.com> Date: Thu Jun 25 16:57:08 2020 +0200 Fortran: Fix character-kind=4 substring resolution (PR95837) Testing showed that it is always set and its value matches always ts->kind (if available) or otherwise, if it is a variable, the sym->ts.kind. gcc/fortran/ChangeLog: PR fortran/95837 * resolve.c (gfc_resolve_substring_charlen): Remove bogus ts.kind setting for the expression. gcc/testsuite/ChangeLog: PR fortran/95837 * gfortran.dg/char4-subscript.f90: New test.
FIXED on mainline = GCC 11.
The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>: https://gcc.gnu.org/g:e0685fadb6aa7c9cc895bc14cbbe2b9026fa3a94 commit r11-2105-ge0685fadb6aa7c9cc895bc14cbbe2b9026fa3a94 Author: Tobias Burnus <tobias@codesourcery.com> Date: Wed Jul 15 12:29:44 2020 +0200 libgomp.fortran/struct-elem-map-1.f90: Add char kind=4 tests As the Fortran PR 95837 has been fixed, the test could be be added. libgomp/ChangeLog: * testsuite/libgomp.fortran/struct-elem-map-1.f90: Remove unused variables; add character(kind=4) tests; update TODO comment.