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]

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


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