Some tests of gfortran

Hi,

as suggested by Tobias on IRC yesterday, I tested a current gfortran
(unpatched, SVN of some days ago) against
ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1764.txt

Below are the reports; I'll await your comments and will open PRs
afterwards where applicable.  Some items could not be tested, as e.g.
user-defined derived-type IO is not yet available.

Yours,
Daniel

*****************************************************************

PROGRAM questionable
   REAL,TARGET :: x
   CALL s1(f(x))
   CALL s2(f(x))
   CALL s3(f(x))
CONTAINS
   FUNCTION f(a)
     REAL,POINTER :: f
     REAL,TARGET :: a
     f => a
   END FUNCTION
   SUBROUTINE s1(variable)
     variable = 42                  ! statement 1
   END SUBROUTINE
   SUBROUTINE s2(variable)
     INTENT(OUT) variable
     variable = 42                  ! statement 2
   END SUBROUTINE
   SUBROUTINE s3(targ)
     REAL,TARGET :: targ
     REAL,POINTER :: p
     p => targ
     PRINT *,ASSOCIATED(p,x)        ! statement 3
   END SUBROUTINE
END

statement 2 is rejected as it should be and statement 3 prints True
which is correct.  statement 1 is however not rejected but should be:

1. The call to s1 is not standard conforming.  5.1.2.7 states
     "If no INTENT attribute is specified for a dummy argument, its use
      is subject to the limitations of the associated actual argument."
    The associated actual argument is the function reference f(x); this
    is an expression, not a variable, and therefore not definable,
    because only variables can be defined (in the sense of being given
    a value, see 2.4.3.1.1 and 2.5.5).

********************************************************************

Is the following C struct:

typedef struct
{
    float x[5];
} array;

interoperable with this Fortran type:

type, bind(c) :: array
    real(c_float) :: x(3)
end type

The answer is No; I was obviously not able to "verify" this for
gfortran, but as it is something not allowed but also something that
could not be diagnosed, I don't see how that could be a problem.

YANI (I hope this isn't already possible and I'm not aware of this):
Make gfortran able to parse C-headers on request and verify the
signatures there are the correct ones; might be interesting, helpful and
maybe not too hard when recycling the existing gcc C-handling?
Something like:

gfortran test.f03 -fverify-bindc=header1.h,header2.h

This would scan header1.h and header2.h for declarations of any BIND(C)
thing in test.f03 and would verify interoperability between those pairs.

**********************************************************************

Given the declarations

   TYPE t
     REAL x
     REAL y(-5:5)
   END TYPE
   TYPE(t) z(10:20)

What is the result of the following LBOUND references:
   LBOUND(z(10)%y)
   LBOUND(z%x)

The confusion arises because the existing definition of LBOUND uses
the undefined term "array structure component" in determining whether
to return the lower bound in the <array-spec> or 1.  It seems clear
that Z(10)%Y must be an array structure component (so the answer ought
to be -5) but it is not clear whether Z%X is one and therefore whether
the result of that LBOUND ought to be 1 or 10.

The results with gfortran are -5 and 10, but according to the
interpretation it should be -5 and 1.

ANSWER:

Yes, the result of the first LBOUND is indeed -5.
The result of the second LBOUND is 1.
Clarifying edits are provided.

The description of the intrinsic function UBOUND suffers from the same
flaw, and the edits provided fix that function as well.

EDITS:

To avoid the undefined term, or any long phrase, the edit changes the
definition of "whole array" to include the case of a whole array
component of a structure.

[107:2-3] Replace the existing definition which is
   "A <<whole array>> is a named array, which may be either a named
   constant (5.1.2.10, 5.2.9) or a variable; no subscript list is
   appended to the name."
with
   "A <<whole array>> is a named array or a structure component whose
    final <part-ref> is an array component name; no subscript list is
   appended."
{Make "whole array" include the whole array component case.}

[107:7-8] Replace "whole array name" with "whole array designator",
           twice.

[326:8] After "a whole array" delete "or array structure component".
{No longer need kludgy wording in LBOUND.}

[358:6-7] After "a whole array" delete "or array structure component".
{No longer need kludgy wording in UBOUND.}

[436:36] After "named array" insert
   "or array component of a structure, with no subscript list."
{Fix the glossary.}

**********************************************************************

The intent was that it would be impossible to reference a deferred
binding.  However, it doesn't appear to me that this intent was achieved.
Consider the following program

   program P
     type, abstract :: T
     contains
       procedure(sub), nopass, deferred :: deferred_proc
     end type T

     call sub

   contains

     subroutine Sub ( X )
       class(t), optional :: X
       call x%deferred_proc
     end subroutine Sub

   end program P

Is this a valid program?  If not, what restriction of the standard does it
violate?

Since x%deferred_proc has the NOPASS attribute, this does not require the
value of x (4.5.7) and thus is not a reference to x (2.5.6).  Therefore,
the first item in the second list in 12.4.1.2 (at [04-007:272:32-33]) does
not prohibit this.

The intention was that this is invalid, as tbp and ppc calls should not
be based on an absent dummy argument (and I guess its similar for NULL
valued pointers?).  While the program as it is above is not yet
supported in gfortran, a changed version that does invoke an ordinary
type-bound procedure on an absent dummy argument does compile fine.  I
guess we can't know at compile-time that this problem is the case, but
maybe that would be another item for runtime-checks?

--
Done:  Arc-Bar-Cav-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran