Re: GCC GSoC 2022: Call for project ideas and mentors

[Damian Rouson]

I assume it’s too late for new project ideas.  I’m adding Milan Curcic in
cc to confirm.

Damian

On Wed, Mar 9, 2022 at 18:09 Jerry D via Fortran 
wrote:

> Perhaps someone could work on completing and merging the shared memory
> (native) fortran coarrays branch.
>
> Regards,
>
> Jerry
>
> On 3/9/22 6:39 AM, Martin Jambor wrote:
> > Hello,
> >
> > I am pleased that I can announce that GCC has been accepted as a
> > mentoring organization of Google Summer of Code 2022.
> >
> > Contributors(*) will be applying from April 4th to April 19th but have
> > already seen some announcing their intention to apply and asking for
> > guidance when selecting a project and preparing their applications.
> > Please continue helping them figure stuff out about GCC like you always
> > do.
> >
> > If anyone still wants to add a project to our idea list (and sign up to
> > be a potential mentor), now is the time to do it.
> >
> > I'm looking forward to another year of interesting projects,
> >
> > Martin
> >
> >
> >
> > (*) Contributors no longer have to be students - they should
> > however be "new or beginner" contributors to our project with the
> > exception that participants of GSoC 2020 or GSoC 2021 can apply.
> >
> > More on changes this year is in my original call for projects:
> > https://gcc.gnu.org/pipermail/gcc/2022-January/238006.html
> >
>
>

Re: Where is it?

[Damian Rouson]

https://wg5-fortran.org/N1151-N1200/N1191.pdf


On Fri, May 27, 2022 at 21:19 Scott Mehring via Fortran 
wrote:

> Where is the download link for FORTRAN 95?
>
>
>
>
>
>
>
> Scott A. Mehring
>
> 6604 Carlisle Pike
>
> Mechanicsburg, PA  17050
>
> (717) 379-2404
>
>
>
>

Re: GSoC Blog Post 0 - GCCprefab build system

[Damian Rouson]

On Mon, Jun 13, 2022 at 8:27 AM Jonathan Wakely via Fortran <
fortran@gcc.gnu.org> wrote:

>
> Yes, it does that, but takes 400 lines of shell script to do so.
>
> If you want "relatively easy ways to build GCC painlessly" then you
> can do it with nine lines of shell commands.
>
> Or in about 80, for any non-prehistoric version, with no config file
> needed (just a single option to the script, the release number or
> snapshot name to build):
>
> https://gist.github.com/jwakely/95b3a790157f55d75e18f577e12b50d7#file-build_gcc_versions-sh


Do the above 9 lines or 80 lines include the entire prerequisite software
stack or just the ones that the download_prerequisites script downloads?
If I recall correctly, building gfortran also requires flex and building
flex requires bison and building bison requires m4 and the
download_prerequisites script didn't download any of those the last time I
checked.

I realize that building gfortran from source comes very easily to GCC
developers, especially if they do it regularly.  I've encountered a lot of
people who found it challenging, including myself initially, which was the
reason for incorporating the capability into the OpenCoarrays installer.

Damian

Re: GSoC Blog Post 0 - GCCprefab build system

[Damian Rouson]

On Mon, Jun 13, 2022 at 8:27 AM Jonathan Wakely via Fortran <
fortran@gcc.gnu.org> wrote:

>
> It doesn't include them, but they are standard system packages that
> everybody can install without downloading the sources and building
> them from scratch.


unless the person is on a system on which they are not preinstalled and a
system for which the person doesn’t have the sudo privileges that package
managers often require.  What I’m describing is the norm for a lot of
government employees and even many people at private corporations with
strict security policies.  For what it’s worth, I’ve been assisting someone
who contacted me with this very issue over the past few days.  Building the
entire stack from source is the least painful option for this person.

You still need to have the other prerequisites listed at
> https://gcc.gnu.org/install/prerequisites.html


That is a long and daunting list for a newcomer.  I’ve listened to gfortran
developers describe building gfortran as “easy” for more than a decade
now.  Simply
saying it’s easy doesn’t make it so. I don’t know that I’ve ever met
someone who described the process as easy unless that person was a gfortran
developer.

Damian


>

Re: Finalization

[Damian Rouson]

Thanks for asking this, Jerry!

Sourcery Institute has a (small) amount of funding that can be offered for
this work in case that helps.

Damian

On Wed, Nov 2, 2022 at 6:32 PM Jerry D via Fortran 
wrote:

> Hi Paul,
>
> Long time no chat.  I hope you and yours are well.
>
> I was planning to retire early next year, but with the economy going
> south on us I am going to hold off a bit.  What a crazy world we are in!
>
> I thought I would drop you a note when I noticed a gfortran finalization
> bug 107489.  Then Steve Kargl mentioned the previous patch you had done
> a lot of work on.  I don't remember if that ever went into trunk or was
> pending some interpretation.
>
> I tried to apply the patch I found and of course it is broken here and
> there.  I don't know if you have been keeping it alive or not relative
> to latest trunk.  So, I thought I would ask privately and at the same
> time see how you are doing?
>
> Cheers always Paul,
>
> Jerry
>

Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"

[Damian Rouson]

I wonder if a relatively easy starting point would be enabling the
declaration of do concurrent construct variables:

do concurrent (integer :: i = 1:n)

It’s a minor convenience and less exciting than adding locality specifiers
but possibly a good first exercise.


Damian

On Thu, Feb 23, 2023 at 07:08 Tobias Burnus  wrote:

> Hi,
>
> and welcome to the GCC / gfortran community.
>
> On 23.02.23 14:15, varma datla via Fortran wrote:
> > I am willing to contribute to the project idea "Fortran – DO CONCURRENT".
>
> I hope the following helps a bit – it is admittedly a bit chaotic, but I
> try to write something cleaner later.
>
> But to have something to think of and to startwith, it should be
> sufficient:
>
> I think there are two parts to it: First, to add the changes of newer
> Fortran to gfortran and then to actually use them to generate
> concurrently running code. (Internally, gfortran currently handles 'do
> concurrent' to run mostly like a normal loop – except that it annotates
> the loops are independent. – Real parallelization would be useful,
> however.)
>
> If you want to see examples, see do_concurrent_1.f90 to
> do_concurrent_6.f90 in gfortran's testsuite, i.e.
> gcc/testsuite/gfortran.dg/ in the GCC sources. That's at
>
> https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/testsuite/gfortran.dg;hb=refs/heads/master
> / But it is best to download GCC yourself via Git as described at
> https://gcc.gnu.org/git.html
>
> I want to note that the DO CONCURRENT syntax also permits a mask
> argument, like in 'do concurrent (i=1:5, j=1:5, (i/=j))' where the last
> argument selects a subset.
>
> For the Fortran standard, see https://gcc.gnu.org/wiki/GFortranStandards
>
> Fortran 2018 (= 18-007r1) adds for locality specifiers: LOCAL,
> LOCAL_INIT, SHARED and DEFAULT(NONE).
>
> Fortran 202x alias 2023 adds 'reduce' as in 'do concurrent (i = 1, n)
> reduce(+:a, b, c) reduce(max:d, e, f)'
>
> I think the first step is to add parsing support for those new features,
> i.e. store them, check for issues (diagnostic) and then fail with a
> 'sorry not yet implemented'.
>
> The next step would be to implement LOCAL/LOCAL_INIT for running on the
> host.
>
> And then, finally, would be to translate into code which can then be run
> concurrently. I was thinking of mapping it internally to OpenMP or
> OpenACC, to be toggled via a commandline option like
> -fdo-concurrent=.
>
> * * *
>
> I think the first step would be to download GCC and build it. Something
> like "git clone" as described above, then "mkdir build" (some
> directory); "cd build" and then "../configure --prefix=where-to-install"
> followed by "make -j12" and "make install". The "-j12" runs 12 build
> jobs in parallel. How much to use depends on your system.
>
> You probably need to install some development versions of libraries such
> as ISL, gmp, mpfr and mpc. If you don't have them readily, an option is
> to run ./contrib/download_prerequisites to download those and build them
> automatically alongside GCC.
>
> So far for now. If you have questions, please ask. — And I will try to
> write something more structured later.
>
> Tobias
>
> --
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
> 80634 Münch
> en;
> Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung,
> Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB
> 106955
>
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
> 80634 Münch
> en;
> Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung,
> Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB
> 106955
>

Re: Possible funding of gfortran work

[Damian Rouson]

Thanks for working on this, guys.  I made a few suggestions below.

Damian

On Wed, May 31, 2023 at 5:25 AM Andre Vehreschild via Fortran <
fortran@gcc.gnu.org> wrote:

>
> - Dependencies (on the project as well as projects that depend on the
>   technology; max 300 words)
>
> CP2K https://www.cp2k.org/


Coarray codes:

ICAR: https://github.com/ncar/icar
FEATS: https://github.com/sourceryinstitute/feats
FAVOR*:
https://www.nrc.gov/reading-rm/doc-collections/nuregs/staff/sr1795/index.html

* This is a closed-source project that will feature parallel execution with
coarrays in an upcoming release.

For additional coarray codes, check out these references:

Mozdzynski, G., Hamrud, M., & Wedi, N. (2015) A Partitioned Global Address
Space implementation of the European Centre for Medium Range Weather
Forecasts Integrated Forecasting System. International Journal of High
Performance Computing Applications.

Garain, S., Balsara, D. S., & Reid, J. (2015) Comparing Coarray Fortran
(CAF) with MPI for several structured mesh PDE applications. Journal of
Computational Physics.

Preissl, R., Wichmann, N., Long, B., Shalf, J., Ethier, S., & Koniges, A.
(2011) Multithreaded global address space communication techniques for
gyrokinetic fusion applications on ultra-scale platforms. In Proceedings of
2011 International Conference for High Performance Computing, Networking,
Storage and Analysis (p. 78). ACM.

Other important Fortran codes that don't necessarily use coarrays:

NWChem computational chemistry software
FUN3D computational fluid dynamics software from NASA
MSC NASTRAN structural engineering software from MSC Software
WRF weather forecasting software from NCAR
FAST nuclear fuel performance software from the U.S. Nuclear Regulatory
Commission (NRC)



> - Why is it critical to fund this project (300 words max)?
>
> Fortran remains one of the premier language for science, especially for
> high-performance computing and fields like quantum chemistry or
> computational fluid dynamics.
>

If you want some usage data, I can provide PDF slides, but I don't think
the gfortran mailing list takes attachments so you'll have to contact me
directly.


> gfortran is the default Fortran compiler on many Linux systems, and lack of
> features and bugs in gfortran hinder adoption of more modern, safer and
> more
> efficient language features. The project has been almost entirely
> volunteer-driven so far, but is currently suffering from a lack of active
> developers for larger features. Funding will enable the project to pay some
> gfortran experienced developers to implement some of missing/incomplete
> features, that are too large to tackle for a single volunteer. Payed
> developers
> are to contribute a significant part of the features.
>
> - Target of the projects in the sense of users (max 300 words)
>
> High-performance computing community, esp. but not limited to fluid and
> thermo
> dynamics, wheater forecasting
>

I would mention the worldwide impact of weather and climate models, all of
which are Fortran codes.  I would also mention nuclear energy.  All of the
codes developed by the U.S. Nuclear Regulatory Commission and used for
licensing power plants are Fortran codes. Also aerospace, e.g., FUN3D
developed by NASA and used by SpaceX and several aircraft manufcaturers.
And automotive engineering (mention NASTRAN developed by MSC Software and
used by several automotive companies).


>
> - How was the project funded in the past (max 300 words)
>

If you don't mind mentioning that the foundational work on the front-end
was partly funded by Sourcery Institute with the remainder being the work
of volunteers, that would be appreciated.  Of course, none of the work on
the shared-memory library was funded by Sourcery Institute so maybe the
Sourcery Institute is not relevant.  Your call.


>
> - Project goal (max 900 words!):
>
> * Fortran has a safe and intuitive method for parallel execution,
>   coarrays. There is currently no complete and efficient implementation for
>   multi-core CPUs on a freely available compiler. The goal is to bring
>   the existing, process-based shared memory implementation on a branch
>   into gfortran mainline as a feature for further evaluation and hardening.
>

This is good.  I think I saw an earlier version without the "on a freely
available compiler" text.  This version is accurate.

>
> * GFortran's coarrays for distributed memory lack support for data
> structures
>   provided modules that have not been compiled with coarray support (or are
>   distributed in binary form only). Research and prototypical
> implementation
>   shall be conducted with the goal to find a general and well performing
>   solution. This could become an outstanding feature for a free compiler.
>

Will this work also require working inside OpenCoarrays?  If so, that would
be great and it's probably important to mention OpenCoarrays directly here
because it's separate software with a different license.


>
> * Enhance t

Re: Installing gfortran-14

[Damian Rouson]

It has been a few years since I used Ubuntu. If I recall correctly, I think
you can just use

sudo apt install gcc

and that will install gcc, g++, and gfortran.  My Linux knowledge is
limited.  I never figured out how to install a specific version of GCC on
Ubuntu so I think you just get what you get.  However, what I liked about
Ubuntu was that it seemed to be aggressive about installing more up-to-date
versions of GCC than some other Linux distributions, so if it's an option,
you might get a newer version of GCC by updating your Ubuntu kernel and
then the above apt command again.  I think the latest version is Ubuntu
24.  FWIW, I mostly used the Lubuntu lightweight Ubuntu distribution.

If you really need GCC 14 and the above advice doesn't help, you might try
running the OpenCoarrays installer script to build whatever version you
want from source:

git clone https://github.com/sourceryinstitute/opencoarrays
cd opencoarrays
./install.sh --package gcc --install-version 14 --install-prefix
 --num-threads 4

or run ./install.sh. --help for additional options or shorter versions of
the above options.

I hope this is all helpful.

Damian



On Tue, Aug 20, 2024 at 4:08 PM John Harper  wrote:

> I did this in my Ubuntu 22.04 system with no trouble:
>
> (lf) john:~$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test
>
> but the next step failed:
>
> (lf) john:~$ sudo apt install gfortran-14
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Package gfortran-14 is not available, but is referred to by another
> package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
>
> E: Package 'gfortran-14' has no installation candidate
> (lf) john:~$
>
> What should I have done?
>
> -- John Harper, School of Mathematics and Statistics
> Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
> e-mail john.har...@vuw.ac.nz
>

PR 116468: Segmentation fault at intrinsic assignment to allocatable array component of derived type with kind type parameter

[Damian Rouson]

A program compiled with gfortran terminates with a segmentation fault
at an intrinsic assignment to an allocatable array component of a
derived type with a kind type parameter.  Please see below.  I tried
several workarounds, including replacing the intrinsic assignment with
a type-bound defined assignment, a non-type-bound defined assignment,
and a source allocation.  I also tried compiling code below with
gfortran 12, 13, and 14.  The only workaround that eliminates the
segmentation fault is switching to source allocation.  The code below
terminates normally with the NAG and LLVM Flang (Flang-new) compilers.

% cat reproducer.f90
  implicit none

  type foo_t(k)
integer, kind :: k
real(k), allocatable :: bar(:)
  end type

  type(foo_t(kind(0.))) foo

  foo%bar = [0.]
end

% gfortran reproducer.f90

% ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x102dfad2f
#1  0x102df9d83
#2  0x194afa583
#3  0x1027c7f4b
zsh: segmentation fault  ./a.out

% gfortran --version
GNU Fortran (Homebrew GCC 14.1.0_2) 14.1.0

Re: PRs 88052 and 88190

[Damian Rouson]

On Sat, Sep 7, 2024 at 22:26 Steve Kargl 
wrote:

> On Sat, Sep 07, 2024 at 08:17:42PM -0700, Jerry D wrote:
>
>
> I personally would like to see -std=f2023 made the default.


I would absolutely love that too.  I’ve lost countless hours chasing down
issues (in other compilers) that didn’t make standard behavior the default.



> Any, and all, extensions would require an explicit option to
> accept the non-standard Fortran construct.


This would be awesome.


> Unfortuantely, the -std=gnu ship sailed years ago.


What makes it a closed issue?

D

>

Re: RANDOM_INIT() and coarray Fortran

[Damian Rouson]

Hi Steve,

I hope the gfortran developers won't commit a patch that replaces
existing behavior with a stub that simply emits an error message.  It
has been a while since I looked at the previous emails regarding
problems with the current behavior so I'm not expressing an opinion
about the current behavior.  I'm simply advocating against breaking
existing codes that rely on the current behavior if nothing better is
being provided.

Or as a compromise, would you mind changing the patch so that the
error message is emitted only in the problematic cases? You presented
one problematic case out of the four possible combinations of
RANDOM_INIT() arguments.  With only four possible combinations to
enumerate, I hope this suggestion isn't burdensome.

Regarding "someone who cares about coarray Fortran," finding people to
work on such an effort is quite challenging.  I believe Andre
Verheschild has some limited availability so I'm cc'ing him and will
discuss it with him if he's interested.  If you know others who might
be interested, please let us know.

Damian

On Sat, Apr 3, 2021 at 10:28 AM Steve Kargl via Fortran
 wrote:
>
> What to do about RANDOM_INIT() and coarray Fortran?
>
> The main issue is that if one compiles with -fcoarray=lib
> (or the WIP -fcoarray=shared), then RANDOM_INIT() may
> require communication between images.  Thus, RANDOM_INIT()
> cannot live in libgfortran for at least -fcoarray=lib.
>
> Consider the simple code:
>
> subroutine foo
>call random_init(.true., .false.)
> end subroutine foo
>
> I have updated the patch for
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301
> to use a stub routine for -fcoarray=lib and -fcoarray=shared.
> Anyone, who knows how to use git, is encouraged to commit the patch.
>
> For -fcoarray=none (default option) and -fcoarray=single, the
> patch will cause gfortran to generate
>
> __attribute__((fn spec (". ")))
> void foo ()
> {
>   _gfortran_random_init (1, 0, 0);
> }
>
> _gfortran_random_init() live in libgfortran and it has been updated
> to meet the intended requires of the Fortran standard.
>
> With -fcoarray=lib and -fcoarray=shared, gfortran will now generate
>
> __attribute__((fn spec (". ")))
> void foo ()
> {
>   _gfortran_random_init_foobar (1, 0);
> }
>
> where _gfortran_random_init_foobar() lives in libgfortran.  It prints
> an error message that RANDOM_INIT() is not yet supported for coarray
> Fortran and exits.  Someone, who cares about coarray Fortran, can fix
> -fcoarray=lib and -fcoarray=shared by updating trans-decl.c (see the
> FIXME for random_init()) to emit
>
> __attribute__((fn spec (". ")))
> void foo ()
> {
>   _gfortran_caf_random_init (1, 0);
> }
>
> or
>
> __attribute__((fn spec (". ")))
> void foo ()
> {
>   _gfortran_cas_random_init (1, 0);
> }
>
> --
> Steve

Re: [RFC] Native Coarrays (finally!) [Review part 3]

[Damian Rouson]

The email below seems to be the most recent email on native coarray
support.  Has there been any more recent work or plans for committing a
patch?  Could someone tell me whether the planned feature will work on
Windows without requiring the Windows Subsystem for Linux?  Asking for a
friend. :)

Damian

On Fri, Oct 16, 2020 at 7:38 AM Paul Richard Thomas via Fortran <
fortran@gcc.gnu.org> wrote:

> Hi Andre,
>
> Yes, as Thomas confirms, you are correct about the function of span.
> Unfortunately the originators of gfortran decided on strides in words for
> array descriptors rather than bytes. As far as I am aware, all the other
> vendors use lbound, stride measure and extent, with stride measure in
> bytes. Once committed to this line, allowing the F95 feature of pointers to
> components of derived type arrays necessitated the introduction of span.
> Tobias and I got a long way to do the change over to {lbound, sm, extent}
> in fortran-dev but we both ran out of availability with a long way to go.
> We did this by calculating stride in words from the new array descriptor
> and substituting it everywhere that the stride was needed. This resulted in
> ugly and inefficient repetitions of sm/element_length in array element
> addressing. When I last looked at it everything worked except coarrays,
> which I broke somewhere in libcaf.
>
> Unfortunately, I am still pressed by daytime activities so something on
> this scale is well beyond my capacity. I will be concentrating on
> regressions in the coming weeks.
>
> Nicolas, I haven't responded to your coarrays patch. Well done for this
> impressive bit of work and thanks to Andre for reviewing it. I sincerely
> hope to see it in master, sometime in the next weeks. As has been said
> elsewhere, this should be an important aid to familiarising fortran users
> with coarrays.  Does anybody have access to an AMD Ryzen 32 core machine?
>
> Best regards
>
> Paul
>
>
>
>
> On Fri, 16 Oct 2020 at 10:43, Thomas Koenig  wrote:
>
> > Am 16.10.20 um 10:45 schrieb Andre Vehreschild:
> > > Hi Thomas, hi Nicolas,
> > >
> > > I agree with you, that doing copies of array's data should be avoided,
> > but
> > > please keep in mind, that the gfc_descriptor_t is so to say "public".
> > I.e.,
> > > there are also libraries using it, that are not in the gcc repo and
> those
> > > depend on the descriptor being usable as is.
> >
> > I am quite aware of that.
> >
> > However, what can happen?
> >
> > Since the last ABI revision, we set the span. Old code calling a new
> > library will work anyway because it will do the packing / unpacking.
> > New code calling the old library is something we do not, in general,
> > support (we do add new functions to the library), but it would also work
> > because we set the span anyway.
> >
> > The only thing we cannot handle is new user code (without the temporary)
> > calling old user code (which does not handle the span).  We cannot
> > change that without an ABI upgrade, but upgrading the library will
> > not be affected.
> >
> > > Furthermore, the span-member is not necessarily the size of the data
> > element in
> > > the array, right @Paul?
> >
> > That's the point of using the span.
> >
> > > Assume a structure whose data components need an odd
> > > number of bytes. Putting this structure into an array, the span-member
> > would
> > > hold the padded data size, right?
> >
> > Not the size, the distance.  Fortunately, alignment requirements mean
> > that this will work out OK.
> >
> > > I am not sure about the above, therefore Paul is in copy. This is just
> > like I
> > > have memorized it (may be wrong).
> > >
> > > Anyway, my remark was more the comment not being precise or rather
> > misleading.
> > > I would expect something like "/* store byte-based strides here */".
> > Which
> > > makes it more clear, what will been done.
> >
> > OK :-)
> >
> > Thanks for looking at this!
> >
> > Best regards
> >
> > Thomas
> >
>
>
> --
> "If you can't explain it simply, you don't understand it well enough" -
> Albert Einstein
>

Re: [PATCH 0/5] Fortran manual updates

[Damian Rouson]

On Tue, Nov 2, 2021 at 8:56 AM Sandra Loosemore 
wrote:

>
> ... I will hold off on that if it's going to cause problems.
>
> Thanks for taking on this task, Sandra.  I'm not aware of the technical
issues around mark-up formatting and the transition that's happening, but I
hope nothing holds up a long-needed update to the standards conformance
information.  Those are really important references that I've seen people
rely upon in decision-making that impacts projects.

Damian

Bug 103054 - [f18] Gfortran accepts invalid and rejects valid co_reduce argument keyword name

[Damian Rouson]

In TS 18508, the second summy argument of co_reduce was named
"operator."  In the Fortran 2018 standard, the corresponding argument
has the name "operation."  GFortran accepts the non-standard keyword
argument name "operator" and rejects the standard name "operation."

% cat co_reduce.f90
  implicit none
  logical :: co_all= .true.
  call co_reduce(co_all, operator=both)
  call co_reduce(co_all, operation=both)
contains
  logical pure function both(lhs,rhs)
logical, intent(in) :: lhs, rhs
both = lhs .and. rhs
  end function
end

% gfortran -fcoarray=single co_reduce.f90
co_reduce.f90:4:40:

4 |   call co_reduce(co_all, operation=both)
  |1
Error: Cannot find keyword named 'operation' in call to 'co_reduce' at (1)
% gfortran --version
GNU Fortran (Homebrew GCC 11.2.0) 11.2.0

PR 117434 - [F08] gfortran rejects actual argument corresponding to procedure pointer dummy

[Damian Rouson]

The Fortran 2023 interpretation document clause 15.5.2.10 paragraph 5
allows a dummy argument procedure pointer to have a corresponding
actual argument that is a valid target for the dummy pointer in a
pointer assignment statement.  I believe this feature first appeared
in the 2008 standard. Gfortran rejects this feature, which is used
ubiquitously throughout the test suite for the recently released
Julienne unit testing framework (https://go.lbl.gov/julienne) and thus
is also used ubiquitously in any software that uses Julienne for unit
testing.

% cat gfortran-reproducer.f90

module julienne_test_description_m
  implicit none

  abstract interface
logical function test_function_i()
end function
  end interface

  type test_description_t
procedure(test_function_i), pointer, nopass :: test_function_
  end type

contains

  type(test_description_t) function new_test_description(test_function)
procedure(test_function_i), intent(in), pointer :: test_function
new_test_description%test_function_ => test_function
  end function

end module

  use julienne_test_description_m
  implicit none
  type(test_description_t) test_description

  test_description = new_test_description(test)

contains

  logical function test()
test = .true.
  end function

end

% gfortran gfortran-reproducer.f90

gfortran-reproducer.f90:26:42:

   26 |   test_description = new_test_description(test)
  |  1
Error: Expected a procedure pointer for argument 'test_function' at (1)

% gfortran --version
GNU Fortran (Homebrew GCC 14.2.0) 14.2.0

[15 Regression]: seg fault on accessing an elemental procedure dummy argument's deferred-length character component

[Damian Rouson]

I'm attempting to submit the code below to Bugzilla, but the site
appears to be hanging.  I'll try again later.  Presumably this should
be added to the deferred-length character metabug.  This code executes
without error when compiled with gfortran 14.2.0, but seg faults when
compiled with a recent build of gfortran 15.

Damian

% cat all.f90
  implicit none

  type string_t
character(len=:), allocatable :: string_
  end type

  call check_allocation([foo()])

contains

  type(string_t) function foo()
foo%string_ = "foo"
  end function

  elemental subroutine check_allocation(string)
type(string_t), intent(in) ::  string
if (.not. allocated(string%string_)) error stop "unallocated"
  end subroutine

end

rouson@rouson-m73 julienne % gfortran all.f90

rouson@rouson-m73 julienne % ./a.out
a.out(64876,0x1eeb90f40) malloc: *** error for object 0x60bd8030:
pointer being freed was not allocated
a.out(64876,0x1eeb90f40) malloc: *** set a breakpoint in
malloc_error_break to debug

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x1031a2b63
#1  0x1031a1ae3
#2  0x186d72583
#3  0x186d41c1f
#4  0x186c4ea2f
#5  0x186b5edc3
#6  0x186b6242f
#7  0x186b7c493
#8  0x102b33d57
#9  0x102b33e5b
zsh: abort  ./a.out

rouson@rouson-m73 julienne % gfortran --version
GNU Fortran (GCC) 15.0.1 20250119 (experimental)

Bug 118750 - [14/15 Regression] ICE on associate with elemental function with polymorphic array actual argument

[Damian Rouson]

I just submitted the following as the above PR:

The code below compiles without error with gfortran 12 and 13 but
causes internal compiler errors with gfortran 14.2.0 and 15.

% cat all.f90
  implicit none

  type string_t
  end type

  associate(string_array => get_string([string_t::]))
  end associate

contains

  type(string_t) elemental function get_string(mold)
class(string_t), intent(in) :: mold
get_string = string_t()
  end function

end

% gfortran-14 all.f90
all.f90:6:53:

6 |   associate(string_array => get_string([string_t::]))
  | 1
internal compiler error: Segmentation fault: 11
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

% gfortran all.f90
all.f90:6:53:

6 |   associate(string_array => get_string([string_t::]))
  | 1
internal compiler error: in gfc_get_descriptor_field, at
fortran/trans-array.cc:248
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

% gfortran --version
GNU Fortran (GCC) 15.0.1 20250119 (experimental)

Re: [15 Regression]: seg fault on accessing an elemental procedure dummy argument's deferred-length character component

[Damian Rouson]

This is now PR 118747 and it has been marked as blocking 68241.

D

On Tue, Feb 4, 2025 at 10:10 AM Damian Rouson  wrote:
>
> I'm attempting to submit the code below to Bugzilla, but the site
> appears to be hanging.  I'll try again later.  Presumably this should
> be added to the deferred-length character metabug.  This code executes
> without error when compiled with gfortran 14.2.0, but seg faults when
> compiled with a recent build of gfortran 15.
>
> Damian
>
> % cat all.f90
>   implicit none
>
>   type string_t
> character(len=:), allocatable :: string_
>   end type
>
>   call check_allocation([foo()])
>
> contains
>
>   type(string_t) function foo()
> foo%string_ = "foo"
>   end function
>
>   elemental subroutine check_allocation(string)
> type(string_t), intent(in) ::  string
> if (.not. allocated(string%string_)) error stop "unallocated"
>   end subroutine
>
> end
>
> rouson@rouson-m73 julienne % gfortran all.f90
>
> rouson@rouson-m73 julienne % ./a.out
> a.out(64876,0x1eeb90f40) malloc: *** error for object 0x60bd8030:
> pointer being freed was not allocated
> a.out(64876,0x1eeb90f40) malloc: *** set a breakpoint in
> malloc_error_break to debug
>
> Program received signal SIGABRT: Process abort signal.
>
> Backtrace for this error:
> #0  0x1031a2b63
> #1  0x1031a1ae3
> #2  0x186d72583
> #3  0x186d41c1f
> #4  0x186c4ea2f
> #5  0x186b5edc3
> #6  0x186b6242f
> #7  0x186b7c493
> #8  0x102b33d57
> #9  0x102b33e5b
> zsh: abort  ./a.out
>
> rouson@rouson-m73 julienne % gfortran --version
> GNU Fortran (GCC) 15.0.1 20250119 (experimental)

Re: [Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

[Damian Rouson]

This is a big deal, Andre!   Thanks for working on this patch.  I have some
test code that I can dig up if that’s helpful.  Have you tested with nested
derived type components, i.e., allocatable components that are themselves
derived types that have allocatable components?

The need for this feature in one of my projects is one of two things that
led me to prioritize other compilers at the end of 2023.  At the time, the
other missing feature was automatic parallelization of `do concurrent`,
including automatic GPU offloading.  Then a few months ago, the death blow
that I couldn’t work around was robust support for kind type parameters.

D


Damian

On Fri, Dec 6, 2024 at 10:13 Andre Vehreschild  wrote:

> Hi all,
>
> I had to dive deeply into the issue with handling allocatable components in
> derived types and to find a future proof solution. I hope do have found a
> universal and flexible one now:
>
> For each allocatable (or pointer) component in a derived type a coarray
> token
> is required. While this is quite easy for the current compilation unit, it
> is
> very difficult to do for arbitrary compilation units or when one gets
> libraries
> that are not aware of coarray's needs. The approach this patch now
> implements
> is to delegate the evaluation of a reference into a coarray into a separate
> access routine. This routine is present on every image, because it is
> generated
> by the compiler at the time it knows that a coarray access is done. With
> external compilation units or libraries this solves the access issue,
> because
> each image knows how to access its own objects, but does not need a coarray
> token for allocatable (or pointer) components anymore. The access on the
> remote
> image's object is done by the remote image itself (for the MPI
> implementation in
> a separate thread). Therefore it knows about the bounds of arrays,
> allocation
> and association state of components and can handle those.
>
> Furthermore is this approach faster, because it has O(1) complexity
> regarding
> the communication. The old approach was O(N) where N is the number of
> allocatable/pointer components + array descriptors on the path of the
> access.
> The new approach sends a set of parameters to the remote image and gets the
> desired data in return.
>
> At the moment the patch handles only getting of data from a remote image.
> It is
> split into two patchsets. The first one does some preparatory clean up,
> like
> stopping to add caf_get calls into the expression tree and removing them
> afterwards again, where they are in the way.
>
> The second patch is then doing the access routine creation. Unfortunately
> is
> this the longer patch. I have also updated the documentation of the caf
> API. I
> hope to not have overlooked something.
>
> This is the first part of a series to rework all coarray access routines
> to use
> the new approach and then remove the deprecated calls. This makes things
> clearer and easier to maintain, although the tree-dump now presents some
> more
> generated routines, which might look odd.
>
> Bootstrapped and regtested ok on x86_64-pc-linux-gnu / Fedora 39 and 41.
> Ok for
> mainline?
>
> I will continue working on the coarray stuff and fix upcoming bugs in the
> future.
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>

Re: [Fortran, Patch, PR57598] Fix coarray STOP

[Damian Rouson]

I don’t think the standard requires providing the stop code to the OS, but
it recommends doing so.  So this is a great idea.  Thanks for working on
coarray features.

Damian

On Thu, Dec 19, 2024 at 04:14 Andre Vehreschild  wrote:

> Hi all,
>
> attached patch fixes a rather old open issue, that I stumbled upon
> while trying to figure, why a test failed on the command line but not
> in the testsuite. The implementation of the STOP command in caf_single
> did not hand the errorcode over to the OS, as does non-caf STOP and as
> it is required by the standard. So I fixed that. I also added reporting
> of exceptions to the coarray (ERROR)? STOP routines. For this I have
> exported the existing function of the regular gfortran runtime library.
> I tried to do this via iexport_proto, but was never able to access the
> routine from the caf-library. I always got linker errors.
>
> After fixing caf-STOP the testsuite reported one regression, which I
> also fixed in send_by_ref.
>
> Bootstrapped and regtests ok on x86_64-pc-linux-gnu / F41. Ok for
> mainline?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gcc dot gnu dot org
>

Re: [Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

[Damian Rouson]

On Tue, Dec 17, 2024 at 20:05 Steve Kargl 
wrote:

> On Mon, Dec 16, 2024 at 04:53:42AM -0800,
Or, perhaps, you care to qualify your generalization?

Thanks for asking.  When I tried using kind type parameters on derived
types with gfortran a few months ago, I gave up because the issues appeared
to be so fundamental that I couldn’t even find workarounds that would allow
me to use the feature at all while awaiting patches.  I corresponded with
Paul, who did the initial implementation of parameterized derives.  I hope
Paul is ok with me quoting his description of the overall situation about 2
months ago.  Paul’s assessment is below.  Also,  I believe Andre is
planning to work on PDT support sometime next year.

Damian


— snip —

The most significant change that is required comes about from PR82649.
While kludges exist, the best approach is to completely change the PDT
representation,
which is generated in decl.cc(gfc_get_pdt_instance). My plan was to
represent a PDT instance by a container:

type(pdt_instance)
   type(pdt_data), dimension(gfc_max_dimensions), pointer :: data
   integer, kind :: param1
...
  integer, len :: paramN
...
end type

Of course, this change will result in a huge amount of downstream fallout
in resolve.cc and trans*.cc. Grepping "attr.pdt" will reveal the affected
files.

The present representation for *each element* is:
type(pdt_instance)
   integer, kind :: param1
...
  integer, len :: paramN
...
  data_components
end type

A possible alternative approach would be to add a "hidden" field,
_allocated and to leave a single element with the parameter fields
retaining their values after deallocation.

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

[Damian Rouson]

The first error message in my previous email led me to the following
constraint:

“*C1130*  A *variable-name *that appears in a LOCAL or LOCAL_INIT
*locality-spec *shall not have the ALLOCATABLE, INTENT (IN), or OPTIONAL
attribute, shall not be of finalizable type, shall not have an allocatable
ultimate component,...”

My first thought was, "Holy guacamole. That seems like such
a severe limitation that the feature seems almost useless."  Fortuitously,
however, it turns out that the code I sent a little while ago was missing
one important feature from my intended use case: associate.  As shown
below, using associate eliminates the first error, but I'm still confused
by the remaining error message.  Are locality specifiers actually supported
yet?

Damian

% cat locality.f90

program main

  implicit none

  integer pair

  integer :: mini_batch_size=1


  real, allocatable, dimension(:,:) :: a, dcdb



  allocate(a(1,1))

  allocate(dcdb(1,1))


  associate(a_ => a, dcdb_ => dcdb)

do concurrent (pair = 1:mini_batch_size) local(a_) reduce(+: dcdb_)

  a_ = 0.

  dcdb_ = 0.

end do

  end associate


end program


% gfortran locality.f90

*locality.f90:12:71:*


   12 | do concurrent (pair = 1:mini_batch_size) local(a_) reduce(+:
dcdb_)

  |
  *1*

*Error:* Sorry, LOCAL and LOCAL_INIT are not yet supported for ‘*do
concurrent*’ constructs at *(1)*


% gfortran --version

GNU Fortran (GCC) 15.0.1 20250119 (experimental)

Copyright (C) 2025 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

[Damian Rouson]

I recently built the master branch of Iain's fork of gcc in order to test
the support for locality specifiers.   I have verified that the branch I
built contains the commit mentioned in this email thread
20b8500cfa522ebe0fcf756d5b32816da7f904dd.  The code below isn't designed to
do anything useful -- just to make sure the syntax works. Could someone
tell me why the second error message indicates that LOCAL is not supported
yet?  Also, the first error message is really interesting because if I'm
really not allowed to have anything allocatable inside LOCAL(), then I'm
going to have to go back to the drawing board regarding my intended use
case.  Any advice?

Damian

% cat locality.f90

program main

  implicit none

  integer pair

  integer :: mini_batch_size=1


  real, allocatable, dimension(:,:) :: a, dcdb



  allocate(a(1,1))

  allocate(dcdb(1,1))


  do concurrent (pair = 1:mini_batch_size) local(a) reduce(+: dcdb)

a = 0.

dcdb = 0.

  end do


end program


% gfortran locality.f90

*locality.f90:8:50:*


8 |   do concurrent (pair = 1:mini_batch_size) local(a) reduce(+: dcdb)

  |  *1*

*Error:* ALLOCATABLE attribute not permitted for ‘*a*’ in LOCAL
locality-spec at *(1)*

*locality.f90:8:67:*


8 |   do concurrent (pair = 1:mini_batch_size) local(a) reduce(+: dcdb)

  |
*1*

*Error:* Sorry, LOCAL and LOCAL_INIT are not yet supported for ‘*do
concurrent*’ constructs at *(1)*


gfortran --version

GNU Fortran (GCC) 15.0.1 20250119 (experimental)

Copyright (C) 2025 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.




On Mon, Jan 13, 2025 at 5:41 PM Jerry D  wrote:

> Committed as:
>
> commit 20b8500cfa522ebe0fcf756d5b32816da7f904dd (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Anuj Mohite 
> Date:   Mon Jan 13 16:28:57 2025 -0800
>
>  Fortran: Add LOCALITY support for DO_CONCURRENT
>
>  This patch provided by Anuj Mohite as part of the GSoC
> project.
>  It is modified slightly by Jerry DeLisle for minor formatting.
>  The patch provides front-end parsing of the LOCALITY specs in
>  DO_CONCURRENT and adds numerous test cases.
>
>  gcc/fortran/ChangeLog:
>
>  * dump-parse-tree.cc (show_code_node):  Updated to use
>  c->ext.concur.forall_iterator instead of
> c->ext.forall_iterator.
>  * frontend-passes.cc (index_interchange): Updated to
>  use c->ext.concur.forall_iterator instead of
> c->ext.forall_iterator.
>  (gfc_code_walker): Likewise.
>  * gfortran.h (enum locality_type): Added new enum for
> locality types
>  in DO CONCURRENT constructs.
>  * match.cc (match_simple_forall): Updated to use
>  new_st.ext.concur.forall_iterator instead of
> new_st.ext.forall_iterator.
>  (gfc_match_forall): Likewise.
>  (gfc_match_do):  Implemented support for matching DO
> CONCURRENT locality
>  specifiers (LOCAL, LOCAL_INIT, SHARED, DEFAULT(NONE), and
> REDUCE).
>  * parse.cc (parse_do_block): Updated to use
>  new_st.ext.concur.forall_iterator instead of
> new_st.ext.forall_iterator.
>  * resolve.cc (struct check_default_none_data): Added struct
>  check_default_none_data.
>  (do_concur_locality_specs_f2023): New function to check
> compliance
>  with F2023's C1133 constraint for DO CONCURRENT.
>  (check_default_none_expr): New function to check DEFAULT(NONE)
>  compliance.
>  (resolve_locality_spec): New function to resolve locality
> specs.
>  (gfc_count_forall_iterators): Updated to use
>  code->ext.concur.forall_iterator.
>  (gfc_resolve_forall): Updated to use
> code->ext.concur.forall_iterator.
>  * st.cc (gfc_free_statement): Updated to free locality
> specifications
>  and use p->ext.concur.forall_iterator.
>  * trans-stmt.cc (gfc_trans_forall_1): Updated to use
>  code->ext.concur.forall_iterator.
>
>  gcc/testsuite/ChangeLog:
>
>  * gfortran.dg/do_concurrent_10.f90: New test.
>  * gfortran.dg/do_concurrent_8_f2018.f90: New test.
>  * gfortran.dg/do_concurrent_8_f2023.f90: New test.
>  * gfortran.dg/do_concurrent_9.f90: New test.
>  * gfortran.dg/do_concurrent_all_clauses.f90: New test.
>  * gfortran.dg/do_concurrent_basic.f90: New test.
>  * gfortran.dg/do_concurrent_constraints.f90: New test.
>  * gfortran.dg/do_concurrent_local_init.f90: New test.
>  * gfortran.dg/do_concurrent_locality_specs.f90: New test.
>  * gfortran.dg/do_concurrent_multiple_reduce.f90: New test.
>  

Re: DO CONCURRENT with LOCAL / LOCAL_INIT [was: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)]

[Damian Rouson]

In case it would help to see another open-source implementation, there
exists a public branch of LLVM that parallelizes DO CONCURRENT using
OpenMP.  The LLVM fork and git tag that I’ve used since November is cited
in the “CPU Parallelism on Perlmutter” slide at
http://go.lbl.gov/just-write-fortran. The compiler work has progressed
since then.  I can hunt down a more up-to-date branch if anyone is
interested.

Damian


On Sun, Jan 26, 2025 at 02:10 Tobias Burnus  wrote:

> Hi,
>
> John Campbell wrote:
> > Would it be easier to consider "DO CONCURRENT with LOCAL / LOCAL_INIT"
> as a special case of !$OMP PARALLEL DO, so utilise this existing
> implementation ?
>
> I think I want to handle by default a bare 'do concurrent' with a code
> separate from OpenMP, but using the normal code.
>
> I am also not completely sure whether the semantic is exactly the same –
> and whether there are issues with the current OpenMP implementation; I
> would assume there are some with 'private' as there are with LOCAL when
> using default-values in derived types.
>
> Note that I also did not see real obstacles yesterday but it requires
> another couple of hours of work (it took so far 5h, ignoring the work
> for what's in already). The future work would be either continuing with
> the current approach or calling the existing OpenMP copy and
> default-init functions (see PR for the function names), which still
> would reuse parts of the current patch.
>
> It also requires more *testcases* for do concurrent to check that
> everything is handled correctly; as the existing testcases (see patch)
> show, simple code works – but trying hard enough, one finds things that
> don't.
>
> [Converting the current/new testcases to OpenMP wouldn't harm, either.
> I'd assume that some cases are mishandled there as well, esp. derived
> types with default values.]
>
>
> Regarding the semantic: I think OpenMP permits more – at least for
> 'firstprivate', like polymorphic variables and allocatable components. –
> For 'private', a lot of details are unspecified. – Fortran is more
> restrictive but/hence has fewer unspecified parts. However, my feeling
> is that the difference is more on the constraint-checking side in the
> compiler and less on the actual implementation.
>
> (That polymorphic variables are supported in OpenMP's firstprivate was
> rather underspecified until OpenMP 6.0; it is now permitted (except on
> 'target'). GCC should handle it already correctly since GCC 13 (?).)
>
> * * *
>
> Regarding moving to real parallelization (out of scope for the current
> patch): For 'do concurrent', I don't think that it should
> unconditionally linke the OpenMP runtime library and turn every
> do-concurrent loop into something that consumes all available threads of
> the system.
>
> Thus, I was thinking in the past of providing -fdo-concurrent=… as flag
> to decide how to handle it, i.e. use no thread parallization, use
> OpenMP's, or … — The question is only the exact option, default, and
> semantic.
>
> BTW: OpenMP before 6.0 did not permit any OpenMP directive on 'do
> concurrent'. However, with OpenMP 6.0, '!$omp loop' is permitted, which
> makes it possible to say per loop whether thread parallization should be
> done or not.
>
> * * *
>
> I think permitting '!$omp loop' on do-concurrent will likely be a GCC 16
> item, while non thread-parallelizing do-concurrent should really still
> become a GCC 15 feature! I think we also think about -fdo-concurrent=…
> for GCC 16.
>
> Tobias
>
>

Re: DO CONCURRENT with LOCAL / LOCAL_INIT [was: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)]

[Damian Rouson]

In case it helps anyone to see how significant the reduction in
complexity can be with support for locality specifiers, we have
Fortran 2008, 2018, and 2023 versions of the "do concurrent" construct
that lies at the heart of our neural-network training code here:

https://github.com/BerkeleyLab/fiats/blob/25457d8e390f59f3191d6fcd0d5a609f173059d6/src/fiats/neural_network_s.F90#L899

The 2023 version has one do concurrent statement that we expand into 7
statements if we have to fall back to 2018 (including the "end block"
that is much lower in the code) without reduce locality and expands to
10 statements if we have to fall all the way back to 2008 without
local or reduce.  Although there's a minor win associated with
supporting local, there's a much bigger reduction in code complexity
that comes with supporting both local and reduce.

Damian

Re: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran DO CONCURRENT Auto-Parallelization

[Damian Rouson]

If this moves forward, I’d like to offer example code to target in Fiats (
https://go.lbl.gov/fiats).  I presented automatic parallelization results
produced by compiling with LLVM flang-new for inference at the PAW-ATM
workshop at SC24 (see https://go.lbl.gov/just-write-fortran). It would be
great to have a similar capability with gfortran.  And I would be
especially excited if Fortran 2023 reduce locality is supported. In our
training algorithm, the use of reduce locality reduces one block of code
from around 10 statements to one statement.

Damian

On Mon, Mar 10, 2025 at 04:19 Thomas Koenig  wrote:

> Dear Chenlu,
>
> Thank you for your interest!
>
> I have forwarded your e-mail to the gfortran mailing list, where
> discussion of gfortran takes place.
>
> Best regards
>
> Thomas
>
>
>  Weitergeleitete Nachricht 
> Betreff: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran
> DO CONCURRENT Auto-Parallelization
> Datum: Mon, 10 Mar 2025 15:43:52 +1100
> Von: Zhang lv via Gcc 
> Antwort an: Zhang lv 
> An: g...@gcc.gnu.org
>
> Hi here,
>
> I'm a Master of Computer Science student at the University of Melbourne.
> Previously, I worked on implementing a GCC optimization prefetching pass
> (which involved loop unrolling) for an Alpha-like computer architecture.
> I'm set to complete my research project in July and graduate soon.
>
> I'm very interested in applying for the 2025 GSoC project and discussing
> potential ideas with the community. However, I'm still unfamiliar with the
> best way to engage in these discussions and apply for the project, so this
> is my first attempt at reaching out.
>
> My primary interest is in projects related to auto-parallelization,
> particularly the Fortran *DO CONCURRENT* project. Below, I outline my
> initial understanding of the project and would appreciate any feedback from
> the community to ensure I'm on the right track:
>
> 1. The *front-end parser* processes the Fortran *DO CONCURRENT* syntax
> and converts it into a language-independent IR—*GIMPLE*.
> 2. The *middle-end* then applies tree optimizations, utilizing SSA
> passes to optimize the code for auto-parallelization.
> 3. This project will involve both *front-end* work (parser and
> parameterized command-line flags) and *middle-end* optimizations
> (optimization passes).
>
> Loop unrolling is influenced by multiple factors, such as loop nesting and
> whether iteration counts are deterministic. A significant performance gain
> comes from reducing array memory access delays, which techniques like
> prefetching can help with. Since *DO CONCURRENT* assumes iteration
> independence, we have more flexibility to unroll loops and implement
> parallelization efficiently.
>
> One of the most exciting advantages of this project is that it enables
> auto-parallelization for a broader range of code without requiring
> developers to be an OpenMP expert. *DO CONCURRENT* in Fortran is much
> easier to use, and previous auto-parallelization techniques have been quite
> limited in their applicability, as only specific loop structures could
> benefit from them.
>
> I look forward to engaging with the community and gaining insights on how
> best to contribute to this project.
>
> Best regards,
>
> Chenlu Zhang
>

Re: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran DO CONCURRENT Auto-Parallelization

[Damian Rouson]

Jerry,

See
https://github.com/BerkeleyLab/fiats/blob/c256784fbd3eb28053daad657fc01c3caaf562d4/src/fiats/neural_network_s.F90#L871.
The F2023_LOCALITY macro switches on the use of reduce locality.  The
F2018_LOCALITY macro uses only locality specifiers that were in Fortran
2018.  The F2008_LOCALITY macro switches to default locality. In this code,
the biggest savings comes from reduce locality.

Damian

On Mon, Mar 10, 2025 at 10:20 Jerry D  wrote:

> On 3/10/25 4:29 AM, Damian Rouson wrote:
> > If this moves forward, I’d like to offer example code to target in Fiats
> > (https://go.lbl.gov/fiats <https://go.lbl.gov/fiats>).  I presented
> > automatic parallelization results produced by compiling with LLVM flang-
> > new for inference at the PAW-ATM workshop at SC24 (see https://
> > go.lbl.gov/just-write-fortran <https://go.lbl.gov/just-write-fortran>).
> > It would be great to have a similar capability with gfortran.  And I
> > would be especially excited if Fortran 2023 reduce locality is
> > supported. In our training algorithm, the use of reduce locality reduces
> > one block of code from around 10 statements to one statement.
> >
> > Damian
> >
> Damian,
>
> Can you send an example of that one block of code as an example. You may
> have already done so, I have lost track in between some other burning
> issues.
>
> Regards,
>
> Jerry
>

Bug 119349 [15 Regression] polymorphic array dummy argument with function result actual argument in elemental function

[Damian Rouson]

With gfortran 12.4.0, 13.3.0, and 14.2.0, the program below prints
"T".   With gfortran 15, the program crashes with an error message
that indicates that a pointer is being freed that was not allocated.

% cat all.f90
  implicit none

  type string_t
character(len=:), allocatable :: string_
  end type

  print *, true([string()])

contains

  type(string_t) function string()
string%string_ = ""
  end function

  logical elemental function true(rhs)
class(string_t), intent(in) :: rhs
true = .true.
  end function

end

% gfortran all.f90
% ./a.out

a.out(28435,0x209bdc840) malloc: *** error for object 0x62f98060:
pointer being freed was not allocated
a.out(28435,0x209bdc840) malloc: *** set a breakpoint in
malloc_error_break to debug

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x1028d2563
#1  0x1028d14e3
#2  0x1a02a2de3
#3  0x1a026bf6f
#4  0x1a0178907
#5  0x1a0081e37
#6  0x1a00859bb
#7  0x1a00a4143
#8  0x102583bdf
#9  0x102583daf
zsh: abort  ./a.out

% gfortran --version
GNU Fortran (GCC) 15.0.1 20250315 (experimental)

Bug 119380 - [12,13,14,15] Associate malloc error on selector with allocatable and procedure pointer

[Damian Rouson]

An associate construct causes the alloc error "pointer being freed was
not allocated" when the selector is a structure constructor for a
derived type with an allocatable component and a procedure pointer
component.  This same error occurs if a function returning the same
type replaces the structure constructor. The same error occurs for
programs compiled with gfortran 12.4.0, 13.3.0, 14.2.0, and 15.0.1:

% cat all.f90
  implicit none

  type foo_t
integer, allocatable :: i_
procedure(f), pointer, nopass :: f_
  end type

  associate(foo => foo_t(1,f))
  end associate

contains

  function f()
logical, allocatable :: f
f = .true.
  end function

end

% gfortran all.f90
% ./a.out
a.out(99502,0x1ed7e4840) malloc: *** error for object 0x2:
pointer being freed was not allocated
a.out(99502,0x1ed7e4840) malloc: *** set a breakpoint in
malloc_error_break to debug

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x100e7a563
#1  0x100e794e3
#2  0x183eaade3
#3  0x183e73f6f
#4  0x183d80907
#5  0x183c89e37
#6  0x183c8d9bb
#7  0x183cac143
#8  0x100acfa43
#9  0x100acfabf
zsh: abort  ./a.out

% gfortran --version
GNU Fortran (GCC) 15.0.1 20250315 (experimental)

Source allocation of pure function result rejected

[Damian Rouson]

gfortran 12, 13, 14, and 15 all reject the source allocation of a pure
function result object's allocatable component with the message "Bad
allocate-object at (1) for a PURE procedure".  Removing "pure"
eliminates the error.  Alternatively, removing the separate procedure
interface also eliminates the error.  Eliminating the explicit
"result" clause generates a different error shown below.

% cat source-allocate-pure-function-result-component.f90
module test_m
  implicit none

  type test_t
integer, allocatable :: i
  end type

  interface
pure module function construct_test() result(test)
  implicit none
  type(test_t) test
end function
  end interface

contains
  module procedure construct_test
allocate(test%i, source = 0)
  end procedure
end module

% gfortran -c source-allocate-pure-function-result-component.f90
source-allocate-pure-function-result.f90:17:20:

   17 | allocate(test%i, source = 0)
  |1
Error: Bad allocate-object at (1) for a PURE procedure


% gfortran --version
GNU Fortran (GCC) 15.0.1 20250412 (experimental)

If the separate "result" clause is eliminated and the procedure name
is therefore the result name ("test"), then the error message changes
to

   17 | allocate(test%i, source = 0)
  |  1
Error: ‘test’ at (1) is not a variable

Bug 104404 - Incorrect CFI_cdesc_t "type" member for assumed-type, assumed-rank complex dummy arguments

[Damian Rouson via Fortran]

For an assumed-type, assumed-rank complex dummy argument in a C interface,
gfortran 11.2.0 passes a CFI_cdesc_t object with a "type" member that does
not match the corresponding CFI_type_float_Complex and
CFI_type_double_Complex values. In the case of a complex(c_float_complex)
argument, the passed "type" member corresponds to CFI_type_double_Complex.
For a complex(c_double_complex) argument, the "type" member has a value
that I don't recognize.  Does anyone know whether this has been fixed on
the 12 branch?

% cat c_descriptor.c
#include 
#include 

void c_descriptor(CFI_cdesc_t* c)
{
  printf("a_desc->type = %d \n", c->type);
  printf("a_desc->elem_len = %d \n", c->elem_len);
  printf("CFI_type_float_Complex = %d \n", CFI_type_float_Complex);
  printf("CFI_type_double_Complex = %d \n", CFI_type_double_Complex);
}

% cat c_descriptor.c
#include 
#include 

void c_descriptor(CFI_cdesc_t* c)
{
  printf("a_desc->type = %d \n", c->type);
  printf("a_desc->elem_len = %d \n", c->elem_len);
  printf("CFI_type_float_Complex = %d \n", CFI_type_float_Complex);
  printf("CFI_type_double_Complex = %d \n", CFI_type_double_Complex);
}
(base) rouson@CLaSS adhoc % cat assumed-type.f90
module c_descriptor_m
  implicit none
contains
  module subroutine print_type_info(a)
type(*), intent(inout), contiguous, target :: a(..)

interface
  subroutine c_descriptor(a) bind(C)
implicit none
type(*) a(..)
  end subroutine
end interface

call c_descriptor(a)

  end subroutine
end module

  use c_descriptor_m
  use iso_c_binding
  implicit none

  complex(c_float_complex) :: z_float = (0._c_float, 0._c_float)
  complex(c_double_complex):: z_double = (0._c_double, 0._c_double)

  print*, "-  complex(c_float_complex) "
  call print_type_info(z_float)
  print*, "-  complex(c_double_complex) ---"
  call print_type_info(z_double)
end

 % gfortran c_descriptor.c assumed-type.f90

% ./a.out
 -  complex(c_float_complex) 
a_desc->type = 2052
a_desc->elem_len = 8
CFI_type_float_Complex = 1028
CFI_type_double_Complex = 2052
 -  complex(c_double_complex) ---
a_desc->type = 4100
a_desc->elem_len = 16
CFI_type_float_Complex = 1028
CFI_type_double_Complex = 2052

% gfortran --version
GNU Fortran (Homebrew GCC 11.2.0_3) 11.2.0

Re: Bug 104404 - Incorrect CFI_cdesc_t "type" member for assumed-type, assumed-rank complex dummy arguments

[Damian Rouson via Fortran]

That's great news.  Thanks for letting me know.

Damian

On Sun, Feb 6, 2022 at 12:48 AM Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

> Hi Damian,
>
> Tobias Burnus fixed it in 12-branch:
> GNU Fortran (GCC) 12.0.1 20220203 (experimental)
> ./a.out
>  -  complex(c_float_complex) 
> a_desc->type = 1028
> a_desc->elem_len = 8
> CFI_type_float_Complex = 1028
> CFI_type_double_Complex = 2052
>  -  complex(c_double_complex) ---
> a_desc->type = 2052
> a_desc->elem_len = 16
> CFI_type_float_Complex = 1028
> CFI_type_double_Complex = 2052
>
> Cheers
>
> Paul
>
>
> On Sun, 6 Feb 2022 at 03:39, Damian Rouson via Fortran <
> fortran@gcc.gnu.org> wrote:
>
>> For an assumed-type, assumed-rank complex dummy argument in a C interface,
>> gfortran 11.2.0 passes a CFI_cdesc_t object with a "type" member that does
>> not match the corresponding CFI_type_float_Complex and
>> CFI_type_double_Complex values. In the case of a complex(c_float_complex)
>> argument, the passed "type" member corresponds to CFI_type_double_Complex.
>> For a complex(c_double_complex) argument, the "type" member has a value
>> that I don't recognize.  Does anyone know whether this has been fixed on
>> the 12 branch?
>>
>> % cat c_descriptor.c
>> #include 
>> #include 
>>
>> void c_descriptor(CFI_cdesc_t* c)
>> {
>>   printf("a_desc->type = %d \n", c->type);
>>   printf("a_desc->elem_len = %d \n", c->elem_len);
>>   printf("CFI_type_float_Complex = %d \n", CFI_type_float_Complex);
>>   printf("CFI_type_double_Complex = %d \n", CFI_type_double_Complex);
>> }
>>
>> % cat c_descriptor.c
>> #include 
>> #include 
>>
>> void c_descriptor(CFI_cdesc_t* c)
>> {
>>   printf("a_desc->type = %d \n", c->type);
>>   printf("a_desc->elem_len = %d \n", c->elem_len);
>>   printf("CFI_type_float_Complex = %d \n", CFI_type_float_Complex);
>>   printf("CFI_type_double_Complex = %d \n", CFI_type_double_Complex);
>> }
>> (base) rouson@CLaSS adhoc % cat assumed-type.f90
>> module c_descriptor_m
>>   implicit none
>> contains
>>   module subroutine print_type_info(a)
>> type(*), intent(inout), contiguous, target :: a(..)
>>
>> interface
>>   subroutine c_descriptor(a) bind(C)
>> implicit none
>> type(*) a(..)
>>   end subroutine
>> end interface
>>
>> call c_descriptor(a)
>>
>>   end subroutine
>> end module
>>
>>   use c_descriptor_m
>>   use iso_c_binding
>>   implicit none
>>
>>   complex(c_float_complex) :: z_float = (0._c_float, 0._c_float)
>>   complex(c_double_complex):: z_double = (0._c_double, 0._c_double)
>>
>>   print*, "-  complex(c_float_complex) "
>>   call print_type_info(z_float)
>>   print*, "-  complex(c_double_complex) ---"
>>   call print_type_info(z_double)
>> end
>>
>>  % gfortran c_descriptor.c assumed-type.f90
>>
>> % ./a.out
>>  -  complex(c_float_complex) 
>> a_desc->type = 2052
>> a_desc->elem_len = 8
>> CFI_type_float_Complex = 1028
>> CFI_type_double_Complex = 2052
>>  -  complex(c_double_complex) ---
>> a_desc->type = 4100
>> a_desc->elem_len = 16
>> CFI_type_float_Complex = 1028
>> CFI_type_double_Complex = 2052
>>
>> % gfortran --version
>> GNU Fortran (Homebrew GCC 11.2.0_3) 11.2.0
>>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough" -
> Albert Einstein
>

PR 105542 - [F03] Orthogonal standard-conforming type finalization tests

[Damian Rouson via Fortran]

In case it's useful to gfortran developers, the Reference-Counter
repository (https://github.com/sourceryinstitute/reference-counter)
contains a test/compiler_test.f90 file that separately tests each of the
scenarios in which Fortran 2018 clause 7.5.6.3 requires type finalization
to occur.  Thanks to the contributions of Wileam Phan and Brad Richardson,
one function tests each scenario.  A comment near the top of each such
function cites the paragraph number of the corresponding requirement.  To
download and run the tests on macOS or Linux with gfortran 12.1.0 and the
Fortran Package Manager (fpm) already installed, execute the following
commands:

git clone https://github.com/sourceryinstitute/reference-counter
cd reference-counter
fpm test

for which the trailing output is

Running Tests

Test that
The compiler
finalizes a non-allocatable object on the LHS of an intrinsic
assignment
finalizes an allocated allocatable LHS of an intrinsic assignment
finalizes a target when the associated pointer is deallocated
finalizes an object upon explicit deallocation
finalizes a non-pointer non-allocatable array object at the END
statement
finalizes a non-pointer non-allocatable object at the end of a
block construct
finalizes a function reference on the RHS of an intrinsic assignment
finalizes a specification expression function result
finalizes an intent(out) derived type dummy argument
finalizes an allocatable component object
A ref_reference
does not leak when constructed, assigned, and then explicitly freed

A total of 11 test cases

Failed
Took 1.94e-4 seconds

Test that
The compiler
finalizes a non-allocatable object on the LHS of an intrinsic
assignment
Expected
|1|
but got
|0|
finalizes an allocated allocatable LHS of an intrinsic assignment
Expected
|1|
but got
|0|
finalizes a function reference on the RHS of an intrinsic assignment
Expected
|1|
but got
|0|
finalizes a specification expression function result
Expected
|1|
but got
|0|

4 of 11 cases failed
4 of 11 assertions failed

STOP 1
 Execution failed for object " reference-counter-test "
*cmd_run*:stopping due to failed executions
STOP 1

PR 107406

[Damian Rouson via Fortran]

gfortran 12.2 accepts the code below if the "allocatable" attribute is
removed:

% cat gfortran-lock-issue.f90
  use iso_fortran_env
  type foo
type(lock_type), allocatable :: bar
  end type
  type(foo) foobar[*]
end

 % gfortran -fcoarray=single gfortran-lock-issue.f90
gfortran-lock-issue.f90:3:39:
3 | type(lock_type), allocatable :: bar
  |   1
Error: Allocatable component bar at (1) of type LOCK_TYPE must have a
codimension

The NAG compiler accepts the above code with or without the allocatable
attribute, and I believe constraint C1608 in the Fortran 2018
interpretation document makes the above code valid.

Damian

PRs 100650 and 49324: intrinsic assignment of reshaped derived type array constructor

[Damian Rouson via Fortran]

I just added a shorter reproducer (below) to PR 100650.  Is this also
related to PR 49324?

Damian

% cat reshape-array-constructor.f90
  implicit none
  type foo_t
integer, allocatable :: bar(:)
  end type

  type(foo_t) foo(2,1)
  integer :: i, j,  n(2,2,1) = reshape([-1,-1,1,1], [2,2,1])

  foo = reshape([([(foo_t(merge(0, 1, n(:,i,j) > 0)), i=1,2)], j=1,1)],
[2,1])
  print *, merge(0, 1, n(:,1,1) > 0), foo(1,1)%bar
  print *, merge(0, 1, n(:,2,1) > 0), foo(2,1)%bar
end
% gfortran reshape-array-constructor.f90
% ./a.out
   1   1   786120848   65240
   0   0   786120848   65240
% gfortran --version
GNU Fortran (Homebrew GCC 13.1.0) 13.1.0