This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Fwd: Fortran compilers and 2003 and 2008 standard conformance]


Dear all,

The following was sent to the Fortran-90 mailing list and might interest you. There was a reply asking about the "C" (no reply yet) and mentioning that the command-line reading of gfortran does not work as written in the standard under Windows. Can someone check? Otherwise, we need to wait for the reply to my question.

Tobias

PS: Fortran 90 mailinglist (subscribe/read archive): http://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=COMP-FORTRAN-90

-------- Original Message --------
Subject: 	Fortran compilers and 2003 and 2008 standard conformance
Date: 	Thu, 7 Aug 2008 16:19:51 +0100
From: 	Ian Chivers <ian.chivers@CHIVERSANDBRYAN.CO.UK>
An: 	COMP-FORTRAN-90@JISCMAIL.AC.UK



The following is the basis for an updated table on compiler
support for the 2003 and 2008 standards. We would like comments.
The Fortran 2008 entries are based on a John Reid
article. This is available at the WG5 ftp site

ftp://ftp.nag.co.uk/sc22wg5/N1701-N1750/N1735.pdf

and in the August edition of Fortran Forum.

Jane and I have also had a suggestion from Richard Maine
about additional entries on allocatable scalars
and allocatable character length. I've added his email
at the end. Where would be the best place to add
Richards entries?

when the comment stage is completed well send the
updated document to J3, WG5 and the compiler people.

thanks in advance

ian chivers

"Fortran 2003 and 2008 Features and Compiler Support: Version 1, August 2008"
"Y=Yes, N=No, P=Partial."
	Cray	gfortran	g95	IBM	Intel	NAG	Sun

ISO TR 15580 IEEE Arithmetic	Y	N	P	Y	N	Y	Y
ISO TR 15581 Allocatable Enhancements	Y	Y	Y	Y	Y	Y	Y

Data enhancements and object orientation Cray gfortran g95 IBM Intel NAG Sun

Parameterized derived types	Y	C	N	N	N	N	N
Procedure pointers	Y	N	Y	Y	N	N	N
Finalization	N	N	N	Y	N	N	N
Procedures bound by name to a type	Y	N	N	Y	N	Y	N
The PASS attribute	Y	N	N	Y	N	Y	N
Procedures bound to a type as operators	Y	N	N	Y	N	Y	N
Type extension	Y	N	N	Y	N	Y	N
Overriding a type-bound procedure	Y	N	N	Y	N	Y	N
Enumerations	Y	Y	Y	Y	N	Y	N
ASSOCIATE construct	Y	N	N	Y	N	Y	N
Polymorphic entities	Y	N	N	Y	N	"Y, 1"	N
SELECT TYPE construct	Y	N	N	Y	N	Y	N
Deferred bindings and abstract types	N	N	N	Y	N	Y	N

Miscellaneous enhancements Cray gfortran g95 IBM Intel NAG Sun

Structure constructors	Y	N	Y	Y	N	N	N
The allocate statement	Y	N	P	Y	N	Y	N
Assignment to an allocatable array	"Y, 2"	N	N	Y	"Y, 2"	N	N
Transferring an allocation	Y	Y	N	Y	Y	N	N
More control of access from a module	Y	Y	N	Y	"Y, 6"	Y	N
Renaming operators on the USE statement	Y	P	Y	Y	Y	N	Y
Pointer assignment	Y	N	Y	Y	Y	Y	N
Pointer INTENT	Y	Y	Y	Y	Y	Y	N
The VOLATILE attribute	Y	Y	Y	Y	Y	Y	Y
The IMPORT statement	Y	Y	Y	Y	Y	Y	N
Intrinsic modules	Y	Y	Y	Y	Y	Y	Y
Access to the computing environment	Y	Y	Y	Y	Y	Y	Y
Support for international character sets	N	N	Y	P	N	P	N
Lengths of names and statements	Y	Y	?	Y	Y	Y	Y
"Binary, octal and hex constants"	Y	Y	Y	Y	Y	Y	Y
Array constructor syntax	Y	"P, 4"	Y	Y	N	"P, 4"	N
Specification and initialization expressions	P	P	Y	Y	P	N	N
Complex constants	Y	Y	Y	Y	Y	N	Y
Changes to intrinsic functions	Y	"P, 9"	Y	Y	N	P	N
Controlling IEEE underflow	Y	N	N	Y	N	N 	Y
Another IEEE class value	Y	N	N	Y	N	N	Y

Input/output enhancements Cray gfortran g95 IBM Intel NAG Sun

Derived type input/output	N	N	N	Y	N	N	N
Asynchronous input/output	Y	C	Y	Y	Y	P	Y
FLUSH statement	Y	Y	Y	Y	Y	N	Y
IOMSG= specifier	Y	Y	Y	Y	N	Y	Y
Stream access input/output	Y	Y	Y	Y	Y	Y	Y
ROUND= specifier	Y	N	P	Y	N	N	Y
DECIMAL= specifier	Y	C	Y	Y	N	Y	Y
SIGN= specifier	Y	C	Y	Y	N	Y	Y
Kind type parameters of integer specifiers	Y	N	?	Y	Y	Y	N
Recursive input/output	Y	P	Y	Y	Y	N	Y
Intrinsic function for newline character	Y	Y	Y	Y	Y	Y	N
Input and output of IEEE exceptional values	Y	Y	Y	Y	"Y, 7"	Y	Y
Comma after a P edit descriptor	Y	Y	Y	Y	Y	Y	Y

Interoperability with C Cray gfortran g95 IBM Intel NAG Sun

Interoperability of intrinsic types	Y	Y	Y	Y	Y	Y	Y
Interoperability with C pointers	Y	Y	Y	Y	"Y, 8"	Y	Y
Interoperability of derived types	Y	Y	Y	Y	Y	Y	Y
Interoperability of variables	Y	Y	Y	Y	Y	Y	Y
Interoperability of procedures	Y	Y	Y	Y	Y	Y	Y
Interoperability of global data	Y	Y	Y	Y	Y	Y	Y

Cray gfortran g95 IBM Intel NAG Sun


Notes


1	No unlimited polymorphics
2	Optional under flag
4	No type spec support
6	Protected only
7	All except NaN Hex
8	No procedure pointers
9	"kind= of maxloc, minloc, shape missing"


Fortran 2008 Features


Submodules

Coarrays

Performance enhancements

do concurrent
Contiguous attribute
Simply contiguous arrays

Data enhancements

Maximum rank
Long integers
Allocatable components
Implied-shape array
Pointer initialization
Kind of a forall index
Allocating a polymorphic variable

Accessing data objects

Accessing real and imaginary parts
Pointer functions

Input/Output

Finding a unit when opening a file
g0 edit descriptor
Unlimited format item
Recursive input/output

Execution control

The block construct
Exit statement
Stop code

Intrinsic procedures for bit processsing

Bit sequence comparison
Combined shifting
Counting bits
Masking bits
Shifting bits
Merging bits
Bit transformational functions

Intrinsic procedures and modules

Storage size
Selecting a real kind
Hyperbolic intrinsic functions
Bessel functions
Arc tangent function
Error and gamma functions
Euclidean vector norms
Parity
Execute command line
Location of maximum or minimum value in an array
Find location in an array
Constants
Module procedures

Programs and procedures

Empty contains section
Internal procedure as an actual argument
Generic resolution by pointer or allocatable attribute
Null pointer as a missing dummy argument
Elemental procedures that are not pure
Entry statement becomes obsolescent

Richards email
==============

I just got the latest Fortran Forum and noticed two somewhat related Fortran
2003 features that I personally think are important, but aren't reflected in
your table of features. If convenient, they might be useful to add to the table.


1. Allocatable scalars. To me, this is an important feature for object
orientation, and in particular for polymorphism. Basically, a polymorphic
object has to be either a pointer or an allocatable (or a dummy argument, which
is a bit restrictive). In my experiments with polymorphism, the polymorphic
objects pretty much always naturally "wanted" to be allocatable. But the NAG
compiler (which I was using at the time) didn't yet support allocatable
scalars. This meant that I either needed to make all the polymorphic objects
pointers or make them arrays (possibly of size 1). Neither of these
alternatives was attractive at all. I found this a significant enough
shortcoming to keep me from using the polymorphic features. Thus, I'd think
this would be something people would want to know about a compiler if they
planned to use polymorphism.


2. Allocatable character length. I think that allocatable character length is
one of the biggest "sleeper" features of f2003. It wasn't even on the list of
f2003 requirements, and thus sometimes doesn't show up in lists of new
features. It just naturally arise from allocatable length parameters for
parameterized derived types. It seemed like one should allow the same thing for
the one intrinsic type with a length type parameter. And lo, when it was all
put together, it seemed like this was finally a good way to do variable length
strings in Fortran. It integrates with the rest of the language immensely
better than iso_varying_string has any hope of doing. In fact, as I said, it
integrates so well that it came about as a consequence of the integration of
other features. Allocatable-length character strings act like so many people
intuitively think of character strings, unlike the fixed-length character
strings that we've had since f77.


Although this is related to allocatable scalars, in that you certainly want to
be able to have allocatable character strings that are scalar, it is also a
separate feature in that you can have allocatable scalars without necessarily
allowing character length to be allocatable. It is also different in
application, in that I see the main other usage of allocatable scalars as being
for polymorphism, whereas allocatable character strings are not much related to
polymorphism. It is also useful independent of parameterized derived types. I
personally expect to see allocatable character strings used far more than
parameterized derived types, even though it was the requirement for
parameterized derived types that lead to allocatable character strings. I could
almost see allocatable character strings as becoming the "normal" way that most
character string variables are done.


end of Richards email
=====================










Cheers


Ian



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]