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)