Hello all,
this patch does two things:
a) It updates the Fortran 2003 and TR/TS 29113 status in the GNU
Fortran manual.
b) It changes all references to Technical Report 29113 to Technical
Specification 29113
c) It changes -std=f2008tr to -std=f2008ts
(a) is obvious.
Regarding (b): For some reason, ISO's SC22 thinks that one should not
use Technical Reports (TR) but a Technical Specification (TS) for the
Further //Interoperability of Fortran with C document - and later also
for the coarray extensions. Glancing at the documentation, I think
they are right that a TS is better; there are procedural differences,
but for us the main difference is the name. As the final word is TS, I
think gfortran should use TS and not TR throughout for the post-F2008
technical documents.
Cf. ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1879.txt : "JTC 1/SC 22
instructs the JTC 1/SC 22/WG 5 Convenor to submit future drafts of TR
29113, Further Interoperability of Fortran with C as Technical
Specifications"
For the difference between TS and TR, see also
http://www.iso.org/iso/standards_development/processes_and_procedures/deliverables.htm;
for the different approval scheme also the following flow chart
(clickable):
http://www.iso.org/iso/standards_development/it_tools/flowchart_main.htm
Regarding (c): If we switch to TS everywhere, I think it makes sense
to also call the flag -std=f2008ts; the flag stands for: Follow the
standard according to Fortran 2008 with the extensions defined in the
post-F2008 (pre-F2013) standard. Namely, TS 29113 on further
interoperability of Fortran with C and the coarray TS, which is in a
rather early stage. (TS 29113 is already past a PDTS voting and a DTS
should be submitted until June 2012.
Given that -std=f2008tr was never included in a released GCC version
and given that it currently only allows very few features, I think no
one actually uses it. Hence, I decided that one can simply change it
without taking care of still accepting the f2008tr version.
(Currently supported TS 29113 features: OPTIONAL with BIND(C) - absent
arguments are indicated as NULL pointer, matching the internal
implementation. RANK() intrinsic - which is boring without
assumed-rank arrays. ASYNCHRONOUS - well, only the semantic has
changed a bit since F2003/GCC 4.6; however, GCC's middle end uses by
default ASYNCHRONOUS semantic; turning it off is a missed-optimization
bug.)
The patch was build and regtested on x86-64-linux.
OK for the trunk?
Tobias
PS: I will also update the release notes after the patch has been
committed.