[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738

burnus at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Feb 22 18:17:40 GMT 2021


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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Paul Thomas from comment #3)
> Is the problem not that the parser is not picking up the incorrectly placed
> print statement? It should never be passed to the matcher because it is in
> the contains context.

Ups. I mess up my visual parser ... – Yes, I concur that rvalue matching should
not happen (only some 'end' – or 'subroutine'/'[type-spec|(im)pure|...]
function' is permitted – unless it is 'type; ...; contains' which has some
other permitted values or ...

The current code has:

parse_contained()
   st = next_statement ();
      switch (st)
        {
        case ST_NONE:
        case ST_FUNCTION:
        case ST_SUBROUTINE:
        case ST_END_FUNCTION:
        case ST_END_MODULE:
        case ST_END_SUBMODULE:
        case ST_END_PROGRAM:
        case ST_END_SUBROUTINE:
           ...
        default:
          gfc_error ("Unexpected %s statement in CONTAINS section at %C",
                     gfc_ascii_statement (st));

It sounds as if you want to have something which only tries to match those –
and then simply stops with an error at the the end, pointing to the line
without trying to parse it. — That would avoid a lot of 'gfc_error' which are
silenced and speeds up parsing (not that it is really the bottle neck).


More information about the Gcc-bugs mailing list