[Bug fortran/93337] [9/10 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[Bug fortran/93337] [9/10 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.3                         |9.4

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 9.3.0 has been released, adjusting target milestone.

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Seems to be fixed by:

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 2b760efe8d7..48f81d89a74 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -2277,6 +2277,9 @@ gfc_find_derived_vtab (gfc_symbol *derived)
   if (!derived)
     return NULL;

+  if (!derived->name)
+    return NULL;
+
   /* Find the gsymbol for the module of use associated derived types.  */
   if ((derived->attr.use_assoc || derived->attr.used_in_submodule)
        && !derived->attr.vtype && !derived->attr.is_class)

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |anlauf at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #4 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-June/054619.html

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:d9fb6f2b4f1321b059807ff6073156f07d9d376b

commit r11-1791-gd9fb6f2b4f1321b059807ff6073156f07d9d376b
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Thu Jul 2 20:41:51 2020 +0200

    PR fortran/93337 - ICE in gfc_dt_upper_string, at fortran/module.c:441

    When declaring a polymorphic variable that is not a dummy, allocatable or
    pointer, an ICE occurred due to a NULL pointer dereference.  Check for
    that situation and punt.

    gcc/fortran/
            PR fortran/93337
            * class.c (gfc_find_derived_vtab): Punt if name is not set.

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:0e66f1ddf7a7166f7a140c03e5d55286c7ef582b

commit r10-8429-g0e66f1ddf7a7166f7a140c03e5d55286c7ef582b
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Thu Jul 2 20:41:51 2020 +0200

    PR fortran/93337 - ICE in gfc_dt_upper_string, at fortran/module.c:441

    When declaring a polymorphic variable that is not a dummy, allocatable or
    pointer, an ICE occurred due to a NULL pointer dereference.  Check for
    that situation and punt.

    gcc/fortran/
            PR fortran/93337
            * class.c (gfc_find_derived_vtab): Punt if name is not set.

    (cherry picked from commit d9fb6f2b4f1321b059807ff6073156f07d9d376b)

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:ed54352ccfc3f0ec6c14e61035a78d06d5d44194

commit r9-8724-ged54352ccfc3f0ec6c14e61035a78d06d5d44194
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Thu Jul 2 20:41:51 2020 +0200

    PR fortran/93337 - ICE in gfc_dt_upper_string, at fortran/module.c:441

    When declaring a polymorphic variable that is not a dummy, allocatable or
    pointer, an ICE occurred due to a NULL pointer dereference.  Check for
    that situation and punt.

    gcc/fortran/
            PR fortran/93337
            * class.c (gfc_find_derived_vtab): Punt if name is not set.

    (cherry picked from commit d9fb6f2b4f1321b059807ff6073156f07d9d376b)

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11, and on 10- and 9-branch.

Thanks for the report!

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[dcb314 at hotmail dot com]

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

--- Comment #10 from David Binderman <dcb314 at hotmail dot com> ---
This valgrind problem has existed since sometime before 20201123.

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Interesting, I made a valgrind version of gcc fortran. 
> ...

My instrumented compiler gives

==67053==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000000eee
at pc 0x00010007eafc bp 0x7ffeefbfe430 sp 0x7ffeefbfe428
READ of size 1 at 0x604000000eee thread T0
    #0 0x10007eafb in gfc_find_derived_vtab(gfc_symbol*) class.c:2271
    #1 0x1000a1555 in gfc_find_vtab(gfc_typespec*) class.c:2910
    #2 0x100263a54 in gfc_match_assignment() match.c:1393
    #3 0x100367bd1 in match_word(char const*, match (*)(), locus*) parse.c:65
    #4 0x10037530c in decode_statement() parse.c:361
    #5 0x100377a2c in next_free() parse.c:1316
    #6 0x1003784e8 in next_statement() parse.c:1548
    #7 0x10037ecd7 in parse_spec(gfc_statement) parse.c:3967
    #8 0x100385b26 in parse_progunit(gfc_statement) parse.c:5896
    #9 0x1003882e6 in gfc_parse_file() parse.c:6437
    #10 0x100571b05 in gfc_be_parse_file() f95-lang.c:212
    #11 0x1075172c7 in compile_file() toplev.c:457
    #12 0x107525744 in do_compile() toplev.c:2193
    #13 0x10bafef19 in toplev::main(int, char**) toplev.c:2332
    #14 0x10c34222c in main main.c:39
    #15 0x7fff20348630 in start+0x0 (libdyld.dylib:x86_64+0x15630)

0x604000000eee is located 30 bytes inside of 48-byte region
[0x604000000ed0,0x604000000f00)
freed by thread T0 here:
    #0 0x15ea1fff7 in wrap_free.part.0 sanitizer_malloc_mac.inc:147
    #1 0x10051cdaa in gfc_delete_symtree(gfc_symtree**, char const*)
symbol.c:2964
    #2 0x100536e2b in gfc_restore_last_undo_checkpoint() symbol.c:3706
    #3 0x100537096 in gfc_undo_symbols() symbol.c:3739
    #4 0x100367afa in reject_statement() parse.c:2678
    #5 0x100367c40 in match_word(char const*, match (*)(), locus*) parse.c:70
    #6 0x10037530c in decode_statement() parse.c:361
    #7 0x100377a2c in next_free() parse.c:1316
    #8 0x1003784e8 in next_statement() parse.c:1548
    #9 0x10037d63b in parse_derived() parse.c:3387
    #10 0x10037f257 in parse_spec(gfc_statement) parse.c:3927
    #11 0x100385b26 in parse_progunit(gfc_statement) parse.c:5896
    #12 0x1003882e6 in gfc_parse_file() parse.c:6437
    #13 0x100571b05 in gfc_be_parse_file() f95-lang.c:212
    #14 0x1075172c7 in compile_file() toplev.c:457
    #15 0x107525744 in do_compile() toplev.c:2193
    #16 0x10bafef19 in toplev::main(int, char**) toplev.c:2332
    #17 0x10c34222c in main main.c:39
    #18 0x7fff20348630 in start+0x0 (libdyld.dylib:x86_64+0x15630)

previously allocated by thread T0 here:
    #0 0x15ea206ff in wrap_calloc sanitizer_malloc_mac.inc:158
    #1 0x10a86d2e5 in xcalloc xmalloc.c:162
    #2 0x10051ca55 in gfc_new_symtree(gfc_symtree**, char const*) symbol.c:2932
    #3 0x10052070e in gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) symbol.c:3384
    #4 0x10052ca29 in gfc_get_ha_sym_tree(char const*, gfc_symtree**)
symbol.c:3469
    #5 0x100259278 in gfc_match_sym_tree(gfc_symtree**, int) match.c:706
    #6 0x1003a71e8 in match_variable(gfc_expr**, int, int) primary.c:3955
    #7 0x1003b57b2 in gfc_match_variable(gfc_expr**, int) primary.c:4099
    #8 0x10025ba6f in gfc_match(char const*, ...) match.c:1162
    #9 0x10026328a in gfc_match_assignment() match.c:1340
    #10 0x100367bd1 in match_word(char const*, match (*)(), locus*) parse.c:65
    #11 0x10037530c in decode_statement() parse.c:361
    #12 0x100377a2c in next_free() parse.c:1316
    #13 0x1003784e8 in next_statement() parse.c:1548
    #14 0x10037d63b in parse_derived() parse.c:3387
    #15 0x10037f257 in parse_spec(gfc_statement) parse.c:3927
    #16 0x100385b26 in parse_progunit(gfc_statement) parse.c:5896
    #17 0x1003882e6 in gfc_parse_file() parse.c:6437
    #18 0x100571b05 in gfc_be_parse_file() f95-lang.c:212
    #19 0x1075172c7 in compile_file() toplev.c:457
    #20 0x107525744 in do_compile() toplev.c:2193
    #21 0x10bafef19 in toplev::main(int, char**) toplev.c:2332
    #22 0x10c34222c in main main.c:39
    #23 0x7fff20348630 in start+0x0 (libdyld.dylib:x86_64+0x15630)

SUMMARY: AddressSanitizer: heap-use-after-free class.c:2271 in
gfc_find_derived_vtab(gfc_symbol*)
Shadow bytes around the buggy address:
  0x1c0800000180: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x1c0800000190: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00 00
  0x1c08000001a0: fa fa 00 00 00 00 00 00 fa fa fd fd fd fd fd fd
  0x1c08000001b0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x1c08000001c0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fa
=>0x1c08000001d0: fa fa 00 00 00 00 00 00 fa fa fd fd fd[fd]fd fd
  0x1c08000001e0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x1c08000001f0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x1c0800000200: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x1c0800000210: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fa
  0x1c0800000220: fa fa 00 00 00 00 00 00 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
  Shadow gap:              cc
==67053==ABORTING

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[anlauf at gcc dot gnu.org]

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
The valgrind invalid read is possibly an issue with error recovery when
handling
the assignment.

Modifying the testcase:

program p
  type t
     character(:), allocatable :: a
  end type t
  class(t), allocatable :: y
  class(t) :: x ! { dg-error "must be dummy, allocatable or pointer" }
  y = x
end

one still gets the invalid read; swapping x and y in the assignment it
disappears.

Could you open a new PR to simplify tracking?

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[dcb314 at hotmail dot com]

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

--- Comment #13 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to anlauf from comment #12)
> Could you open a new PR to simplify tracking?

Sure. # 98263