[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 --- Comment #11 from Thomas Koenig --- Author: tkoenig Date: Tue Mar 12 17:22:28 2019 New Revision: 269624 URL: https://gcc.gnu.org/viewcvs?rev=269624=gcc=rev Log: 2019-03-12 Thomas Koenig PR fortran/87673 * match.c (gfc_match_type_spec): Remove call to gfc_resolve_expr for character length. 2019-03-12 Thomas Koenig PR fortran/87673 * gfortran.dg/charlen_17.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/charlen_17.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #10 from Thomas Koenig --- (In reply to Thomas Koenig from comment #9) > This "fixes" this PR, of course bringing back > the original problem (PR82049). Or rather, not bringing it back. I assume that one of Harald's patches fixed this another way in the meantime.
[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 --- Comment #9 from Thomas Koenig --- This "fixes" this PR, of course bringing back the original problem (PR82049). Index: match.c === --- match.c (Revision 269552) +++ match.c (Arbeitskopie) @@ -2122,8 +2122,10 @@ ts->type = BT_CHARACTER; m = gfc_match_char_spec (ts); +#if 0 if (ts->u.cl && ts->u.cl->length) gfc_resolve_expr (ts->u.cl->length); +#endif if (m == MATCH_NO) m = MATCH_YES; Next, to see what gfc_resolve_expr is doing wrong here.
[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 --- Comment #8 from Thomas Koenig --- > No ICE with r257407+2 patches (2018-02-06), ICE with r257500+3 patches > (2018-02-08). Bisection shows that r257459 fails, r257458 works. This also makes sense because r257459 deals with that general area.
[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 --- Comment #7 from Dominique d'Humieres --- > Trying some bisection. > > r257267 was ok, r258291 showed the is_illegal_recursion bug and > also shows the error with that removed. > > To be continued... No ICE with r257407+2 patches (2018-02-06), ICE with r257500+3 patches (2018-02-08).
[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 --- Comment #6 from Thomas Koenig --- Trying some bisection. r257267 was ok, r258291 showed the is_illegal_recursion bug and also shows the error with that removed. To be continued...
[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 --- Comment #5 from Thomas Koenig --- A better traceback. Part of this seems to be a use after free problem: =5863== Invalid read of size 1 ==5863==at 0x8FEEB4: resolve_elemental_actual(gfc_expr*, gfc_code*) (resolve.c:2160) ==5863==by 0x90160F: resolve_function(gfc_expr*) (resolve.c:3228) ==5863==by 0x909ECE: gfc_resolve_expr(gfc_expr*) (resolve.c:6866) ==5863==by 0x915AC6: resolve_charlen(gfc_charlen*) (resolve.c:11943) ==5863==by 0x921D66: resolve_types(gfc_namespace*) (resolve.c:16727) ==5863==by 0x921E24: resolve_types(gfc_namespace*) (resolve.c:16740) ==5863==by 0x92221F: gfc_resolve(gfc_namespace*) (resolve.c:16843) ==5863==by 0x8F1D04: gfc_parse_file() (parse.c:6275) ==5863==by 0x95177B: gfc_be_parse_file() (f95-lang.c:204) ==5863==by 0xED717F: compile_file() (toplev.c:456) ==5863==by 0x81F707: do_compile (toplev.c:2204) ==5863==by 0x81F707: toplev::main(int, char**) (toplev.c:2339) ==5863==by 0x8231BE: main (main.c:39) ==5863== Address 0x58b1dc7 is 87 bytes inside a block of size 344 free'd ==5863==at 0x4C2B390: free (vg_replace_malloc.c:530) ==5863==by 0x9448FF: gfc_free_symbol(gfc_symbol*) (symbol.c:3087) ==5863==by 0x9449EE: gfc_release_symbol(gfc_symbol*) (symbol.c:3114) ==5863==by 0x8F05E0: gfc_fixup_sibling_symbols(gfc_symbol*, gfc_namespace*) (parse.c:5492) ==5863==by 0x8F088A: parse_contained(int) (parse.c:5584) ==5863==by 0x8F126C: parse_module() (parse.c:5953) ==5863==by 0x8F1C36: gfc_parse_file() (parse.c:6248) ==5863==by 0x95177B: gfc_be_parse_file() (f95-lang.c:204) ==5863==by 0xED717F: compile_file() (toplev.c:456) ==5863==by 0x81F707: do_compile (toplev.c:2204) ==5863==by 0x81F707: toplev::main(int, char**) (toplev.c:2339) ==5863==by 0x8231BE: main (main.c:39) ==5863== Block was alloc'd at ==5863==at 0x4C2C432: calloc (vg_replace_malloc.c:752) ==5863==by 0x189EC60: xcalloc (xmalloc.c:162) ==5863==by 0x944A15: gfc_new_symbol(char const*, gfc_namespace*) (symbol.c:3125) ==5863==by 0x9450BA: gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**, bool) (symbol.c:3375) ==5863==by 0x94539C: gfc_get_ha_sym_tree(char const*, gfc_symtree**) (symbol.c:3468) ==5863==by 0x8F8677: gfc_match_rvalue(gfc_expr**) (primary.c:3349) ==5863==by 0x8BCC54: match_primary(gfc_expr**) (matchexp.c:157) ==5863==by 0x8BCD67: match_level_1(gfc_expr**) (matchexp.c:211) ==5863==by 0x8BCE29: match_mult_operand(gfc_expr**) (matchexp.c:267) ==5863==by 0x8BD034: match_add_operand(gfc_expr**) (matchexp.c:356) ==5863==by 0x8BD2F4: match_level_2(gfc_expr**) (matchexp.c:480) ==5863==by 0x8BD486: match_level_3(gfc_expr**) (matchexp.c:551) ==5863==
[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 --- Comment #4 from Thomas Koenig --- Running f951 under valgrind, we get with current trunk (r269549): ==27666== Memcheck, a memory error detector ==27666== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==27666== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==27666== Command: /home/ig25/lib/gcc/x86_64-pc-linux-gnu/9.0.1/f951 big.f90 ==27666== ==27666== Conditional jump or move depends on uninitialised value(s) ==27666==at 0x84A598: gfc_match_decl_type_spec(gfc_typespec*, int) (decl.c:4047) ==27666==by 0x84BA2C: gfc_match_data_decl() (decl.c:5950) ==27666==by 0x8AA8D0: match_word (parse.c:65) ==27666==by 0x8AA8D0: decode_statement() (parse.c:376) ==27666==by 0x8AE374: next_free (parse.c:1241) ==27666==by 0x8AE374: next_statement() (parse.c:1473) ==27666==by 0x8B04A4: parse_spec(gfc_statement) (parse.c:3681) ==27666==by 0x8B220C: parse_progunit(gfc_statement) (parse.c:5680) ==27666==by 0x8B25AD: parse_contained(int) (parse.c:5581) ==27666==by 0x8B329E: parse_module() (parse.c:5953) ==27666==by 0x8B36EB: gfc_parse_file() (parse.c:6256) ==27666==by 0x8FCDCF: gfc_be_parse_file() (f95-lang.c:204) ==27666==by 0xE2234F: compile_file() (toplev.c:456) ==27666==by 0x81F907: do_compile (toplev.c:2204) ==27666==by 0x81F907: toplev::main(int, char**) (toplev.c:2339) ==27666== ==27666== Invalid read of size 1 ==27666==at 0x8BC9DE: resolve_elemental_actual(gfc_expr*, gfc_code*) (resolve.c:2160) ==27666==by 0x8CC2B2: resolve_function (resolve.c:3228) ==27666==by 0x8CC2B2: gfc_resolve_expr(gfc_expr*) (resolve.c:6866) ==27666==by 0x8CFACB: resolve_charlen(gfc_charlen*) [clone .part.0] (resolve.c:11943) ==27666==by 0x8C09A8: resolve_charlen (resolve.c:11934) ==27666==by 0x8C09A8: resolve_types(gfc_namespace*) (resolve.c:16727) ==27666==by 0x8C0A63: resolve_types(gfc_namespace*) (resolve.c:16740) ==27666==by 0x8C5DDC: gfc_resolve(gfc_namespace*) [clone .part.0] (resolve.c:16843) ==27666==by 0x8B3706: gfc_parse_file() (parse.c:6275) ==27666==by 0x8FCDCF: gfc_be_parse_file() (f95-lang.c:204) ==27666==by 0xE2234F: compile_file() (toplev.c:456) ==27666==by 0x81F907: do_compile (toplev.c:2204) ==27666==by 0x81F907: toplev::main(int, char**) (toplev.c:2339) ==27666==by 0x8233BE: main (main.c:39) [...] so I suspect that this is where the problem comes from.
[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |7.5 Summary|Errors caused by using |[7/8/9 Regression] Errors |function for character |caused by using function |length in allocate with |for character length in |typespec|allocate with typespec
