public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andre Vehreschild <vehre@gmx.de>
To: Jerry D <jvdelisle2@gmail.com>
Cc: Mikael Morin <morin-mikael@orange.fr>,
	Paul Richard Thomas <paul.richard.thomas@gmail.com>,
	GCC-Fortran-ML <fortran@gcc.gnu.org>,
	Thomas Koenig <tkoenig@netcologne.de>,
	Lexi Pimenidis <lexi@badgersystems.de>
Subject: Re: Possible funding of gfortran work
Date: Tue, 30 May 2023 15:32:42 +0200	[thread overview]
Message-ID: <20230530153242.54728d4d@vepi2> (raw)
In-Reply-To: <105c761a-5030-aee5-6587-2783a794f469@gmail.com>

Hi all,

thank you for all your input. I have read the funding requirements and checked
out the application form. We have to agree on a project goal and describe why
it is critical to fund this project.

Let me try a first shot on this:

- Title:

GFortran-Improvement

- Abstract:

Enable the free gfortran compiler to support contemporary language paradigms.

- Dependencies (on the project as well as projects that depend on the
  technology)

Does any one have a convincing project that uses contemporary Fortran? 

Project goal (max 900 words!):

* Complete language intrinsic parallel programming paradigm coarrays. This
  includes completing native coarray support (thread based). As well as
  refactoring of the library based  coarray approach to support coarrays in
  modules. I.e. research on how to support the use of coarrays in modules that
  are not aware of coarrays (not compiled with its support enabled).

* Complete standard compliance from Fortran 2003 onwards. Esp. fixing
  finalization of partially derived types (PDTs) and issues in the associate
  command.

* Ensure maintainability of gfortran by cleaning up/refactoring APIs including
  the scalarizer. Improve the single responsibility pattern's (SRP) use by,
  e.g., ensuring the parser does no longer parts of the resolve stage. The goal
  is not only to separate responsibilities but also to get clearer error
  messages and with that improve user-friendliness.

Why is it critical to fund this project (300 words max)?

Improving the freely available gfortran compiler to support state of the art
parallelism and language paradigms as well as removing bugs and ensuring
standard compliance will allow existing codes to be compiled more reliably.
Furthermore is the lack of support for the newer language paradigms preventing
the use of Fortran in current projects. Developing in contemporary Fortran needs
commercial compilers (that support these paradigms already), which leads to
dependencies on those.

----

This is what I propose for a start. I welcome everyone to participate and make
the goal or the reasoning more elaborate. We may propose the funding request in
English or in German. When no one participates, I am tempted to propose it in
German, as that being my first language, I feel more confident in it.

The company Badger Systems GmbH, Cologne, DE, I am working for will support in
project and bureaucratic management and is willing to act as the proposer of
this funding request. We of course will be profiting from this.

Any input is welcome. Feel free to ask, comment, agree, disagree (only when you
propose something better) or just acknowledge.

Regards,
	Andre

On Sun, 28 May 2023 13:53:04 -0700
Jerry D <jvdelisle2@gmail.com> wrote:

> On 5/28/23 12:25 PM, Mikael Morin wrote:
> > Hello,
> > 
> > I would like to apply for 60% of my work time if there is funding for it.
> > 
> > These are the projects that I would like to push (in no particular order):
> >   - Simplify scalarizer API and usage,
> >   - Create internal APIs (basically split gfortran.h and/or trans.h to 
> > different pieces) and add unit testing for them,
> >   - Move code from class.cc to a trans-class.cc and get rid of the class 
> > artifacts around the class descriptor and vtable in the whole frontend.
> >   - Defer all work done at parsing time to resolution time, so that the 
> > parser's job reduces to just recognizing and recording statements,
> >   - Avoid simplifying intrinsics before checking they are valid,
> >   - Improve module loading (there is PR98426, possibly a few others),
> >   - Array descriptor reform (does it still apply?).
> > 
> > The above are, I think, long and/or difficult, and a bit unrewarding as 
> > they have virtually no user-visible impact, and it's unlikely to get 
> > funding for them.  But maybe we could apply for a package project 
> > including user-visible changes and less visible ones.
> > 
> > The projects proposed by Paul all seem worth pursuing.  If there is only 
> > one, my vote goes for fixing the PDTs.
> > 
> > Cheers.
> > Mikael  
> 
> The original person who contacted me at FortranDiscourse already 
> submitted a proposal for something to do with Fortran-Lang and is 
> offering to assist with a gfortran proposal. I asked for a direct email 
> address so I could relay this to you if you do not have it.  I also gave 
> saveral of your emails to him asking to contact you directly.
> 
> Regards,
> 
> Jerry


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

  reply	other threads:[~2023-05-30 13:32 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-26  4:34 Jerry DeLisle
2023-05-26 17:09 ` Bernhard Reutner-Fischer
2023-05-26 21:22 ` Jerry D
2023-05-27  8:08   ` Thomas Koenig
2023-05-27 11:24     ` Andre Vehreschild
2023-05-27 16:19       ` Paul Richard Thomas
2023-05-28 14:26         ` Nicolas König
2023-05-28 15:07         ` Thomas Koenig
2023-05-28 19:25         ` Mikael Morin
2023-05-28 20:53           ` Jerry D
2023-05-30 13:32             ` Andre Vehreschild [this message]
2023-05-30 20:08               ` Thomas Koenig
2023-05-31  3:46                 ` Benson Muite
2023-05-31  6:08                   ` Thomas Koenig
2023-05-31  8:42                     ` Benson Muite
2023-05-31 12:23                     ` Andre Vehreschild
2023-05-31 14:08                       ` Damian Rouson
2023-06-01  9:18                         ` Andre Vehreschild
2023-06-01 10:56                           ` Bernhard Reutner-Fischer
2023-06-01 10:59                           ` Mikael Morin
2023-06-04  8:23                             ` Thomas Koenig
2023-06-05  8:08                             ` Andre Vehreschild
2023-06-05 11:44                               ` Mikael Morin
2023-06-06 13:06                                 ` Andre Vehreschild
2023-06-08 12:38                                   ` Mikael Morin
2023-06-14  8:28                                     ` Andre Vehreschild
2023-06-14  9:40                                       ` Mikael Morin
2023-06-14 18:48                                         ` Bernhard Reutner-Fischer
2023-06-01 11:12                           ` Benson Muite
2023-06-04  7:49                             ` Thomas Koenig
2023-06-05 10:12                               ` Andre Vehreschild
2023-06-05 10:07                             ` Andre Vehreschild
2023-06-05 12:16                               ` Thomas Koenig
2023-06-05 12:21                                 ` Andre Vehreschild
2023-06-08  5:34                               ` Benson Muite
2023-06-14  8:00                                 ` Andre Vehreschild
2023-06-02  0:53                           ` Jerry D
2023-06-05 10:09                             ` Andre Vehreschild

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=20230530153242.54728d4d@vepi2 \
    --to=vehre@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=jvdelisle2@gmail.com \
    --cc=lexi@badgersystems.de \
    --cc=morin-mikael@orange.fr \
    --cc=paul.richard.thomas@gmail.com \
    --cc=tkoenig@netcologne.de \
    /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).