This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC 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]

[Bug fortran/33141] Intrinsic procedures: Improve warning/error with -std=*



------- Comment #3 from burnus at gcc dot gnu dot org  2008-07-19 11:55 -------
>   REAL :: asinh

The real solution is to use "external asinh" if a non-intrinsic procedure is
meant.

> When compiled with -std=f2008 -Wall, it calls the intrinsic "correct" asinh.
> I suspect, in this case we want a warning to be emitted, right?

You mean something like:

   REAL FUNCTION asinh (arg)
                 1
Warning: Procedure at (1) has the same name as an intrinsic procedure


Or alternatively:

Warning: 'asinh' declared at (1) is also the name of an intrinsic. It can only
be called via an explicit interface or if declared EXTERNAL


Thinking about it, such a message would be indeed useful. One could restrict
the warning to non-module procedures as module procedures are only accessible
using "USE MODULE", however, I'm not sure whether one should warn nonetheless.
I'm also not sure whether using -Wsurprising or -W<a_new_name> is better
(probably the latter as then -Wno-<...> can be used).

The warning could dependent on the -std=* but maybe it is better to always
print the warning - at least as long we have the current -std=f* behavor of
silently using the intrinsic function.


Regarding module procedures, Tobias S suggested:

Warning: 'asinh' declared at (1) may shadow the intrinsic of the same name. In
order to call the intrinsic, explicit INTRINSIC declarations may be required


 * * *


> For -std=f2003 without -Wall or -fall-intrinsics, the same happens.
and in comment #1
> Give a better error message with -std=* if the intrinsic procedure is not
> available. Currently, the warning not only depends on -std=* but also on -W*. 

It is far from being obvious what should happen - and gfortran's behaviour also
changed in between.


For "intrinsic erf":

gfortran-4.2 -std=f95:
  Error: Intrinsic at (1) does not exist

gfortran-4.3 -std=f95:
  (silently links the intrinsic version)

g95:
  Error: Function 'erf' at (1) has no implicit type

ifort -stand f95:
  warning #7416: Fortran 95 does not allow this intrinsic procedure.   [ERF]


For "real :: erf; print *, erf(1.0)":

gfortran-4.2 -std=f95  aaa.f
  aaa.f:(.text+0x5f): undefined reference to `erf_'

gfortran-4.3 -std=f95  aaa.f
  (links the intrinsic version)

g95 -std=f95  aaa.f
  aaa.f:(.text+0x6c): undefined reference to `erf_'

ifort -stand f95  aaa.f
  Fortran 95 does not allow this intrinsic procedure.


Thus there are three possibilities:
- Silently use the intrinsic version
- Printing a warning (and using the intrinsic version)
- Printing an error
- Using the external version (and possibly fail at link time)
[The latter is of cause not a solution for the "INTRINSIC ..." case]

I regard the current behavior as very problematic, but I'm fine with any of the
other solutions. In any case, the behavior as in PR 20248 comment 14 should
remain.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33141


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