* [Bug fortran/93337] [9/10 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441
[not found] <bug-93337-4@http.gcc.gnu.org/bugzilla/>
@ 2020-03-12 11:58 ` jakub at gcc dot gnu.org
2020-06-25 19:58 ` [Bug fortran/93337] [9/10/11 " anlauf at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-12 11:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441
[not found] <bug-93337-4@http.gcc.gnu.org/bugzilla/>
2020-03-12 11:58 ` [Bug fortran/93337] [9/10 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441 jakub at gcc dot gnu.org
@ 2020-06-25 19:58 ` anlauf at gcc dot gnu.org
2020-06-25 20:20 ` anlauf at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: anlauf at gcc dot gnu.org @ 2020-06-25 19:58 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441
[not found] <bug-93337-4@http.gcc.gnu.org/bugzilla/>
2020-03-12 11:58 ` [Bug fortran/93337] [9/10 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441 jakub at gcc dot gnu.org
2020-06-25 19:58 ` [Bug fortran/93337] [9/10/11 " anlauf at gcc dot gnu.org
@ 2020-06-25 20:20 ` anlauf at gcc dot gnu.org
2020-07-02 18:42 ` cvs-commit at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: anlauf at gcc dot gnu.org @ 2020-06-25 20:20 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441
[not found] <bug-93337-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-06-25 20:20 ` anlauf at gcc dot gnu.org
@ 2020-07-02 18:42 ` cvs-commit at gcc dot gnu.org
2020-07-06 21:14 ` cvs-commit at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-07-02 18:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441
[not found] <bug-93337-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-07-02 18:42 ` cvs-commit at gcc dot gnu.org
@ 2020-07-06 21:14 ` cvs-commit at gcc dot gnu.org
2020-07-07 19:42 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-07-06 21:14 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441
[not found] <bug-93337-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2020-07-06 21:14 ` cvs-commit at gcc dot gnu.org
@ 2020-07-07 19:42 ` cvs-commit at gcc dot gnu.org
2020-07-07 19:43 ` anlauf at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-07-07 19:42 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441
[not found] <bug-93337-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2020-07-07 19:42 ` cvs-commit at gcc dot gnu.org
@ 2020-07-07 19:43 ` anlauf at gcc dot gnu.org
2020-12-13 11:01 ` dcb314 at hotmail dot com
` (3 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: anlauf at gcc dot gnu.org @ 2020-07-07 19:43 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441
[not found] <bug-93337-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2020-07-07 19:43 ` anlauf at gcc dot gnu.org
@ 2020-12-13 11:01 ` dcb314 at hotmail dot com
2020-12-13 11:40 ` dominiq at lps dot ens.fr
` (2 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: dcb314 at hotmail dot com @ 2020-12-13 11:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441
[not found] <bug-93337-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2020-12-13 11:01 ` dcb314 at hotmail dot com
@ 2020-12-13 11:40 ` dominiq at lps dot ens.fr
2020-12-13 20:49 ` anlauf at gcc dot gnu.org
2020-12-13 21:18 ` dcb314 at hotmail dot com
10 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2020-12-13 11:40 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441
[not found] <bug-93337-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2020-12-13 11:40 ` dominiq at lps dot ens.fr
@ 2020-12-13 20:49 ` anlauf at gcc dot gnu.org
2020-12-13 21:18 ` dcb314 at hotmail dot com
10 siblings, 0 replies; 11+ messages in thread
From: anlauf at gcc dot gnu.org @ 2020-12-13 20:49 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441
[not found] <bug-93337-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2020-12-13 20:49 ` anlauf at gcc dot gnu.org
@ 2020-12-13 21:18 ` dcb314 at hotmail dot com
10 siblings, 0 replies; 11+ messages in thread
From: dcb314 at hotmail dot com @ 2020-12-13 21:18 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread