Paul Richard Thomas
2018-09-17 13:31:45 UTC
Anton Shterenlikht, the Standards Officer of the BCS Fortran
Specialist Group, has been carrying out a survey on the benefits of
continuing fortran standardisation. The interim report can be found
here: http://www.fortran.bcs.org/2018/FortranBenefitsSurvey_interimrep_Aug2018.pdf
Concerning gfortran:
________________
On balance, the responses are positive. However, it is clear that the
versions being used in the field are lagging far behind trunk.
Some quite considered remarks point out that bugginess in new features
is shared between nearly all brands but the fact that they don't have
the same bugs makes life difficult for those wanting to use them! (see
the penultimate paragraph below)
Of bugs in features that were mentioned explicitly, deferred character
length comes out on top of the list. Bizarrely, though, more people
claim to use PDTs than deferred character length and yet there are no
complaints about the poor implementation in gfortran (mea culpa)
.
We can probably draw some development priorities from the document. It
is clear, though, that bug fixing is the highest priority, as is
obvious from the number of gfortran PRs.
Most pleasing of all is that it is clear that a good number of
respondents use gfortran.
Some comments that stood out:
___________________________
"As of today the only two things I can think of that will save Fortran
is for Intel to follow NVIDIA/Portland Groups example and release a
community edition (Ie free) version of their compiler and for the
NVIDIA backed flang project to supplant gfortran as the ”open source”
compiler. Just my 2 cents"
"Actually not a benefit, but a real failure in the standardization.
There is no standard for the Fortran modules file format. This is
terrible. One has to compile Fortran libraries with all sorts of
compilers to be able to link them to main code compiled with the
corresponding compilers. The Fortran standards committee should have
adressed this horribly lax policy a long time ago. Long overdue."
(I can only agree. However, the array descriptor ABIs are not
compatible either.)
"Fortran is a dead language and its use should be banned by an act of
Parliament."
(Well, I suppose that it would make a change from brexit.)
"....gfortran (many features supported, but %re and %im missing -
really looking forward to this, lack of progress in PR40196 for over 9
years is very disappointing),..."
(The demand has been deafening, hasn't it?)
"Gfortran 5.4.0, Nagfor 6207, ifort 17.0.5 None of these compilers
supports the full (up to 2008) standard, and it is frustrating using
trial and error to find the subset of useful features that they do all
support. All three claim to support parts of the standard which they
actually don’t. Among other problems, gfortran incorrectly handles
elemental functions on arrays and scalars, e.g. f(array, g(scalar))
fails for any elemental functions f and g;....."
( I agree with the general part of this remark. However, I was unable
to reproduse the problem with elemental functions.)
"gfortran - yes (although it would be nice if coarrays were better
integrated, i.e. not having to use the opencoarray library
explicitly)."
(Music for your ears, Nicolas and Thomas!)
Best regards
Paul
Specialist Group, has been carrying out a survey on the benefits of
continuing fortran standardisation. The interim report can be found
here: http://www.fortran.bcs.org/2018/FortranBenefitsSurvey_interimrep_Aug2018.pdf
Concerning gfortran:
________________
On balance, the responses are positive. However, it is clear that the
versions being used in the field are lagging far behind trunk.
Some quite considered remarks point out that bugginess in new features
is shared between nearly all brands but the fact that they don't have
the same bugs makes life difficult for those wanting to use them! (see
the penultimate paragraph below)
Of bugs in features that were mentioned explicitly, deferred character
length comes out on top of the list. Bizarrely, though, more people
claim to use PDTs than deferred character length and yet there are no
complaints about the poor implementation in gfortran (mea culpa)
.
We can probably draw some development priorities from the document. It
is clear, though, that bug fixing is the highest priority, as is
obvious from the number of gfortran PRs.
Most pleasing of all is that it is clear that a good number of
respondents use gfortran.
Some comments that stood out:
___________________________
"As of today the only two things I can think of that will save Fortran
is for Intel to follow NVIDIA/Portland Groups example and release a
community edition (Ie free) version of their compiler and for the
NVIDIA backed flang project to supplant gfortran as the ”open source”
compiler. Just my 2 cents"
"Actually not a benefit, but a real failure in the standardization.
There is no standard for the Fortran modules file format. This is
terrible. One has to compile Fortran libraries with all sorts of
compilers to be able to link them to main code compiled with the
corresponding compilers. The Fortran standards committee should have
adressed this horribly lax policy a long time ago. Long overdue."
(I can only agree. However, the array descriptor ABIs are not
compatible either.)
"Fortran is a dead language and its use should be banned by an act of
Parliament."
(Well, I suppose that it would make a change from brexit.)
"....gfortran (many features supported, but %re and %im missing -
really looking forward to this, lack of progress in PR40196 for over 9
years is very disappointing),..."
(The demand has been deafening, hasn't it?)
"Gfortran 5.4.0, Nagfor 6207, ifort 17.0.5 None of these compilers
supports the full (up to 2008) standard, and it is frustrating using
trial and error to find the subset of useful features that they do all
support. All three claim to support parts of the standard which they
actually don’t. Among other problems, gfortran incorrectly handles
elemental functions on arrays and scalars, e.g. f(array, g(scalar))
fails for any elemental functions f and g;....."
( I agree with the general part of this remark. However, I was unable
to reproduse the problem with elemental functions.)
"gfortran - yes (although it would be nice if coarrays were better
integrated, i.e. not having to use the opencoarray library
explicitly)."
(Music for your ears, Nicolas and Thomas!)
Best regards
Paul