Node: Context-Sensitive Intrinsicness, Next: Context-Sensitive Constants, Previous: Initializing Before Specifying, Up: Non-bugs
g77
treats procedure references to possible intrinsic
names as always enabling their intrinsic nature, regardless of
whether the form of the reference is valid for that
intrinsic.
For example, CALL SQRT
is interpreted by g77
as
an invalid reference to the SQRT
intrinsic function,
because the reference is a subroutine invocation.
First, g77
recognizes the statement CALL SQRT
as a reference to a procedure named SQRT
, not
to a variable with that name (as it would for a statement
such as V = SQRT
).
Next, g77
establishes that, in the program unit being compiled,
SQRT
is an intrinsic--not a subroutine that
happens to have the same name as an intrinsic (as would be
the case if, for example, EXTERNAL SQRT
was present).
Finally, g77
recognizes that the form of the
reference is invalid for that particular intrinsic.
That is, it recognizes that it is invalid for an intrinsic
function, such as SQRT
, to be invoked as
a subroutine.
At that point, g77
issues a diagnostic.
Some users claim that it is "obvious" that CALL SQRT
references an external subroutine of their own, not an
intrinsic function.
However, g77
knows about intrinsic
subroutines, not just functions, and is able to support both having
the same names, for example.
As a result of this, g77
rejects calls
to intrinsics that are not subroutines, and function invocations
of intrinsics that are not functions, just as it (and most compilers)
rejects invocations of intrinsics with the wrong number (or types)
of arguments.
So, use the EXTERNAL SQRT
statement in a program unit that calls
a user-written subroutine named SQRT
.