This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: RFA: Revamp fortran array types
On Aug 18 2009, Tobias Burnus wrote:
Sorry, some niggles here, some of which which may be of consequence for
long-term development.
Well, a programmer should roughly know what is allowed in a language and
should use things which are allowed - (s)he does not need to know all
the fine prints about things which are allowed under very specific
circumstances. Only compiler writers should know.
I wish :-( Sorry but, when you start to use asynchronicity (e.g. MPI
non-blocking) or parallelism (OpenMP, coarrays or whatever) in practical
applications, then the programmers need to be intimately familiar with the
minutiae.
This is good grounds for always keeping an eye open for useful warnings
on potential aliasing mistakes when adding parallelism - our experience
(as an HPC site with a wide range of kit and portable codes) was that it
was VERY useful to compile such a program under several compilers, for
just that reason.
In the end a C and a Fortran program should have the same speed; there
are some minor points which play a large role at different optimization
levels, but at the end, there is no reason that one program should be
magically faster than the other.
Sorry, but that is only because gfortran is based on gcc. Even with full
go-faster stripes (which are almost never used), C99 doesn't do any better
than Fortran 77, overall. My rule of thumb is:
restrict => assumed size arrays
restrict+const => INTENT(IN)
const alone => no effect on optimisation
restrict+static isn't as good as explicit size arrays, because all that it
says is that the array must be at least that size - access over the
syntactic end is almost certainly allowed.
There are no equivalents to the "no escape" rules or INTENT(OUT),
effectively none to the "don't play stupid games with EQUIVALENCE" ones and
the rules on how pointers and targets interact are much less
optimiser-friendly. There's also no equivalent to the ASYNCHRONOUS
attribute, which is very important to some interfaces.
However, if one wants to follow IEEE 754:2008, certain
Fortran-allowed optimizations cannot be done.
That's extremely unclear. Unless they made major changes between the final
public draft and the accepted version, they dropped all of the language
binding stuff - for good reasons, as it was hopeless. And there isn't
anything significant in the Fortran standard about this, even if the
optional exceptions module is being used.
If gfortran has some documentation on precisely what its arithmetic model is
in "IEEE" mode, I should like to see it. I tried reading both IEEE 754R and
Fortran 2003 with a wet towel around my head, and am none the wiser.
Pointer intents were added in Fortran 2003; to quote from the standard
(this time F2003, 4.1.2.7 INTENT attribute):
Not in a way that is terribly useful for optimisation :-(
Regards,
Nick Maclaren.