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

Re: Mixed entries and 12.5.2.5


Paul Thomas wrote:
> At very least, the message is unhelpful and I will attempt to rework it.
Some other error message for comparison and ideas:

NAG f95: Function CX_CADR has storage-associated ENTRY CX_RADC but is
not of default kind

ifort: The function and entry names do not have consistent data types. 
They do not have to be the same data type, but they must be in the same
data type group.   [CX_RADC]

And less helpful:

g95: ENTRY 'cx_cadr' at (1) cannot be of type TYPE(cx)

gfortran: FUNCTION result r1 can't be of type TYPE(cx) in FUNCTION
cx_cadr at (1)

openf95 and sunf95: The type attributes for entry points "R1" and "R2"
conflict.


> However, it does raise the question as to whether gfortran should
> permit an extension where scalars of other than these default types
> should be allowed.  Lifting the restriction allows the above to
> compile and run correctly.
I think as long as no other compiler supports it, we don't need it;
though I don't mind allowing it for -std=legacy.

By the way, the same text is in Fortran 95, 2003 and in the Fortran 2008
draft.

In Fortran 77 one finds the following which does not seem to have the
default-kind restriction (as there were no TYPE and POINTER there is
obviously no such restriction):

"Within a function subprogram, all variables whose names are also the
names of entries are associated with each other and with the variable,
if any, whose name is also the name of the function subprogram (17.1.3).
Therefore, any such variable that becomes defined causes all associated
variables of the same type to become defined and all associated
variables of different type to become undefined. Such variables are not
required to be of the same type unless the type is character, but the
variable whose name is used to reference the function must be in a
defined state when a RETURN or END statement is executed in the
subprogram. An associated variable of a different type must not become
defined during the execution of the function reference. [...]

If an entry name in a function subprogram is of type character, each
entry name and the name of the function subprogram must be of type
character. If the name of the function subprogram or any entry in the
subprogram has a length of (*) declared, all such entities must have a
length of (*) declared; otherwise, all such entities must have a length
specification of the same integer value."
http://www.fortran.com/fortran/F77_std/rjcnf-15.html#sh-15.7

Tobias


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