[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 --- Comment #9 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #6) > Hiesenbug. Steves fix, probably on BSD, does not work on linux. Some of my > attempts work when running within the debugger, but do not work outside the > debugger. I have traced through the scanner with and without the END > statement and see nothing yet. I resolved the Hiesenbug issue and now I get Steve's result. I had a bad soft link in my local test setup. I have traced the MATCH_ERROR several levels down inside gfc_match_expr. I have not fingered it yet
[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 --- Comment #6 from Jerry DeLisle --- Hiesenbug. Steves fix, probably on BSD, does not work on linux. Some of my attempts work when running within the debugger, but do not work outside the debugger. I have traced through the scanner with and without the END statement and see nothing yet. We might try a regression hunt to see where it broke to get a hint. One thing I have not checked yet is in fixed form we skip past the first characters of each line. We may need to trap an EOF when we are doing that skipping.
[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #7 from Joost VandeVondele --- (In reply to Jerry DeLisle from comment #6) > Hiesenbug. Steves fix, probably on BSD, does not work on linux. Some of my > attempts work when running within the debugger, but do not work outside the > debugger. I have traced through the scanner with and without the END > statement and see nothing yet. > > We might try a regression hunt to see where it broke to get a hint. One > thing I have not checked yet is in fixed form we skip past the first > characters of each line. We may need to trap an EOF when we are doing that > skipping. This might be obvious, but valgrind might give a hint ? : -linux-gnu/6.0.0/finclude -o /tmp/ccyEi6l3.s ==20860== ==20860== Invalid read of size 4 ==20860==at 0x5DF7C1: free_expr0(gfc_expr*) (expr.c:431) ==20860==by 0x5DF9BD: gfc_free_expr(gfc_expr*) (expr.c:513) ==20860==by 0x60FE57: gfc_match_if(gfc_statement*) (match.c:1441) ==20860==by 0x62BF91: decode_statement (parse.c:398) ==20860==by 0x62BF91: decode_statement() (parse.c:293) ==20860==by 0x62D434: next_free (parse.c:1076) ==20860==by 0x62D434: next_statement() (parse.c:1310) ==20860==by 0x62F4D4: parse_executable(gfc_statement) (parse.c:4792) ==20860==by 0x630311: parse_progunit(gfc_statement) (parse.c:5215) ==20860==by 0x6316C0: gfc_parse_file() (parse.c:5698) ==20860==by 0x6745A2: gfc_be_parse_file() (f95-lang.c:201) ==20860==by 0xB64FD2: compile_file() (toplev.c:464) ==20860==by 0xB6706B: do_compile (toplev.c:1985) ==20860==by 0xB6706B: toplev::main(int, char**) (toplev.c:2092) ==20860==by 0x1354346: main (main.c:39) ==20860== Address 0x4dc1b50 is 0 bytes inside a block of size 192 free'd ==20860==at 0x4A06D9B: free (vg_replace_malloc.c:530) ==20860==by 0x60FE12: gfc_match_if(gfc_statement*) (match.c:1425) ==20860==by 0x62BF91: decode_statement (parse.c:398) ==20860==by 0x62BF91: decode_statement() (parse.c:293) ==20860==by 0x62D434: next_free (parse.c:1076) ==20860==by 0x62D434: next_statement() (parse.c:1310) ==20860==by 0x62F4D4: parse_executable(gfc_statement) (parse.c:4792) ==20860==by 0x630311: parse_progunit(gfc_statement) (parse.c:5215) ==20860==by 0x6316C0: gfc_parse_file() (parse.c:5698) ==20860==by 0x6745A2: gfc_be_parse_file() (f95-lang.c:201) ==20860==by 0xB64FD2: compile_file() (toplev.c:464) ==20860==by 0xB6706B: do_compile (toplev.c:1985) ==20860==by 0xB6706B: toplev::main(int, char**) (toplev.c:2092) ==20860==by 0x1354346: main (main.c:39) ==20860== Block was alloc'd at ==20860==at 0x4A07B05: calloc (vg_replace_malloc.c:711) ==20860==by 0x13C2368: xcalloc (xmalloc.c:163) ==20860==by 0x5DF29F: gfc_get_expr() (expr.c:48) ==20860==by 0x5DF397: gfc_get_operator_expr(locus*, gfc_intrinsic_op, gfc_expr*, gfc_expr*) (expr.c:106) ==20860==by 0x5B1090: eval_intrinsic(gfc_intrinsic_op, eval_f, gfc_expr*, gfc_expr*) (arith.c:1611) ==20860==by 0x5B1440: eval_intrinsic_f3 (arith.c:1725) ==20860==by 0x5B1440: eval_intrinsic_f3(gfc_intrinsic_op, arith (*)(gfc_expr*, gfc_expr*, gfc_expr**), gfc_expr*, gfc_expr*) (arith.c:1713) ==20860==by 0x6131B2: match_equiv_operand(gfc_expr**) (matchexp.c:784) ==20860==by 0x613276: match_level_5(gfc_expr**) (matchexp.c:811) ==20860==by 0x612572: gfc_match_expr(gfc_expr**) (matchexp.c:870) ==20860==by 0x60B870: gfc_match(char const*, ...) (match.c:1015) ==20860==by 0x60FCC7: gfc_match_if(gfc_statement*) (match.c:1347) ==20860==by 0x62BF91: decode_statement (parse.c:398) ==20860==by 0x62BF91: decode_statement() (parse.c:293)
[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 --- Comment #8 from Jerry DeLisle --- (In reply to Joost VandeVondele from comment #7) > (In reply to Jerry DeLisle from comment #6) > > Hiesenbug. Steves fix, probably on BSD, does not work on linux. Some of my > > attempts work when running within the debugger, but do not work outside the > > debugger. I have traced through the scanner with and without the END > > statement and see nothing yet. > > > > We might try a regression hunt to see where it broke to get a hint. One > > thing I have not checked yet is in fixed form we skip past the first > > characters of each line. We may need to trap an EOF when we are doing that > > skipping. > > This might be obvious, but valgrind might give a hint ? : > > -linux-gnu/6.0.0/finclude -o /tmp/ccyEi6l3.s > ==20860== > ==20860== Invalid read of size 4 > ==20860==at 0x5DF7C1: free_expr0(gfc_expr*) (expr.c:431) > ==20860==by 0x5DF9BD: gfc_free_expr(gfc_expr*) (expr.c:513) > ==20860==by 0x60FE57: gfc_match_if(gfc_statement*) (match.c:1441) Yes we know it is near here. I am suspecting that we have actually matched the good if statement and have gone down again in the next_statement with premature file end. The gfc_match_if calls gfc_match which calls many matchers and expr is coming back junk. The bugger is why it depends on fixed form, thus my comment above.
[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 --- Comment #4 from Jerry DeLisle --- Yes, I was looking at this in gdb lst night and I am really suspicious of the comment about guaranteed to match. I tried with what you did only I did not return at that point. The fact that it has to do with fixed form continuation had me digging in scanner.c. I also noticed that the expr returned after what looks like a good free_expr (good meaning no ICE) leaves the contents of the expr as garbage. I wonder if the free_expression should set all the sub component types in the structure to valid values to avoid these issues.
[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 --- Comment #5 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #4) > Yes, I was looking at this in gdb lst night and I am really suspicious of > the comment about guaranteed to match. I tried with what you did only I did > not return at that point. The fact that it has to do with fixed form > continuation had me digging in scanner.c. I also noticed that the expr > returned after what looks like a good free_expr (good meaning no ICE) leaves > the contents of the expr as garbage. I wonder if the free_expression should > set all the sub component types in the structure to valid values to avoid > these issues. ie Set expr = NULL, but it does not help.
[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.4
[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
The bug surfaces at line 1439 in match.c. The line is
gfc_match (" if ( %e ) ", ); /* Guaranteed to match. */
The comment is wrong. For some reason, splitting
the expression across the two lines causes a match
failure. Changing the above to
m = gfc_match (" if ( %e ) ", );
if (m != MATCH_YES)
return m;
yields
troutmask:sgk[232] gfc6 -c g5.f
g5.f:5:72:
Error: Syntax error in expression at (1)
f951: Error: Unexpected end of file in 'g5.f'
which yields a bogus error and the desired error.
[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||4.4.7 Keywords||ice-on-invalid-code Last reconfirmed||2015-08-29 Ever confirmed|0 |1 Summary|ICE on missing end program |[4.9/5/6 Regression] ICE on |in fixed source |missing end program in ||fixed source Known to fail||4.5.0 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- That's obviously an old regression: ... As old as r154654.
