https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461
--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- (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.
