[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from anlauf at gcc dot gnu.org --- The issue found with valgrind should be fixed, see PR78746. Closing. Thanks for the report!
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 anlauf at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78746 CC||anlauf at gcc dot gnu.org --- Comment #8 from anlauf at gcc dot gnu.org --- See also PR78746, comment#17. A patch was submitted there to solve this issue.
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #7 from Christophe Lyon --- I see it again rather frequently since a couple of days ago. (cross x86_64 -> arm)
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 --- Comment #6 from Dominique d'Humieres --- Not seen in https://gcc.gnu.org/pipermail/gcc-testresults/2020-June/564061.html
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 --- Comment #5 from Manfred Schwarb --- This might have been solved by https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=ac932bfcd21e9523fa2b880ae8138aef79da7f54 , at least I don't see it anymore in today's build. As the crash of class_61.f90 is a bit difficult to reproduce, additional confirmation might be needed.
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment #4 from Manfred Schwarb ---
I see it too on i686 for current trunk: Instrumenting the testsuite checks with
/usr/bin/env LIBC_FATAL_STDERR_=1 MALLOC_PERTURB_=B MALLOC_CHECK_=3 make check
9 | class(t2), pointer :: q(2) ! { dg-error "must have a deferred
shape" }
| 1
Error: Pointer array component of structure at (1) must have a deferred shape
f951: internal compiler error: Segmentation fault
0x8e61e8d crash_signal
../../gcc-trunk-source/gcc/gcc/toplev.c:328
0x860f511 resolve_component
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:14318
0x86107fb resolve_fl_derived0
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:14753
0x8610d29 resolve_fl_derived
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:14882
0x8611ad0 resolve_symbol
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:15251
0x8636a81 do_traverse_symtree
../../gcc-trunk-source/gcc/gcc/fortran/symbol.c:4150
0x8636b18 gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
../../gcc-trunk-source/gcc/gcc/fortran/symbol.c:4175
0x8615988 resolve_types
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:17175
0x8615dd8 gfc_resolve(gfc_namespace*)
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:17290
0x85eb469 resolve_all_program_units
../../gcc-trunk-source/gcc/gcc/fortran/parse.c:6245
0x85ebb66 gfc_parse_file()
../../gcc-trunk-source/gcc/gcc/fortran/parse.c:6492
0x864043d gfc_be_parse_file
../../gcc-trunk-source/gcc/gcc/fortran/f95-lang.c:210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #3 from Christophe Lyon --- I've recently started to see this randomly with my cross-compilers for arm (host x86)
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #2 from Arseny Solokha --- It's likely a duplicate of PR78746.
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-03-11
Ever confirmed|0 |1
--- Comment #1 from Dominique d'Humieres ---
On x86_64-apple-darwin18 and an instrumented GCC9 (r269205) I get
% gfcg /opt/gcc/_clean/gcc/testsuite/gfortran.dg/class_61.f90 -O
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/class_61.f90:9:30:
9 | class(t2), pointer :: q(2) ! { dg-error "must have a deferred
shape" }
| 1
Error: Pointer array component of structure at (1) must have a deferred shape
=
==32481==ERROR: AddressSanitizer: heap-use-after-free on address 0x61303900
at pc 0x0001003efd9b bp 0x7ffeefbfe2b0 sp 0x7ffeefbfe2a8
READ of size 8 at 0x61303900 thread T0
#0 0x1003efd9a in resolve_component(gfc_component*, gfc_symbol*)
resolve.c:13828
#1 0x1003f5eec in resolve_fl_derived0(gfc_symbol*) resolve.c:14282
#2 0x1003f72d8 in resolve_fl_derived(gfc_symbol*) resolve.c:14411
#3 0x1003e45c3 in resolve_symbol(gfc_symbol*) resolve.c:14785
#4 0x1004d43fb in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*),
void (*)(gfc_symbol*)) symbol.c:4156
#5 0x1004f22e0 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
symbol.c:4181
#6 0x10044e99d in resolve_types(gfc_namespace*) resolve.c:16697
#7 0x1003dfbe0 in gfc_resolve(gfc_namespace*) resolve.c:16811
#8 0x1003422f8 in resolve_all_program_units(gfc_namespace*) parse.c:6073
#9 0x1003629f3 in gfc_parse_file() parse.c:6321
#10 0x10053d40b in gfc_be_parse_file() f95-lang.c:204
#11 0x1063b24e8 in compile_file() toplev.c:456
#12 0x1063be87e in do_compile() toplev.c:2204
#13 0x109550717 in toplev::main(int, char**) toplev.c:2339
#14 0x1099c9345 in main main.c:39
#15 0x7fff7512bed8 in start (libdyld.dylib:x86_64+0x16ed8)
0x61303900 is located 192 bytes inside of 344-byte region
[0x61303840,0x61303998)
freed by thread T0 here:
#0 0x1599d18ff in wrap_free.part.0 sanitizer_malloc_mac.inc:121
#1 0x1004f1a17 in gfc_free_symbol(gfc_symbol*) symbol.c:3086
#2 0x1004f1d63 in gfc_release_symbol(gfc_symbol*) symbol.c:3113
#3 0x100501a1d in gfc_restore_last_undo_checkpoint() symbol.c:3706
#4 0x100502946 in gfc_undo_symbols() symbol.c:3737
#5 0x1003438c8 in reject_statement() parse.c:2576
#6 0x100343a0e in match_word(char const*, match (*)(), locus*) parse.c:70
#7 0x100350471 in decode_statement() parse.c:376
#8 0x100352bac in next_free() parse.c:1241
#9 0x10035357a in next_statement() parse.c:1473
#10 0x100358682 in parse_derived() parse.c:3285
#11 0x10035a077 in parse_spec(gfc_statement) parse.c:3825
#12 0x100360637 in parse_progunit(gfc_statement) parse.c:5680
#13 0x1003629b5 in gfc_parse_file() parse.c:6220
#14 0x10053d40b in gfc_be_parse_file() f95-lang.c:204
#15 0x1063b24e8 in compile_file() toplev.c:456
#16 0x1063be87e in do_compile() toplev.c:2204
#17 0x109550717 in toplev::main(int, char**) toplev.c:2339
#18 0x1099c9345 in main main.c:39
#19 0x7fff7512bed8 in start (libdyld.dylib:x86_64+0x16ed8)
previously allocated by thread T0 here:
#0 0x1599d0de2 in wrap_calloc sanitizer_malloc_mac.inc:132
#1 0x108a1d5c7 in xcalloc xmalloc.c:162
#2 0x1004e916b in gfc_new_symbol(char const*, gfc_namespace*) symbol.c:3122
#3 0x1004eb6de in gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) symbol.c:3374
#4 0x1004eccfd in gfc_get_symbol(char const*, gfc_namespace*, gfc_symbol**)
symbol.c:3424
#5 0x1000eb431 in gfc_match_decl_type_spec(gfc_typespec*, int) decl.c:4337
#6 0x1000fac2f in gfc_match_data_decl() decl.c:5949
#7 0x10034399f in match_word(char const*, match (*)(), locus*) parse.c:65
#8 0x100350471 in decode_statement() parse.c:376
#9 0x100352bac in next_free() parse.c:1241
#10 0x10035357a in next_statement() parse.c:1473
#11 0x100358682 in parse_derived() parse.c:3285
#12 0x10035a077 in parse_spec(gfc_statement) parse.c:3825
#13 0x100360637 in parse_progunit(gfc_statement) parse.c:5680
#14 0x1003629b5 in gfc_parse_file() parse.c:6220
#15 0x10053d40b in gfc_be_parse_file() f95-lang.c:204
#16 0x1063b24e8 in compile_file() toplev.c:456
#17 0x1063be87e in do_compile() toplev.c:2204
#18 0x109550717 in toplev::main(int, char**) toplev.c:2339
#19 0x1099c9345 in main main.c:39
#20 0x7fff7512bed8 in start (libdyld.dylib:x86_64+0x16ed8)
SUMMARY: AddressSanitizer: heap-use-after-free resolve.c:13828 in
resolve_component(gfc_component*, gfc_symbol*)
Shadow bytes around the buggy address:
0x1c2606d0: fd fd fd fd fd fd fd fd fd fd fd fd fd
