This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Patch, fortran] PR32526 - [4.3 regression] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'


:ADDPATCH fortran:

This is a regression that I caused in fixing one of the reporter's
previous PRs *sigh*

The problem lies in gfc_match_call.  It is better for this discussion
by showing the original and the faulty versions of the code that gets
a symbol to make a call to:

Originally, the offending code was

 if (gfc_get_ha_sym_tree (name, &st))
   return MATCH_ERROR;

 sym = st->n.sym;
 gfc_set_sym_referenced (sym);

 if (!sym->attr.generic
     && !sym->attr.subroutine
     && gfc_add_subroutine (&sym->attr, sym->name, NULL) == FAILURE)
   return MATCH_ERROR;

Thus, the gfc_get_ha_sym_tree gets an existing symtree, if it can, or
creates a new one.  Then, the symbol is checked for not being a
generic interface or a subroutine before being given the subroutine
attribute.

PR31424 came about because the intent was to call a contained
subroutine but gfc_get_ha_symtree brought back a host associated array
variable instead.  This had the subroutine attribute dolloped on it,
which did not go down very well!

The fix for PR31424 is this:

 if (gfc_get_ha_sym_tree (name, &st))
   return MATCH_ERROR;

sym = st->n.sym;

 if (sym->ns != gfc_current_ns
	&& !sym->attr.generic
	&& !sym->attr.subroutine
       && gfc_get_sym_tree (name, NULL, &st) == 1)
   return MATCH_ERROR;

sym = st->n.sym;

 if (gfc_add_subroutine (&sym->attr, sym->name, NULL) == FAILURE)
   return MATCH_ERROR;

gfc_set_sym_referenced (sym);

This collects a new symtree if the host associated symbol is not
generic or a subroutine, thus fixing PR31424.

However, the testcase for the present PR exposes an error in the
patch.  There is no longer a check on whether or not the symbol is
already a subroutine or generic before adding the attribute.  In the
case here, adding the subroutine attribute to a generic interface
makes the symbol ambiguous when USEing poly_Class.

The fix is brutally simple - make the check, as before.  However, I
have rearranged it a bit and added comments.

Regtests on Cygwin_NT/amd64.

I intend to commit this patch as 'obvious' 24 hours from now, unless
anybody objects.

Thank you for the report, Michael.

Paul

2007-07-04 Paul Thomas <pault@gcc.gnu.org>

	PR fortran/32526
	* match.c (gfc_match_call): Check, in all cases, that a symbol
	is neither generic nor a subroutine before trying to add it as
	a subroutine.

2007-07-04 Paul Thomas <pault@gcc.gnu.org>

	PR fortran/32526
	* gfortran.dg/interface_14.f90: New test.

Attachment: pr32526.diff
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]