This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, fortran] PR30476 - [Regression 4.2, 4.3] Via other module imported generic interface rejected
- From: Paul Thomas <paulthomas2 at wanadoo dot fr>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 17 Jan 2007 11:48:47 +0100
- Subject: Re: [Patch, fortran] PR30476 - [Regression 4.2, 4.3] Via other module imported generic interface rejected
- References: <45ACE57D.10703@wanadoo.fr> <45AD0C96.4050601@net-b.de>
Hi Tobias,
/home/tob/projects/gcc/gcc/fortran/module.c:3100: Warning: the address
of "module" will always evaluate as "true"
module is defined as:
char module[GFC_MAX_SYMBOL_LEN + 1];
Maybe it is better to use if (module[0] && ... ?
No, it's better to eliminate that part of the condition completely; it's
pure reflex to check that a pointer is there. Thanks
This part of the code now reads:
{
/* Unless sym is a generic interface, this reference
is ambiguous. */
gfc_symtree *st;
p = p ? p : name;
st = gfc_find_symtree (gfc_current_ns->sym_root, p);
if (!sym->attr.generic
&& sym->module != NULL
&& strcmp(module, sym->module) != 0)
st->ambiguous = 1;
}
Is my assumption correct that st->ambiguous gets already set correctly
via gfc_find_symtree?
No, st->ambiguous only gets set in two places; both in module.c.
I build & regtested it on openSUSE/x86_64 with no new regressions.
Is it OK with the above change?
Paul
PS reply:
Post scriptum and unrelated to this patch:
For some reasons I get a core-dump when running interface_10.f90 and
somehow two ambiguous errors are not detected when compiling
interface_11.f90 (dg-error in lines 72 and 88). However, I also have
these failures without the patch applied.
You answered your own question on this one :-)
* c_by_val_1 and vect/vect-4.f90 fail on i64:
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00633.html
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00612.html
The c_by_val bit is PR30432 which I am in no position to do anything
with because I do not see it. Andrew Pinski has raised the concern, in
the PR thread, that this not a gfortran issue.
* open_errors.f90, string_0xfe_0xff_1.f90 and vect/vect-5.f90 on
sparc-sun-solaris
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00628.html
* on aix5 c_by_val, static_linking_1, string_0xfe_0xff_1.f90, value_4 and
gfortran.fortran-torture/execute/intrinsic_nearest.f90 fail
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00624.html
ditto, I suspect.
* on hppa-linux fail bound_2, cray_pointers_2, and string_0xfe_0xff_1.f90
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00622.html
* on another x86_64 (-m32 and -m64) fails string_0xfe_0xff_1.f90
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00613.html
I think that Thomas has dealt with the last?