public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jorge D'Elia <jdelia@intec.unl.edu.ar>
To: Paul Richard Thomas <paul.richard.thomas@gmail.com>
Cc: Gfortran List <fortran@gcc.gnu.org>
Subject: Re: Benefits of continuing Fortran standardisation survey: interim results
Date: Mon, 17 Sep 2018 23:21:00 -0000	[thread overview]
Message-ID: <473035887.18501.1537227125366.JavaMail.zimbra@intec.unl.edu.ar> (raw)
In-Reply-To: <CAGkQGiJbEoRo_wDvGHOiQEHnDW+opUEuBUxXhXKhSx=Gsb5YQg@mail.gmail.com>

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

      reply	other threads:[~2018-09-17 23:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17 13:31 Paul Richard Thomas
2018-09-17 21:17 ` Jorge D'Elia
2018-09-17 21:37   ` Paul Richard Thomas
2018-09-17 23:21     ` Jorge D'Elia [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=473035887.18501.1537227125366.JavaMail.zimbra@intec.unl.edu.ar \
    --to=jdelia@intec.unl.edu.ar \
    --cc=fortran@gcc.gnu.org \
    --cc=jdelia@cimec.unl.edu.ar \
    --cc=paul.richard.thomas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).