[Patch, Fortran] PR58787 ICE (error recovery) in check_proc_interface

Tobias Burnus burnus@net-b.de
Thu Oct 11 23:17:00 GMT 2018


Next patch, next try …

The problem is the following: We have a use-associated symbol (a 
function) – which is once referenced (by use association).

We now declare a same-name function in the 'contains' section.

gfortran now parses the function name, fetches the symbol and reports 
that one duplicates the function (gfc_error_now). However, it continues 
afterwards and creates a sym_tree in the gfc_current_ns – and duly 
increases the sym->refs to 2.

A bit later, the function gets rejected. (Parsing of the formal 
arguments fails when setting a attribute of a use-associated symbol, but 
I think this doesn't matter. reject_statement() is called, which rolls 
back the symbol, but again, I think that doesn't matter – it just makes 
some other solutions a tad more difficult.)

Now, the contains namespace is cleaned up: As the function name is in 
the namespace's sym_tree, gfc_release_symbol() is invoked.

The symbol itself is not freed (as --refs > 0), but sym->formal_ns is. 
(There are some safety nets, like sym->rev == 2 and sym->ns != 
sym->formal_ns, but they don't help.)

Later, the symbol of the parent's namespace is resolved – and this 
includes resolving the formal arguments. – And accessing freed memory 
might crash gfortran.

As solution, I return early and with an error from get_proc_name(). I 
think that's cleaner than waiting longer – and the early return avoids 
creating the symbol at the first place. (Otherwise, modifications have 
to go beyond rolling back of the symbols; doing refs++ probably helps, 
but is rather intransparent.)


Pro of the early return: Avoids accessing already freed memory, might 
generate shorter error output as some later fails (like for not being 
able to modify attributes of a use-associated symbol) are gone.

Contra: As one returns before entering a procedure, all following lines 
are in the outer scope (usually 'contains') and there probably 
unexpected. Hence, one might get a bunch of follow-up errors which do 
not help.


Build on x86-64 and even more carefully regtested.

OK?

Tobias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr58787.diff
Type: text/x-patch
Size: 9294 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20181011/51226d2c/attachment.bin>


More information about the Fortran mailing list