[Bug fortran/78746] charlen_03, charlen_10 ICE

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #31 from anlauf at gcc dot gnu.org ---
The valgrind issues with error-recovery with charlen_03 has been moved to
PR98661, and there is no longer an ICE as reported here.

To avoid further cluttering of the present PR, please add further comments
there.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #30 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #29)
> > There's no testcase named "pr78746.f90" in the testsuite.
> 
> Ideed! My prx.f90 are in the test suite only when they are fixed.
> 
> Now my "pr78746.f90" is exactly charlen_03.f90.

... which was removed by Steve.

We're running in circles, so please open a new pr.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[dominiq at lps dot ens.fr via Gcc-bugs]

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

--- Comment #29 from Dominique d'Humieres  ---
> There's no testcase named "pr78746.f90" in the testsuite.

Ideed! My prx.f90 are in the test suite only when they are fixed.

Now my "pr78746.f90" is exactly charlen_03.f90.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|WAITING

--- Comment #28 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #27)
> At revision r11-6550 my instrumented compiler gives:
> 
> pr78746.f90:5:40:
> 
> 5 |   character(:), allocatable :: x(n) ! { dg-error "must have a
> deferred shape" }
>   |1
> Error: Allocatable component of structure at (1) must have a deferred shape
> =
> ==33829==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x60400ee8 at pc 0x000100423feb bp 0x7ffeefbfe3b0 sp 0x7ffeefbfe3a8
> READ of size 8 at 0x60400ee8 thread T0
> ...

There's no testcase named "pr78746.f90" in the testsuite.

Would you please open a new PR with enough information?

[Bug fortran/78746] charlen_03, charlen_10 ICE

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #27 from Dominique d'Humieres  ---
At revision r11-6550 my instrumented compiler gives:

pr78746.f90:5:40:

5 |   character(:), allocatable :: x(n) ! { dg-error "must have a
deferred shape" }
  |1
Error: Allocatable component of structure at (1) must have a deferred shape
=
==33829==ERROR: AddressSanitizer: heap-use-after-free on address 0x60400ee8
at pc 0x000100423feb bp 0x7ffeefbfe3b0 sp 0x7ffeefbfe3a8
READ of size 8 at 0x60400ee8 thread T0
...

[Bug fortran/78746] charlen_03, charlen_10 ICE

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #26 from anlauf at gcc dot gnu.org ---
Should be fixed on master for gcc-11, and on 10- and 9-branch.
Validated with valgrind that class_61.f90 no longer shows the issue.

Closing.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #25 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

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

commit r9-9162-gef7d053ea33cc9abc7fc413213705a16478fefc4
Author: Harald Anlauf 
Date:   Wed Jan 6 19:37:11 2021 +0100

PR fortran/78746 - invalid access after error recovery

The error recovery after an invalid reference to an undefined CLASS
during a TYPE declaration lead to an invalid access.  Add a check.

gcc/fortran/ChangeLog:

* resolve.c (resolve_component): Add check for valid CLASS
reference before trying to access CLASS data.

(cherry picked from commit 8b6f1e8f97fe0d435d334075821149dbd85c8266)

[Bug fortran/78746] charlen_03, charlen_10 ICE

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #24 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:19eb1973321375190485bc49e68992863b1972bf

commit r10-9234-g19eb1973321375190485bc49e68992863b1972bf
Author: Harald Anlauf 
Date:   Wed Jan 6 19:37:11 2021 +0100

PR fortran/78746 - invalid access after error recovery

The error recovery after an invalid reference to an undefined CLASS
during a TYPE declaration lead to an invalid access.  Add a check.

gcc/fortran/ChangeLog:

* resolve.c (resolve_component): Add check for valid CLASS
reference before trying to access CLASS data.

(cherry picked from commit 8b6f1e8f97fe0d435d334075821149dbd85c8266)

[Bug fortran/78746] charlen_03, charlen_10 ICE

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #23 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:8b6f1e8f97fe0d435d334075821149dbd85c8266

commit r11-6505-g8b6f1e8f97fe0d435d334075821149dbd85c8266
Author: Harald Anlauf 
Date:   Wed Jan 6 19:37:11 2021 +0100

PR fortran/78746 - invalid access after error recovery

The error recovery after an invalid reference to an undefined CLASS
during a TYPE declaration lead to an invalid access.  Add a check.

gcc/fortran/ChangeLog:

* resolve.c (resolve_component): Add check for valid CLASS
reference before trying to access CLASS data.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #22 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-January/01.html

[Bug fortran/78746] charlen_03, charlen_10 ICE

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #21 from anlauf at gcc dot gnu.org ---
Potential fix:

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index fa6f756d285..891db391907 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -14384,7 +14396,7 @@ resolve_component (gfc_component *c, gfc_symbol *sym)
   /* F2008, C448.  */
   if (c->ts.type == BT_CLASS)
 {
-  if (CLASS_DATA (c))
+  if (c->attr.class_ok && CLASS_DATA (c))
{
  attr = &(CLASS_DATA (c)->attr);

At least valgrind is happy with that change.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #20 from David Binderman  ---
(In reply to Arseny Solokha from comment #17)
> Just in case, w/ gcc/testsuite/gfortran.dg/class_61.f90 (as of r268503):
> 
> ==20572== Invalid read of size 8
> ==20572==at 0x8150A4: resolve_component(gfc_component*, gfc_symbol*)
> (resolve.c:13809)
> ==20572==by 0x815BB2: resolve_fl_derived0(gfc_symbol*) [clone .part.54]
> (resolve.c:14258)
> ==20572==by 0x8161FF: resolve_fl_derived0 (resolve.c:14357)
> ==20572==by 0x8161FF: resolve_fl_derived(gfc_symbol*) (resolve.c:14387)

I can confirm that I am still seeing this one, over a year later.

Since the code is in error, probably not a high priority.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[dominiq at lps dot ens.fr]

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

--- Comment #19 from Dominique d'Humieres  ---
> Still worth fixing, but IMHO a low priority.

Well, there is a latent bug that may show on an other target.

There are seven other PRs containing heap-use-after-free:

48776   ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE
52622   heap-use-after-free with instrumented compiler
87908   ICE in check_interface0, at fortran/interface.c:1841
79524   [7/8/9 Regression] valgrind error for gfortran.dg/fimplicit_none_2.f90
82721   [7/8/9 Regression] Error message with corrupted text, sometimes ICE
84245   [7/8/9 Regression] ICE in delete_root, at fortran/bbt.c:150
86657   ASAN error: heap-use-after-free gcc/fortran/symbol.c:1762 in
gfc_add_flavor

[Bug fortran/78746] charlen_03, charlen_10 ICE

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 CC||tkoenig at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #18 from Thomas Koenig  ---
Still worth fixing, but IMHO a low priority.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #17 from Arseny Solokha  ---
Just in case, w/ gcc/testsuite/gfortran.dg/class_61.f90 (as of r268503):

==20572== Invalid read of size 8
==20572==at 0x8150A4: resolve_component(gfc_component*, gfc_symbol*)
(resolve.c:13809)
==20572==by 0x815BB2: resolve_fl_derived0(gfc_symbol*) [clone .part.54]
(resolve.c:14258)
==20572==by 0x8161FF: resolve_fl_derived0 (resolve.c:14357)
==20572==by 0x8161FF: resolve_fl_derived(gfc_symbol*) (resolve.c:14387)
==20572==by 0x812957: resolve_symbol(gfc_symbol*) (resolve.c:14761)
==20572==by 0x83B222: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) (symbol.c:4155)
==20572==by 0x81FA55: resolve_types(gfc_namespace*) (resolve.c:16673)
==20572==by 0x8118FE: gfc_resolve(gfc_namespace*) (resolve.c:16787)
==20572==by 0x8036D6: resolve_all_program_units (parse.c:6073)
==20572==by 0x8036D6: gfc_parse_file() (parse.c:6323)
==20572==by 0x850FDE: gfc_be_parse_file() (f95-lang.c:204)
==20572==by 0xDA085C: compile_file() (toplev.c:456)
==20572==by 0x76966E: do_compile (toplev.c:2176)
==20572==by 0x76966E: toplev::main(int, char**) (toplev.c:2311)
==20572==by 0x76BADD: main (main.c:39)
==20572==  Address 0x4fafcb0 is 192 bytes inside a block of size 344 free'd
==20572==at 0x4833FEB: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20572==by 0x841E40: gfc_restore_last_undo_checkpoint() (symbol.c:3705)
==20572==by 0x7F9786: reject_statement() (parse.c:2576)
==20572==by 0x7FA577: match_word (parse.c:70)
==20572==by 0x7FA577: decode_statement() (parse.c:376)
==20572==by 0x7FE341: next_free (parse.c:1241)
==20572==by 0x7FE341: next_statement() (parse.c:1473)
==20572==by 0x800194: parse_derived (parse.c:3285)
==20572==by 0x800194: parse_spec(gfc_statement) (parse.c:3826)
==20572==by 0x802AAF: parse_progunit(gfc_statement) (parse.c:5680)
==20572==by 0x803671: gfc_parse_file() (parse.c:6220)
==20572==by 0x850FDE: gfc_be_parse_file() (f95-lang.c:204)
==20572==by 0xDA085C: compile_file() (toplev.c:456)
==20572==by 0x76966E: do_compile (toplev.c:2176)
==20572==by 0x76966E: toplev::main(int, char**) (toplev.c:2311)
==20572==by 0x76BADD: main (main.c:39)
==20572==  Block was alloc'd at
==20572==at 0x48351A6: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20572==by 0x1671700: xcalloc (xmalloc.c:162)
==20572==by 0x840848: gfc_new_symbol(char const*, gfc_namespace*)
(symbol.c:3123)
==20572==by 0x840C77: gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) (symbol.c:3373)
==20572==by 0x840EE1: gfc_get_symbol(char const*, gfc_namespace*,
gfc_symbol**) (symbol.c:3426)
==20572==by 0x79385F: gfc_match_decl_type_spec(gfc_typespec*, int)
(decl.c:4325)
==20572==by 0x795E51: gfc_match_data_decl() (decl.c:5934)
==20572==by 0x7FA55B: match_word (parse.c:65)
==20572==by 0x7FA55B: decode_statement() (parse.c:376)
==20572==by 0x7FE341: next_free (parse.c:1241)
==20572==by 0x7FE341: next_statement() (parse.c:1473)
==20572==by 0x800194: parse_derived (parse.c:3285)
==20572==by 0x800194: parse_spec(gfc_statement) (parse.c:3826)
==20572==by 0x802AAF: parse_progunit(gfc_statement) (parse.c:5680)
==20572==by 0x803671: gfc_parse_file() (parse.c:6220)

[Bug fortran/78746] charlen_03, charlen_10 ICE

[kargl at gcc dot gnu.org]

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

--- Comment #16 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #15)
> I still get
> 
> % gfcg charlen_10.f90 
> charlen_10.f90:5:39:
> 
> 5 |   character(:), allocatable :: x(y)1  ! { dg-error "must have a
> deferred shape" }
>   |   1
> Error: Allocatable component of structure at (1) must have a deferred shape
> =
> ==64346==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x60401028 at pc 0x0001003ef71b bp 0x7ffeefbfe4d0 sp 0x7ffeefbfe4c8
> READ of size 8 at 0x60401028 thread T0
> #0 0x1003ef71a in gfc_resolve_expr(gfc_expr*) resolve.c:6839
> #1 0x10001556f in resolve_array_bound(gfc_expr*, int) array.c:346
> #2 0x10001c067 in gfc_resolve_array_spec(gfc_array_spec*, int)
> array.c:387
> #3 0x1003e3709 in resolve_component(gfc_component*, gfc_symbol*)
> resolve.c:14148
> ...

So what?  An error message has been emitted and gfortran is exiting.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[dominiq at lps dot ens.fr]

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

--- Comment #15 from Dominique d'Humieres  ---
I still get

% gfcg charlen_10.f90 
charlen_10.f90:5:39:

5 |   character(:), allocatable :: x(y)1  ! { dg-error "must have a
deferred shape" }
  |   1
Error: Allocatable component of structure at (1) must have a deferred shape
=
==64346==ERROR: AddressSanitizer: heap-use-after-free on address 0x60401028
at pc 0x0001003ef71b bp 0x7ffeefbfe4d0 sp 0x7ffeefbfe4c8
READ of size 8 at 0x60401028 thread T0
#0 0x1003ef71a in gfc_resolve_expr(gfc_expr*) resolve.c:6839
#1 0x10001556f in resolve_array_bound(gfc_expr*, int) array.c:346
#2 0x10001c067 in gfc_resolve_array_spec(gfc_array_spec*, int) array.c:387
#3 0x1003e3709 in resolve_component(gfc_component*, gfc_symbol*)
resolve.c:14148
...

[Bug fortran/78746] charlen_03, charlen_10 ICE

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #14 from kargl at gcc dot gnu.org ---
Both charlen_03.f90 and charlen_10.f90 now issue
errors without an ICE on FreeBSD.  valgrind is
currently broken, so I cannot to a deeper test.
I suspect that one of Paul's recent patches may
have accidentally fixed the remaining issues.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
> Dominique: Can the bug be marked as resolved?

The attached tests are still failing on trunk (9.0).

[Bug fortran/78746] charlen_03, charlen_10 ICE

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
Dominique: Can the bug be marked as resolved?

[Bug fortran/78746] charlen_03, charlen_10 ICE

[clyon at gcc dot gnu.org]

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

--- Comment #11 from Christophe Lyon  ---
I confirm that charlen_15 now compiles & executes OK for me.

charlen_03 and charlen_10 have been removed, so they no longer fail :-)

[Bug fortran/78746] charlen_03, charlen_10 ICE

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> Both of the remaining testcases now compile for me.
> Probably can close this PR.

With my instrumented gfortran compiler I still see failures similar to the one
reported in comment 2:

pr78746.f90:5:39:

   character(:), allocatable :: x(n) ! { dg-error "must have a deferred
shape" }
   1
Error: Allocatable component of structure at (1) must have a deferred shape
=
==80385==ERROR: AddressSanitizer: heap-use-after-free on address 0x604010e8
at pc 0x0001003b3627 bp 0x7fff5fbfe530 sp 0x7fff5fbfe528
READ of size 8 at 0x604010e8 thread T0
#0 0x1003b3626 in gfc_resolve_expr(gfc_expr*) resolve.c:6736
#1 0x100015279 in resolve_array_bound(gfc_expr*, int) array.c:327
#2 0x10001bd19 in gfc_resolve_array_spec(gfc_array_spec*, int) array.c:368
#3 0x1003a7bdd in resolve_component(gfc_component*, gfc_symbol*)
resolve.c:13920
#4 0x1003abfa1 in resolve_fl_derived0(gfc_symbol*) resolve.c:14039
#5 0x1003acbdb in resolve_fl_derived(gfc_symbol*) resolve.c:14134
#6 0x10039a977 in resolve_symbol(gfc_symbol*) resolve.c:14479
#7 0x10046c576 in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*),
void (*)(gfc_symbol*)) symbol.c:4157
#8 0x10048a3a5 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
symbol.c:4182
#9 0x1004002ed in resolve_types(gfc_namespace*) resolve.c:16358
#10 0x100395fc9 in gfc_resolve(gfc_namespace*) resolve.c:16472
#11 0x1002feb25 in resolve_all_program_units(gfc_namespace*) parse.c:6030
#12 0x10031dc5f in gfc_parse_file() parse.c:6280
#13 0x1004d36b3 in gfc_be_parse_file() f95-lang.c:204
#14 0x1052de1b0 in compile_file() toplev.c:454
#15 0x1052e857d in do_compile() toplev.c:2059
#16 0x1075dd23b in toplev::main(int, char**) toplev.c:2194
#17 0x1075e2a87 in main main.c:39
#18 0x7fffcb057234 in start (libdyld.dylib:x86_64+0x5234)

0x604010e8 is located 24 bytes inside of 48-byte region
[0x604010d0,0x60401100)
freed by thread T0 here:
#0 0x1562efe10 in wrap_free.part.0 sanitizer_malloc_mac.inc:142
#1 0x100480732 in gfc_delete_symtree(gfc_symtree**, char const*)
symbol.c:2927
#2 0x10049a7d4 in gfc_restore_last_undo_checkpoint() symbol.c:3694
#3 0x10049aa2c in gfc_undo_symbols() symbol.c:3727
#4 0x1002fefd5 in reject_statement() parse.c:2546
#5 0x1002ff11d in match_word(char const*, match (*)(), locus*) parse.c:70
#6 0x10030ba38 in decode_statement() parse.c:376
#7 0x10030e091 in next_free() parse.c:1225
#8 0x10030ea5e in next_statement() parse.c:1457
#9 0x100313af2 in parse_derived() parse.c:3255
#10 0x1003154d7 in parse_spec(gfc_statement) parse.c:3795
#11 0x10031b954 in parse_progunit(gfc_statement) parse.c:5637
#12 0x10031dc21 in gfc_parse_file() parse.c:6177
#13 0x1004d36b3 in gfc_be_parse_file() f95-lang.c:204
#14 0x1052de1b0 in compile_file() toplev.c:454
#15 0x1052e857d in do_compile() toplev.c:2059
#16 0x1075dd23b in toplev::main(int, char**) toplev.c:2194
#17 0x1075e2a87 in main main.c:39
#18 0x7fffcb057234 in start (libdyld.dylib:x86_64+0x5234)

previously allocated by thread T0 here:
#0 0x1562ef46c in wrap_calloc sanitizer_malloc_mac.inc:153
#1 0x10746b354 in xcalloc xmalloc.c:162
#2 0x1004803dd in gfc_new_symtree(gfc_symtree**, char const*) symbol.c:2897
#3 0x1004843d2 in gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) symbol.c:3356
#4 0x100490128 in gfc_get_ha_sym_tree(char const*, gfc_symtree**)
symbol.c:3441
#5 0x100341f22 in gfc_match_rvalue(gfc_expr**) primary.c:3141
#6 0x100226505 in match_primary(gfc_expr**) matchexp.c:157
#7 0x100226794 in match_level_1(gfc_expr**) matchexp.c:211
#8 0x100226b09 in match_mult_operand(gfc_expr**) matchexp.c:267
#9 0x100227313 in match_add_operand(gfc_expr**) matchexp.c:356
#10 0x100227d00 in match_level_2(gfc_expr**) matchexp.c:480
#11 0x100228210 in match_level_3(gfc_expr**) matchexp.c:551
#12 0x100228689 in match_level_4(gfc_expr**) matchexp.c:599
#13 0x1002294bd in match_and_operand(gfc_expr**) matchexp.c:693
#14 0x10022978c in match_or_operand(gfc_expr**) matchexp.c:722
#15 0x100229bf1 in match_equiv_operand(gfc_expr**) matchexp.c:765
#16 0x10022a060 in match_level_5(gfc_expr**) matchexp.c:811
#17 0x100226029 in gfc_match_expr(gfc_expr**) matchexp.c:870
#18 0x1000192cc in match_array_element_spec(gfc_array_spec*) array.c:433
#19 0x10001ca3d in gfc_match_array_spec(gfc_array_spec**, bool, bool)
array.c:528
#20 0x1000cf09c in variable_decl(int) decl.c:2256
#21 0x1000d2ab8 in gfc_match_data_decl() decl.c:5679
#22 0x1002ff09b in match_word(char const*, match (*)(), locus*) parse.c:65
#23 0x10030ba38 in decode_statement() parse.c:376
#24 0x10030e091 in next_free() 

[Bug fortran/78746] charlen_03, charlen_10 ICE

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #8)
> I have removed the two failing testcase and attached them to this PR.
> 
> It is likely the dg-error will need to be updated when the bug is
> fixed.

Both of the remaining testcases now compile for me.
Probably can close this PR.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
I have removed the two failing testcase and attached them to this PR.

It is likely the dg-error will need to be updated when the bug is
fixed.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Created attachment 40360
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40360=edit
charlen_10.f90 source code

[Bug fortran/78746] charlen_03, charlen_10 ICE

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Created attachment 40359
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40359=edit
charlen_30.f90 testcase

[Bug fortran/78746] charlen_03, charlen_10 ICE

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Dec 17 23:10:01 2016
New Revision: 243778

URL: https://gcc.gnu.org/viewcvs?rev=243778=gcc=rev
Log:
2016-12-17  Steven G. Kargl  

PR fortran/78746
* charlen_03.f90: Remove test. 
* charlen_10.f90: Ditto.

Removed:
trunk/gcc/testsuite/gfortran.dg/charlen_03.f90
trunk/gcc/testsuite/gfortran.dg/charlen_10.f90
Modified:
trunk/gcc/testsuite/ChangeLog