This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Mixed entries and 12.5.2.5
- From: Paul Thomas <paulthomas2 at wanadoo dot fr>
- To: Fortran List <fortran at gcc dot gnu dot org>
- Date: Tue, 31 Jul 2007 15:49:35 +0200
- Subject: Mixed entries and 12.5.2.5
In putting together my story for the patch for pr31609, I wound up
revisiting pr31474. In messing around with the original testcase, I
kept coming across the error
gfc_error ("FUNCTION result %s can't be of type %s "
"in FUNCTION %s at %L", sym->name,
gfc_typename (ts), ns->entries->sym->name,
&sym->declared_at);
else
gfc_error ("ENTRY result %s can't be of type %s "
"in FUNCTION %s at %L", sym->name,
gfc_typename (ts), ns->entries->sym->name,
&sym->declared_at);
when mixing the characteristics of function and entries. Specifically,
this example causes the error:
MODULE complex
TYPE cx
REAL :: real, imag
character(128) :: chr
END TYPE cx
INTERFACE OPERATOR (+)
MODULE PROCEDURE cx_cadr, cx_radc
END INTERFACE
CONTAINS
FUNCTION cx_cadr(z, r) result (r1)
type (cx) :: r1
real :: r2
TYPE (cx), INTENT(IN) :: z
REAL, INTENT(IN) :: r
r1 = cx (z%real + r, 0.0, "Mary had a little lamb")
return
ENTRY cx_radc(r, z) result (r2)
r2 = z%real +r
END FUNCTION cx_cadr
END MODULE complex
use complex
type (cx) :: a = cx (1.0 , 2.0, ""), c
real :: b = 1.0, d
c = a + b
d = b + a
print *, c, d
end
This is a reflection of 12.5.2.5 of the standard:
.......snip................ If the characteristics of the result of the
function named in the ENTRY
statement are the same as the characteristics of the result of the
function named in the FUNCTION
statement, their result variables identify the same variable, although
their names need not be the
same. Otherwise, they are storage associated and shall all be scalars
without the POINTER
attribute and one of the types: default integer, default real, double
precision real, default complex,
or default logical.
At very least, the message is unhelpful and I will attempt to rework
it. Something along the lines that results of mixed entries can only be
default numeric/logical.
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.
What do you think?
Paul