(j3.2006) (SC22WG5.4798) [ukfortran] Fourth WG5 ballot on interpretations
N.M. Maclaren
nmm1
Tue Sep 25 03:27:53 EDT 2012
Herewith my votes.
Regards,
Nick Maclaren.
Yes No Number Title
--- --- F08/0043 Executing a type-bound procedure on a coindexed
object
-Y- --- F08/0048 Sequence association for coarrays
-Y- --- F08/0054 Requirements for needing an explicit interface
--- --- F08/0055 G editing for reals
--- --- F08/0056 Non-polymorphic ALLOCATE with polymorphic SOURCE=
-Y- --- F08/0057 Interoperability with empty types
-Y- --- F08/0058 ENTRY point RESULT variable
--- --- F08/0059 Auto-targetting requirements
-Y- --- F08/0060 Procedure pointer assignment with an EXTERNAL target
-Y- --- F08/0061 Description of the CONTIGUOUS attribute misworded?
-Y- --- F08/0062 Mixing default initialization with DATA
initialization
-C- --- F08/0063 G editing to a narrow output field
-Y- --- F08/0064 STATUS of GET_ENVIRONMENT_VARIABLE
-C- --- F08/0065 Should certain procedures in intrinsic modules be
pure?
--- --- F08/0066 Are certain expressions with pointer initialization
constant?
--- --- F08/0067 Passing arrays of extended type objects
--- --- F08/0068 Pointer association and extended type arrays
--- --- F08/0069 Which part of an effective argument becomes
undefined?
--- --- F08/0070 Finalization of INTENT(OUT) arguments
-Y- --- F08/0072 Final subroutines with corank
--- --- F08/0073 Polymorphic auto-targetting
Comment on F08/0063
This is a good candidate for improvement in a future revision.
Comment on F08/0065
Upon checking on what this meant, I believe that the lists in tables
14.1 and 14.2 contain some errors. Specifically, I can see no reason
for IEEE_GET_ROUNDING MODE and IEEE_GET_UNDERFLOW MODE not to be pure
(but they aren't), but I can see good reasons for IEEE_SET_FLAG and
IEEE_SET_HALTING_MODE not to be (and they are). However, even if true,
that is a matter for a separate interpretation.
More information about the J3
mailing list