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
