MB Clause No
Subclause No.
Figure Table/ Note
Type of com-
Comment (justification for change by the MB)  Proposed change by the MB Secretariat Observations
on each comment submitted
GB-1 general ge Proposed subset
In its vote on the Fortran 2008 CD the UK noted that, for well known reasons, the current standard had not been fully implemented four years after publication and five years after technical stabilization. Since then it has become apparent that some major suppliers are unlikely to implement all of Fortran 2003 but are planning to incorporate some of the new features from Fortran 2008 according to their customers' requirements.  Thus each provider will in effect be defining its own subset of Fortran 2008.  This negates the principal objective of the standard, viz 'to promote portability, reliability, maintainability, and efficient execution of Fortran programs for use on a variety of computing systems'.

Since full Fortran 2008 compilers are unlikely to be widely available for the foreseeable future while there is certainly user demand for some of the new features, the UK proposes that a subset of Fortran 2008 be defined and standardized.  This standard should define the common subset of what is reliably portable in order to provide a basis for the production of portable programs.  Further, it should exclude some or all of the obsolescent features listed in Annex B.  Where the process of defining it identifies features and restrictions that are historical, unnecessary and impair portability, they should be identified and either proposed as changes for a future revision of the Fortran standard or described in a Technical Report.
There should be a new project to define a compatible subset of the language.
GB-2 general ge Disposition of coarrays in the standard
The comments in this section reflect the majority, but not the unanimous, opinion of the BSI Fortran panel.
We have no objections to the coarray proposals themselves although it appears, given the on-going technical discussions, that they are not yet sufficiently mature to be standardized.

We are however concerned that the coarray model is not sufficiently general for standardization and it is not obvious that it is the best model for Fortran to adopt for the longer term.  We would prefer a more architecture-neutral model so as to allow for future architectural developments.

Moreover it is far from clear that the Fortran programmer who has need of parallel computation facilities would prefer coarrays to more established alternative systems such as MPI.

These points lead to the conclusion that coarrays should be not be in the base language but should be developed separately as an optional feature, either as a Technical Report or as an optional part of the standard.
Coarrays should be developed separately as an optional feature.
GB-3 general te Delete arithmetic IF
The arithmetic IF should be deleted in order to help reduce redundancy in the language.  It was classed as obsolescent in Fortran 90 and in subsequent standards.  The words in 8.2.4,

Execution of an arithmetic IF statement causes evaluation of the numeric expression followed by a branch. The branch target statement identified by the first label, the second label, or the third label is executed next depending on whether the value of the numeric expression is less than zero, equal to zero, or greater than zero, respectively.

are incorrect when the expression has a NaN value since this is not less than zero, not equal to zero and not greater than zero.

If required in a standard-conforming program, the statement can trivially be replaced with an IF-construct, using a preprocessor.
Delete the arithmetic IF statement
GB-4 general ed It is confusing that STOP initiates normal termination but the quite similar ALL STOP initiates error termination.  We suggest replacing ALL STOP by a different, stronger, term namely ABORT ALL.  The term ALL STOP occurs in 12 places in the document in total. Rename the ALL STOP statement.
US-2 Several Several Ed Wordsmithing Details in attached file 09-290r2.txt
US-4 Several Several Ed Wordsmithing Details in attached file 09-300r1.txt
US-5 Several Several Te General scoping fixes Details in attached file 09-302r1.txt
US-6 Several Several Te Scoping unit fixes for BLOCK construct Details in attached file 09-303r2.txt
GB-5 ed There is a duplicate ‘the’ in the text. Change ‘the the’ to ‘the’.
US-1 2.3.5 2-3 Te Contradictions concerning branching and transfer of control Details in attached file 09-289r1.txt
GB-6 2.3.5 4,7 te The current wording overspecifies error termination in paragraph 4 of 2.3.5 (Execution sequence). See section 1 of accompanying UK document.
GB-7 2.4.7 3 ed The use of ‘rectangular pattern’ is unclear; a clarification is proposed. See section 2 of accompanying UK document.
JP-1 2.5.7 Note 2.16 ed Editorial correction. " of ISO/IEC 9899:1999" should be " of ISO/IEC 9899:1999".
GB-8 2 ed The variable names T1, K1, K2, K3 in the commentary should be in lower case as in the example. Change upper case to lower case.
GB-9 8 ed Example years appear to be out of date. Change ‘1994’ to ‘2008’ and ‘1995’ to ‘2009’.
JP-2 5.2.1 C506 ed Editorial correction. "<obsolescent>a statement function,</obsolescent>" should be inserted before "or an automatic object".
US-3 6.2, Te Syntax ambiguity concerning data pointers Details in attached file 09-294.txt
JP-3 par.1 ed Editorial correction. The reference of generic interface, "(4.5.2,", should be "(4.5.5,".
JP-4 par.2, (2), (b) ed Editorial correction. The reference of generic binding, "(4.5.2)", should be "(4.5.5)".
JP-5 par.5, (2), (b) ed Editorial correction. The reference of generic binding, "(4.5.2)", should be "(4.5.5)".
JP-6 par.1 ed Editorial correction. The reference of generic interface, "4.5.2,", should be "4.5.5,".
JP-7 par.2, (2), (b) ed Editorial correction. The reference of generic binding, "(4.5.2)", should be "(4.5.5)".
GB-10 1 ed There is a duplicate ‘the’ in the text. Change ‘the the’ to ‘the’.
CA-01 8.1.4 Te there seems no requirement for WAIT statements before the corresponding END BLOCK statement for asynchronous data transfers to complete.  Either disallow the ASYNC attribute on data in block constructs, or amend the requirement on the wait statement so that it is required before the block ends when asynchronous data transfer has been initiated.
GB-11 8.5.4 4 te The note on SYNC IMAGES is incorrect. See section 3 of accompanying UK document.
GB-12 8.5.4 4 ed The difference between SYNC IMAGES and SYNC ALL should be clarified.  New text is proposed. See section 4 of accompanying UK document.
JP-8 par.6 ed Editorial correction. "the next position after" should be inserted before "the highest-numbered position".
GB-13 9.5.3 1 te Each image has a separate set of units.  Units are not associated with a whole program. Change "a program" to "an image".
JP-9 10.10.4 par.1, 3rd line ed Editorial correction. "comma" of "if the decimal edit mode is comma" should be uppercase like "COMMA".
JP-10 par.1, 3rd item ed Editorial correction. "comma" of "if the decimal edit mode is comma" should be uppercase.
JP-11 11.2.2 Note 11.8 ed Editorial clarification. "The above two constraints" is a little ambiguous and should be changed to
"The constraints C1107 and C1108".
JP-12 par.1, 2nd line ed Editorial correction. The reference of defined assignment, "(", should be "(,".
GB-14 13.5 2 te Execution of certain intrinsic procedures is inadequately specified. See section 5 of accompanying UK document.
CA-04 13.7 Te The behaviour between two images that execute the following intrinsics cannot be guaranteed. COMMAND_ARGUMENT_COUNT,
We'd like to specify that it is processor dependent to the values returned on multiple images using the listed intrinsics
GB-15 13.7.44 3,6 ed Example years to be appear out of date. Change ‘1990’ to ‘2008’ and ‘1985’ to ‘2008’ (three times).
CA-03 13.7.57 Te It is not stated what the behaviour is between 2 images that execute  EXECUTE_COMMAND_LINE concurrently We recommend that this be stated to be processor dependent.
GB-16 13.7.111 6 ed The result in the example is incorrect. Change ‘the value 20’ to ‘the value 4’.
CA-02 13.7.135 Te There is a discussion on random number generator (RANDOM_NUMBER) on multiple images, but is left unstated what the relationship is between cores  We prefer that each image be able to generate random numbers independently, but if this is not possible, there should be a statement that this is processor dependent.
GB-17 13.7.150 7 ed The sample code is incorrect. Change ‘SHIFTA (IBSET (0, BIT_SIZE (0)), 2)’ to ‘SHIFTA (IBSET (0, BIT_SIZE (0) - 1), 2)’.
JP-13 13.7.157 Result Value, 2nd line ed Editorial correction. "MIN" of the exponent part should be lowercase.
GB-18 14.7 1 ed It is not clear in clause 14 that each image has its own floating-point status. Add new note before NOTE 14.6:

NOTE 14.5a
Each image has its own floating-point status (2.3.4)
JP-14 14.7 par.1 ed Editorial correction. "IEEE_GET_UNDERFLOW_MODE" and "IEEE_SET_UNDERFLOW_MODE" are missing.
JP-15 14.11.3 Result Value ed Editorial correction. "the value of X" should be "the absolute value of X".
GB-19 14.11.24 6 ed A space is missing. Add space between '1989' and 'except'.
GB-20 14.11.26 5 ed A space is missing. Add space between '1989' and 'for'.
GB-21 16.3.1 3 ed The cross reference to is incorrect. Change ’’ to ’’.
GB-22 16.6.5 1 item (3) ed The word ‘data’ is usually treated as plural throughout the document. Change ‘data is’ to ‘data are’.
JP-16 16.6.6 (16) ed Editorial correction. The reference "(" should be "(,".
JP-17 C.6.3 par.10, 3rd line ed Editorial correction. The assignment,
" CH2 = '''THIS STRING HAS QUOTES.''' " should be
(Quotation marks should be used.)
GB-23 C.11.1 2 bullet 4 ed The word ‘data’ is usually treated as plural throughout the document. Change ‘data is’ to ‘data are’.