Benefits of continuing Fortran standardisation survey: interim results

Benefits of continuing Fortran standardisation survey: interim results

[Paul Richard Thomas]

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

Re: Benefits of continuing Fortran standardisation survey: interim results

[Jorge D'Elia]

----- Mensaje original -----
> De: "Paul Richard Thomas" <paul.richard.thomas@gmail.com>
> Para: "Gfortran List" <fortran@gcc.gnu.org>
> Enviado: Lunes, 17 de Septiembre 2018 10:31:45
> Asunto: Benefits of continuing Fortran standardisation survey: interim results
>
> 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.

Perhaps encourage the users the convenience or need to update 
the compiler version with a short phrase in the commands like 
"gfortran --version", etc., as well as in the manual or on the 
wiki page?

> 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.)

Although the array descriptor ABIs are not compatible, some 
compatibility in the * .mod files would be very welcome, at 
least partially, and thus avoid introducing a lot of extra work.

> "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.)

The anonymous opinion is somewhat unfriendly because it is 
innecesary and it is a statement not technically justified.

> "....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. 

In the case of the Gfortran manual, the "standard" label in each 
intrinsic is very useful to quickly verify in what Fortran 
standard (95, 2003, 2008, etc.) is available.

> 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!)

I would also like a better integration of coarrays in case of 
processing either with shared or distributed memory. Then, a 
little more music for Nicolas and Thomas...


Regards
Jorge.
--

Re: Benefits of continuing Fortran standardisation survey: interim results

[Paul Richard Thomas]

Dear Jorge,

....snip....
>> However, it is clear that the versions being used in the
>> field are lagging far behind trunk.
>
> Perhaps encourage the users the convenience or need to update
> the compiler version with a short phrase in the commands like
> "gfortran --version", etc., as well as in the manual or on the
> wiki page?

The problem, reading between the lines is that many users are in the
hands of system administrators, who do not greatly like straying
outside the confines of the distro.
....snip....
>
> Although the array descriptor ABIs are not compatible, some
> compatibility in the * .mod files would be very welcome, at
> least partially, and thus avoid introducing a lot of extra work.

Unfortunately, I think that it would now take more work to make .mod
files compatible than the ABI.

>
>> "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.)
>
> The anonymous opinion is somewhat unfriendly because it is
> innecesary and it is a statement not technically justified.

Which one - about fortran or brexit? :-)

....snip....
> In the case of the Gfortran manual, the "standard" label in each
> intrinsic is very useful to quickly verify in what Fortran
> standard (95, 2003, 2008, etc.) is available.

You are correct. However, the commentator is correctly pointing out
that the different brands have different bugs for the F20xx features.

....snip....

>> "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!)
>
> I would also like a better integration of coarrays in case of
> processing either with shared or distributed memory. Then, a
> little more music for Nicolas and Thomas...

Estoy de acuerdo!

Paul

Re: Benefits of continuing Fortran standardisation survey: interim results

[Jorge D'Elia]

Dear Paul,

----- Mensaje original -----
> De: "Paul Richard Thomas" <paul.richard.thomas@gmail.com>
> Para: "Jorge D'Elia" <jdelia@cimec.unl.edu.ar>
> CC: "Gfortran List" <fortran@gcc.gnu.org>
> Enviado: Lunes, 17 de Septiembre 2018 18:36:55
> Asunto: Re: Benefits of continuing Fortran standardisation survey: interim results
>
> Dear Jorge,
> 
> ....snip....
>>> However, it is clear that the versions being used in the
>>> field are lagging far behind trunk.
>>
>> Perhaps encourage the users the convenience or need to update
>> the compiler version with a short phrase in the commands like
>> "gfortran --version", etc., as well as in the manual or on the
>> wiki page?
> 
> The problem, reading between the lines is that many users are in the
> hands of system administrators, who do not greatly like straying
> outside the confines of the distro.

Yes, you're right (sometimes we have a similar problem in our clusters). 
Then, a brief note addressed more to the system administrators: (i) in 
order to encourage the installation of the most up-to-date distribution 
possible, and thus to have the most modern gfortran compiler; (ii) that 
gfortran evolves quickly (comparing 4.x to 9.x versions), which suggests 
a more frequent update cycle for gfortran than, for example, gcc/g++ 
(I think, correct if I'm wrong).

> ....snip....
>>
>> Although the array descriptor ABIs are not compatible, some
>> compatibility in the * .mod files would be very welcome, at
>> least partially, and thus avoid introducing a lot of extra work.
> 
> Unfortunately, I think that it would now take more work to 
> make .mod files compatible than the ABI.

Ok, although dreaming does not cost anything...

>>> "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.)
>>
>> The anonymous opinion is somewhat unfriendly because it is
>> innecesary and it is a statement not technically justified.
> 
> Which one - about fortran or brexit? :-)

Well, the brexit affair is a mystery that I can not understand 
from here and much less something to say :-)

> ....snip....
>> In the case of the Gfortran manual, the "standard" label in each
>> intrinsic is very useful to quickly verify in what Fortran
>> standard (95, 2003, 2008, etc.) is available.
> 
> You are correct. However, the commentator is correctly pointing out
> that the different brands have different bugs for the F20xx features.

It is almost inevitable when compilers evolve with the new features.
Computational efficiency, software stability and backwards compatibility 
are important features, although we should also attract new generations 
of programmers, and introduce new ideas (provided they are worthwhile).

> ....snip....
> 
>>> "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!)
>>
>> I would also like a better integration of coarrays in case of
>> processing either with shared or distributed memory. Then, a
>> little more music for Nicolas and Thomas...
> 
> Estoy de acuerdo!

Great!

Regards.
Jorge.
--