Figure Table/ Note
|Type of com-
|Comment (justification for change by the MB)||Proposed change by the MB||Secretariat Observations
on each comment submitted
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
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,
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||220.127.116.11||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.||"18.104.22.168 of ISO/IEC 9899:1999" should be "22.214.171.124 of ISO/IEC 9899:1999".|
|GB-8||126.96.36.199||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||188.8.131.52||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, 184.108.40.206||Te||Syntax ambiguity concerning data pointers||Details in attached file 09-294.txt|
|JP-3||220.127.116.11||par.1||ed||Editorial correction.||The reference of generic interface, "(4.5.2, 18.104.22.168)", should be "(4.5.5, 22.214.171.124)".|
|JP-4||126.96.36.199||par.2, (2), (b)||ed||Editorial correction.||The reference of generic binding, "(4.5.2)", should be "(4.5.5)".|
|JP-5||188.8.131.52||par.5, (2), (b)||ed||Editorial correction.||The reference of generic binding, "(4.5.2)", should be "(4.5.5)".|
|JP-6||184.108.40.206||par.1||ed||Editorial correction.||The reference of generic interface, "4.5.2, 220.127.116.11.3", should be "4.5.5, 18.104.22.168.3".|
|JP-7||22.214.171.124||par.2, (2), (b)||ed||Editorial correction.||The reference of generic binding, "(4.5.2)", should be "(4.5.5)".|
|GB-10||126.96.36.199||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||188.8.131.52||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||10.11.3.5||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||184.108.40.206.3||par.1, 2nd line||ed||Editorial correction.||The reference of defined assignment, "(220.127.116.11)", should be "(18.104.22.168, 22.214.171.124)".|
|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.
|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
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 126.96.36.199 is incorrect.||Change ’188.8.131.52’ to ’184.108.40.206’.|
|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 "(220.127.116.11-18.104.22.168)" should be "(22.214.171.124, 126.96.36.199)".|
|JP-17||C.6.3||par.10, 3rd line||ed||Editorial correction.||The assignment,
" CH2 = '''THIS STRING HAS QUOTES.''' " should be
" CH2 = '"THIS STRING HAS QUOTES."' ".
(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’.|