http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52452
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Known to work| |4.1.2, 4.3.4, 4.4.0
Keywords| |rejects-valid
Last reconfirmed| |2012-03-01
CC| |burnus at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|INTRINSIC cannot be applied |[4.5/4.6/4.7 Regression]
|to gfortran's ETIME |INTRINSIC cannot be applied
| |to gfortran's ETIME
Target Milestone|--- |4.5.4
Known to fail| |4.5.3, 4.6.2, 4.7.0
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-01
18:59:41 UTC ---
That's odd, but I can reproduce it. It works with GCC 4.1 to 4.4.
I think the problem is related to a specialty of ETIME and a few other vendor
intrinsics: ETIME can be either a function or a subroutine, cf.
http://gcc.gnu.org/onlinedocs/gfortran/ETIME.html
I think with
INTRINSIC :: etime
it is first evaluated for that line - and for some reasons the function version
is chosen. And then later for
CALL etime(tarray, result)
one gets then an error.
Untested patch:
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1496,7 +1498,7 @@ resolve_intrinsic (gfc_symbol *sym, locus *loc)
if (sym->intmod_sym_id)
isym = gfc_intrinsic_function_by_id ((gfc_isym_id) sym->intmod_sym_id);
- else
+ else if (!sym->attr.subroutine)
isym = gfc_find_function (sym->name);
if (isym)
