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: [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

Re: [Patch, Fortran] libgomp: Silence unpack's may be used uninitialized warning

[Damian Rouson]

I've been seeing similar messages to this one for quite some time now -- I
think ~1 year.  I don't often use unpack so there are likely many other
causes too.  I haven't take the time to isolate them, but if I can do so
easily, I'll submit reports.

Damian

On Mon, Sep 28, 2020 at 2:12 PM Tobias Burnus 
wrote:

> There are more warnings, but I picked this one which shows up
> with default build options for GCC trunk – twice for each
> generated file:
>
> ../../../../repos/gcc/libgfortran/generated/unpack_i2.c:128:12: warning:
> ‘rstride’ may be used uninitialized [-Wmaybe-uninitialized]
> ../../../../repos/gcc/libgfortran/generated/unpack_i2.c:278:12: warning:
> ‘rstride’ may be used uninitialized [-Wmaybe-uninitialized]
>
> Hence, 13 times these messages (×2 warnings/file + ×2 with multilib) → 53
> 'warning:'.
>
> Seemingly, the compiler logic has changes as the previous location
> used to be sufficient to silence the compiler.
> (The warning is right if base_addr = NULL and dim = 0; the latter should
> not occur but the compiler does not know this.)
>
> Committed as obvious as r11-3508-g69c56ce673d1e1d4508e82053a32011f807c6088
>
> Tobias
>
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München /
> Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
> Alexander Walter
>

Re: [PATCH] Allow opening file on multiple units

[Damian Rouson]

Could someone please update the Fortran 2018 status page on the wiki
to reflect this patch?  I would volunteer to do it myself, but I've
tried on at least 3 occasions (including today) to set up an account
or generate a new password and every attempt fails with a warning that
I'm being locked out because of too many requests in a short period of
time.

Is anyone aware of other lines in the status page that can also be
updated based on recent patches.  If so, please update those too.
Keeping the wiki up-to-date would be a great time-savings to whomever
takes on responding to the Fortran compiler status survey that Ian
Chivers and Jane Sleightholme publish periodically in the ACM Fortran
Forum.  I think Paul is usually the one to respond and I know it costs
him a great deal of time to do so.   I wish I could help by keeping
the wiki up-to-date.  I promise to do so if I ever manage to survive
the login setup process.

Damian


On Wed, May 15, 2019 at 9:02 AM Steve Kargl
 wrote:
>
> On Wed, May 15, 2019 at 04:24:47PM +0300, Janne Blomqvist wrote:
> > As of Fortran 2018 it's allowed to open the same file on multiple
> > units.
> >
> > fortran/ChangeLog:
> >
> > 2019-05-15  Janne Blomqvist  
> >
> >   PR fortran/90461
> > * io/open.c (new_unit): Don't check if the file is already open
> >   for F2018.
> >
> > testsuite/ChangeLog:
> >
> > 2019-05-15  Janne Blomqvist  
> >
> >   PR fortran/90461
> > * gfortran.dg/open_errors_2.f90: Add -std=f2008, adjust line number.
> >   * gfortran.dg/open_errors_3.f90: New test.
> >
> > Regtested on x86_64-pc-linux-gnu, Ok for trunk?
>
> Yes.
>
> --
> Steve

Re: ISO_Fortran_binding patch

[Damian Rouson]

On Wed, Jan 9, 2019 at 3:08 PM Thomas Koenig  wrote:
>
>
> Thanks a lot for this!  Looking at what we are currently
> finishing, I think we will be quite close to F2008 conformance
> when gcc 9 comes out, modulo a few bugs, of course.

And because ISO_Fortran_binding.h is part of Fortran 2018, this patch moves
gfortran closer to 2018 conformance as well.

Damian

Re: OpenCoarrays integration with gfortran

[Damian Rouson]

On Fri, Sep 21, 2018 at 9:25 AM Jerry DeLisle  wrote:

> The actual library source code is contained mostly in one source file.

There are as many files as there are options for the underlying
parallel programming
model.  The default is MPI, but I've co-authored conference papers last year
and this year in which the OpenCoarrays OpenSHEM option outperformed MPI.
One paper even described a platform on which OpenSHMEM was the only option
beyond a few thousand cores because the required MPI features were immature on
that platform.  Early versions of OpenCoarrays also provided GASNet
and ARMCI options.
I recommend against tying gfortran to MPI only.

> After all the attempts to integrate into the GNU build systems without
> much success my thinking has shifted.

Thanks for all your efforts!

> Keep in mind that the OpenCoarrays
> implementation is quite dependent on gfortran and in fact has to do
> special things in the build dependent on the version of gcc/gfortran a
> user happens to use.  I dont think this is a good situation.

I agree.  Possibly OpenCoarrays could drop support for older gfortran versions
at some point to avoid maintaining code that exists solely to support compiler
versions that are several years old.

>
> 1) Focus on distribution packages such as Fedora, Debian, Ubuntu,
> Windows, etc. Building of these packages needs to be automated into the
> distributions.

This is the option that the OpenCoarrays documentation recommends as easiest for
most users.

> 2) Take the one source file, edit out all the macros that define
> prefixes to function calls, hard code the gfortran prefixes etc and fork
> it directly into the libgfortran library under GPL with attributions to
> the original developers as appropriate.

See above.   Also, this means that changes in the gfortran repository would not
propagate back upstream unless each gfortran developer agrees to
distribute his or her
work under both GPL and BSD.  Even that is only feasible if the copied
files stay cohesive
and don't reference code outside the copied file.  I think it's more
likely that copying the code
into gfortran would be a branch point, after which the relevant files
would diverge and
work on the GPL side would be harder to fund than the BSD side.

Most commercial entities are more likely to contribute to a
BSD-licensed project than a
GPL-licensed one.  Over the past several months, one commercial compiler vendor
authorized one of their developers to contribute to OpenCoarrays. and
another commercial
compiler vendor invited community input on whether to use OpenCoarrays
during a public
teleconference.  The prospect of commercial support is the motivation
for using BSD.

> Strategy 2 does have some advantages. For example, eliminating the need
> for separate CAF and CAFRUN scripts which are a wrapper on gfortran.

Even in the case of just one underlying parallel programming model,
this is tricky.  To wit, Cray uses
a compiler wrapper and a program launcher.  Intel was able to
eliminate the compiler wrapper,
but still required a program launcher for distributed-memory execution
until recently.  I don't
know the details, but I've heard it was not trivial for Intel to
accomplish this and I imagine it would be
even more complicated if they weren't hardwiring Intel MPI into their back-end.

> People would just have to stop thinking about it and just use it.

The same would be true if someone could coax the GCC build system to
build OpenCoarrays
just as it builds other prerequisites.  The big difference is that
OpenCoarrays is a prerequisite
for using gfortran rather than for building gfortran so it needs to be
built after gfortran rather
than before like other prerequisites.  The real problem is finding
anyone who can work the
proper magic in the GCC build system.

Thanks for your input.  I hope my response is helpful.

Damian

Re: [PATCH 08/25] Fix co-array allocation

[Damian Rouson]

On Thu, Sep 20, 2018 at 1:01 PM Thomas Koenig  wrote:

>
> We addressed integrating OpenCoarray into the gcc source tree at the
> recent Gcc summit during the gfortran BoF session.
>

I agree with keeping it as a separate code base, but comments from some
gfortran developers on the gfortran mailing list suggest that they liked
the idea of integrating the building of OpenCoarrays into the GCC build
system to simplify multi-image testing.


> Feedback from people working for big Linux distributions was that they
> would prefer to package OpenCoarrays as a separate library.
> (They also mentioned it was quite hard to build.)
>
> Maybe these people could use some help from you.
>

Thanks for the feedback.  Please feel free to put me in touch with them or
suggest that they submit issues on the OpenCoarrays repository.  We would
be glad to help.  We've put a lot of time into addressing installation
issues that have been submitted to us and we'll continue to do so if we
receive reports.

Damian

Re: [PATCH 08/25] Fix co-array allocation

[Damian Rouson]

On Wed, Sep 19, 2018 at 3:30 PM Andrew Stubbs  wrote:

>
> If you want to port your tool to GCN that would be cool, but I suspect
> non-trivial.
>

To clarify, OpenCoarrays is not a tool.  It is the parallel ABI required to
create executable programs capable of executing in multiple images as
required by the Fortran 2008 standard.  Multi-image execution is the reason
coarray features exist so I hope the maintainers won't approve a patch that
impacts coarray features but has not been tested against OpenCoarrays,
which has its own test suite.  Again, I would be glad to assist with
installing OpenCoarrays on your system. Whether it's trivial or not, it's
essential to protect against breaking a large feature set that is part of
Fortran 2008 and 2018.

Damian

Re: [PATCH 08/25] Fix co-array allocation

[Damian Rouson]

Has this been tested in multi-image execution using OpenCoarrays?   If not,
I would be glad to assist with installing OpenCoarrays so that it can be
part of the testing process.

On a related note, two Sourcery Institute developers have attempted to edit
the GCC build system to make the downloading and building of OpenCoarrays
automatically part of the gfortran build process.  Neither developer
succeeded.  If anyone has any interest in figuring out how to do this, it
will prevent a lot of potential regressions when single-image testing
doesn't expose issues that only arise with multi-image execution.

Damian

On Wed, Sep 19, 2018 at 9:25 AM Andrew Stubbs  wrote:

> On 05/09/18 19:07, Janne Blomqvist wrote:
> > The argument must be of type size_type_node, not sizetype. Please instead
> > use
> >
> > size = build_zero_cst (size_type_node);
> >
> >
> >>  * trans-intrinsic.c (conv_intrinsic_event_query): Convert
> computed
> >>  index to a size_t type.
> >>
> >
> > Using integer_type_node is wrong, but the correct type for calculating
> > array indices (lbound, ubound,  etc.) is not size_type_node but rather
> > gfc_array_index_type (which in practice maps to ptrdiff_t). So please use
> > that, and then fold_convert index to size_type_node just before
> generating
> > the call to event_query.
> >
> >
> >>  * trans-stmt.c (gfc_trans_event_post_wait): Likewise.
> >>
> >
> > Same here as above.
>
> How is the attached? I retested and found no regressions.
>
> Andrew
>

Re: [wwwdocs] Add GCC 8 Fortran feature description

[Damian Rouson]

Thank you!

Damian

On May 17, 2018 at 12:32:19 AM, Thomas Koenig (tkoe...@netcologne.de) wrote:

> Hi Damian,
>
> Partial support is provided for Fortran 2018 teams, which are
> hierarchical
> subsets of images that execute independently of other image subsets.
>
>
> Committed.
>
> Regards
>
> Thomas
>
>

Re: [wwwdocs] Add GCC 8 Fortran feature description

[Damian Rouson]

**PING**

Could someone either approve and apply this or explain to me how to do so?  I 
don’t have commit rights so I don’t think I can do it.

Damian

On May 2, 2018 at 11:22:02 AM, Damian Rouson (dam...@sourceryinstitute.org) 
wrote:

The patch below includes a description of a new feature in gfortran for 
inclusion in the GCC 8 changes.html file.  I don’t have commit rights.  Could 
someone approve and apply this?  Thanks.  

Damian  


cvs diff: Diffing .  
Index: changes.html  
===  
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v  
retrieving revision 1.74  
diff -r1.74 changes.html  
761a762,765  
>      
>     Partial support is provided for Fortran 2018 teams, which are 
> hierarchical  
>     subsets of images that execute independently of other image subsets.   
>     

[wwwdocs] Add GCC 8 Fortran feature description

[Damian Rouson]

The patch below includes a description of a new feature in gfortran for 
inclusion in the GCC 8 changes.html file.  I don’t have commit rights.  Could 
someone approve and apply this?  Thanks.

Damian


cvs diff: Diffing .
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.74
diff -r1.74 changes.html
761a762,765
>    
>     Partial support is provided for Fortran 2018 teams, which are hierarchical
>     subsets of images that execute independently of other image subsets. 
>   

Re: [PATCH] Character length cleanup for Coarray Fortran library

[Damian Rouson]

Hi Janne,

To be more specific, the new OpenCoarrays test failures after applying the 
patch are the following ones:

 image_fail_test_1 (Timeout)
 image_fail_and_sync_test_2 (Timeout)
 image_fail_and_sync_test_3 (Timeout)
 image_fail_and_get_test_1 (Timeout)

There are four.  I was mistaken when I wrote that there are three.

Damian

On February 21, 2018 at 12:56:05 PM, Janne Blomqvist 
(blomqvist.ja...@gmail.com) wrote:

On Wed, Feb 21, 2018 at 10:18 PM, Damian Rouson  
<dam...@sourceryinstitute.org> wrote:  
>  
>  
>  
>  
> On February 21, 2018 at 11:35:47 AM, Janne Blomqvist 
> (blomqvist.ja...@gmail.com(mailto:blomqvist.ja...@gmail.com)) wrote:  
>  
>> PING  
>>  
>> Is anybody planning to work on this on the opencoarrays side? Or do  
>> you prefer that this is just committed and you can sort it out on your  
>> own schedule?  
>  
> Hi Janne,  
>  
> The trunk didn’t build for me the first time I tried soon after your initial 
> email and it took me until yesterday to find time to try again. Once I 
> succeeded, the patch created three new test failures. I’m wondering if 
> Andre’s recent patch (r257813) helped reduce the number. All new failures 
> involve the failed-images features developed by Alessandro and Andre, both of 
> whom now have new employment or contracts that prevent making significant 
> contributions to OpenCoarrays (although I hope that will change and am 
> working with Alessandro’s organization to attempt to get some of his time 
> allocated to gfortran/OpenCoarrays development).  
>  
> I think the most sustainable path forward is for me to assist any interested 
> gfortran developer in building OpenCoarrays on your local system and running 
> the test suite. At least that eliminates the reliance on OpenCoarrays 
> developers to run the tests every time a patch impacts OpenCoarrays. If we 
> can work together on building OpenCoarrays on your system, we can also look 
> together at the requisite changes to see if we can eliminate the failures.  
>  
> Oxford University Ph.D. student Daniel Garza visit Sourcery Institute March 
> 17 - June 2 to integrate the building of OpenCoarrays into the GCC build 
> system so I hope this will all be easier sooner.  

Ok, I'll see if I find the time to get opencoarrays built.  



--  
Janne Blomqvist  

Re: [PATCH] Character length cleanup for Coarray Fortran library

[Damian Rouson]

 



On February 21, 2018 at 11:35:47 AM, Janne Blomqvist 
(blomqvist.ja...@gmail.com(mailto:blomqvist.ja...@gmail.com)) wrote:

> PING  
>  
> Is anybody planning to work on this on the opencoarrays side? Or do  
> you prefer that this is just committed and you can sort it out on your  
> own schedule?  

Hi Janne,

The trunk didn’t build for me the first time I tried soon after your initial 
email and it took me until yesterday to find time to try again.  Once I 
succeeded, the patch created three new test failures.  I’m wondering if Andre’s 
recent patch (r257813) helped reduce the number.  All new failures involve the 
failed-images features developed by Alessandro and Andre, both of whom now have 
new employment or contracts that prevent making significant contributions to 
OpenCoarrays (although I hope that will change and am working with Alessandro’s 
organization to attempt to get some of his time allocated to 
gfortran/OpenCoarrays development).

I think the most sustainable path forward is for me to assist any interested 
gfortran developer in building OpenCoarrays on your local system and running 
the test suite.  At least that eliminates the reliance on OpenCoarrays 
developers to run the tests every time a patch impacts OpenCoarrays.  If we can 
work together on building OpenCoarrays on your system, we can also look 
together at the requisite changes to see if we can eliminate the failures.

Oxford University Ph.D. student Daniel Garza visit Sourcery Institute March 17 
- June 2 to integrate the building of OpenCoarrays into the GCC build system so 
I hope this will all be easier sooner.

Damian 

Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier

[Damian Rouson]

Hi Andre,

Thanks for your latest work on CAF features.  Could you let us know whether 
this commit should be tested against the OpenCoarrays master branch or another 
branch?  With the master branch, I get one test failure (not counting two known 
teams failures that are actually false negatives that I need to fix):

lib_caf_mpi::sendget_by_ref(): Warning ! sendget_by_ref() is mostly 
unfunctional due to a design error. Split up your statement with coarray refs 
on both sides of the assignment when the datatype transfered is non 
4-byte-integer compatible.
libcaf_mpi RUNTIME ERROR: Cannot convert type 1 kind 4 to type 0 kind 4

Is the above expected?  Also, because the message comes from sendget, does that 
mean it only affects lines that involve three images such as the following:

if (this_image()==1) x[2] = x[3]


Damian

On February 19, 2018 at 9:32:06 AM, Andre Vehreschild (ve...@gmx.de) wrote:

Hi all,  

no objections received therefore committed as r257813. Thanks for fast review  
Jerry.  

- Andre  

On Sun, 18 Feb 2018 18:33:07 +0100  
Andre Vehreschild  wrote:  

> Well, after discussing on IRC whether RM should be bothered, I was asked to  
> simplify release managers lives and propose, that if no one objects within 
> one  
> day, I will merge the patch. So any objections?  
>  
> - Andre  
>  
> On Sun, 18 Feb 2018 18:07:28 +0100  
> Andre Vehreschild  wrote:  
>  
> > Dear release managers,  
> >  
> > this patch (for reference  
> > https://gcc.gnu.org/ml/fortran/2018-02/msg00124.html) fixes a regression in 
> >  
> > the coarray api by extending three relatively new functions with one or two 
> >  
> > arguments, respectively. The patch has been approved by gfortran devs.  
> > Asking your approval to merge it: Ok to merge to trunk?  
> >  
> > Regards,  
> > Andre  
> >  
> > On Sun, 18 Feb 2018 08:53:41 -0800  
> > Jerry DeLisle  wrote:  
> >  
> > > On 02/18/2018 07:39 AM, Andre Vehreschild wrote:  
> > > > Hi all,  
> > > >  
> > > > attached patch fixes an issue with the coarray API. When a component of 
> > > >  
> > > > a derived type coarray was referenced using a caf_*_by_ref () function  
> > > > and that component was not an array with a descriptor, then the type of 
> > > >  
> > > > the component was not known. Which additionally meant, that type  
> > > > conversion was not applied as required. This patch fixes that issue by  
> > > > adding type specifiers to the three caf_*_by_ref-calls and implements  
> > > > the functionality for libcaf_single. This is harmless because other  
> > > > coarray libraries that do not expect this argument just ignore it.  
> > > > Additionally does this patch also provide the first working version of  
> > > > caf_sendget_by_ref in libcaf_single, which previously only lead to a  
> > > > stack corruption and was not usable since the array descriptor rework  
> > > > (nice job, btw).  
> > > >  
> > > > I would like to have this patch in trunk knowing that I am somewhat  
> > > > late, but it would be quite necessary, because as it is now, the  
> > > > coarray feature for derived types is hardly usable. Furthermore do some 
> > > >  
> > > > people name this a regression, because the caf_*_by_ref are also used  
> > > > when the lhs of a caf_get_by_ref() is allocatable which now does not  
> > > > work as expected anymore but before gcc-6 using caf_get() (w/o  
> > > > reallocation) did.  
> > > >  
> > > > Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk?  
> > > >  
> > > > - Andre  
> > > >  
> > >  
> > > This is OK from the Fortranners perspective. Should touch base with  
> > > release manager. It looks harmless though it changes coarray API, which  
> > > is hidden behind -fcoarray=  
> > >  
> > > Regards,  
> > >  
> > > Jerry  
> >  
> >  
>  
>  


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

Re: [PATCH] Character length cleanup for Coarray Fortran library

[Damian Rouson]

 
I’ll try applying the patch and testing it.  I have about a 50% success rate 
with getting patches to apply cleanly.  Is this available on an svn or git 
branch that I can just checkout rather than attempting to apply the patch?  I 
find that process to be much more reliable. 

Going forward, please submit OpenCoarrays questions or issues via our issues 
page:

https://github.com/sourceryinstitute/OpenCoarrays/issues  

Most OpenCoarrays contributors don’t monitor the gfortran mailing list closely 
so we’re unlikely to see emails to the list in a timely manner.  

Also, when making changes that impact OpenCoarrays, please build OpenCoarrays 
and run our test suite.  We recently made several changes to our installation 
documentation and installer script based on feedback received from Steve Kargl. 
 One result is a set of instructions written by Zaak with GCC developers as an 
intended audience:  

https://github.com/sourceryinstitute/OpenCoarrays/blob/master/INSTALL  

Several other installation changes inspired by Steve’s feedback are listed 
here:  

https://github.com/sourceryinstitute/OpenCoarrays/issues/478  

and these will make it into a release shortly, but are already all available 
via git clone. I’m looking forward to hosting Oxford University Ph.D. student 
Daniel Garza, from March 17 to June 2, to work on finishing the integration of 
OpenCoarrays into the GCC autotools scripts so that OpenCoarrays will be built 
anytime gfortran is built so hopefully it will be even easier for everyone to 
build and test with OpenCoarrays soon.  

Damian 


On February 9, 2018 at 8:11:07 AM, Janne Blomqvist 
(blomqvist.ja...@gmail.com(mailto:blomqvist.ja...@gmail.com)) wrote:

> Following the change to use size_t for Fortran character lengths (PR
> 78534), this patch modifies the Coarray ABI in a similar way. The
> single-image implementation that is included in libgfortran is
> updated, but this needs corresponding work in the OpenCoarray library
> as well for multi-image support. Damian, can you look into that?
>  
> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
>  
> gcc/fortran/ChangeLog:
>  
> 2018-02-09 Janne Blomqvist  
>  
> * gfortran.texi: Update Coarray API description.
> * trans-decl.c (gfc_build_builtin_function_decls): Use size_t for
> character lengths, int for exit codes.
> (generate_coarray_sym_init): Use size_t for character length.
> * trans-intrinsic.c (conv_co_collective): Likewise.
> * trans-stmt.c (gfc_trans_lock_unlock): Likewise.
> (gfc_trans_event_post_wait): Likewise.
> (gfc_trans_sync): Likewise.
>  
> libgfortran/ChangeLog:
>  
> 2018-02-09 Janne Blomqvist  
>  
> * caf/libcaf.h: Remove stdint.h include.
> (_gfortran_caf_register): Use size_t for character length.
> (_gfortran_caf_deregister): Likewise.
> (_gfortran_caf_sync_all): Likewise.
> (_gfortran_caf_sync_memory): Likewise.
> (_gfortran_caf_sync_images): Likewise.
> (_gfortran_caf_stop_numeric): Use int for exit code.
> (_gfortran_caf_stop_str): Use size_t for character length.
> (_gfortran_caf_error_stop_str): Likewise.
> (_gfortran_caf_error_stop): Use int for exit code.
> (_gfortran_caf_co_broadcast): Use size_t for character length.
> (_gfortran_caf_co_sum): Likewise.
> (_gfortran_caf_co_min): Likewise.
> (_gfortran_caf_co_max): Likewise.
> (_gfortran_caf_co_reduce): Likewise.
> (_gfortran_caf_lock): Likewise.
> (_gfortran_caf_unlock): Likewise.
> (_gfortran_caf_event_post): Likewise.
> (_gfortran_caf_event_wait): Likewise.
> * caf/mpi.c (_gfortran_caf_register): Update implementation to
> match prototype.
> (_gfortran_caf_deregister): Likewise.
> (_gfortran_caf_sync_all): Likewise.
> (_gfortran_caf_sync_images): Likewise.
> (_gfortran_caf_error_stop_str): Likewise.
> (_gfortran_caf_error_stop): Likewise.
> * caf/single.c (caf_internal_error): Likewise.
> (_gfortran_caf_register): Likewise.
> (_gfortran_caf_deregister): Likewise.
> (_gfortran_caf_sync_all): Likewise.
> (_gfortran_caf_sync_memory): Likewise.
> (_gfortran_caf_sync_images): Likewise.
> (_gfortran_caf_stop_numeric): Likewise.
> (_gfortran_caf_stop_str): Likewise.
> (_gfortran_caf_error_stop_str): Likewise.
> (_gfortran_caf_error_stop): Likewise.
> (_gfortran_caf_co_broadcast): Likewise.
> (_gfortran_caf_co_sum): Likewise.
> (_gfortran_caf_co_min): Likewise.
> (_gfortran_caf_co_max): Likewise.
> (_gfortran_caf_co_reduce): Likewise.
> (_gfortran_caf_event_post): Likewise.
> (_gfortran_caf_event_wait): Likewise.
> (_gfortran_caf_lock): Likewise.
> (_gfortran_caf_unlock): Likewise.
> ---
> gcc/fortran/gfortran.texi | 32 -
> gcc/fortran/trans-decl.c | 38 +++---
> gcc/fortran/trans-intrinsic.c | 4 ++--
> gcc/fortran/trans-stmt.c | 12 +-
> libgfortran/caf/libcaf.h | 37 ++---
> libgfortran/caf/mpi.c | 28 +++---
> libgfortran/caf/single.c | 55 ++-
> 7 files changed, 103 insertions(+), 103 deletions(-)
>  
> diff --git 

Re: [PATCH, fortran] Support Fortran 2018 teams

[Damian Rouson]

On January 24, 2018 at 1:29:12 PM, Steve Kargl 
(s...@troutmask.apl.washington.edu) wrote:


Yes, thanks, Paul. Unfortunately, I've run out of time.  
Damian, GCC is in stage 3, we need to wait for approval  
from the release manager (aka Jakub) before committing  
the patch.  


Will do.  

Damian

Re: [PATCH, fortran] Support Fortran 2018 teams

[Damian Rouson]

Thank you, Paul.   I think Alessandro has commit rights.  If so, then I’ll ask 
him to make the requested edits and commit it.

Damian

On January 24, 2018 at 12:19:58 PM, Paul Richard Thomas 
(paul.richard.tho...@gmail.com) wrote:

Hi All,  

Given the delay relative to the start of stage 3, I thought that I had  
better deal with this asap:  


+ /* TODO: this works on any derived type when  
+ it should only work with team_type. */  
+ if (team->ts.type != BT_DERIVED)  
Why don't you give the team_type derived type an attribute 'team_type'  
and test that?  

- code node is passed. The result type and library subroutine name  
+ code ndoe is passed. The result type and library subroutine name  
typo  

+! Tests if team_number intrinsic fucntion works  

It's just as well that there is an 'n' in there, although it gives me  
an idea for a new type of fortran procedure that does what it says :-)  

Together with the change that Steve identified, this seems to me to be  
ready to go.  

(Jakub, This is all hidden behind the -fcoarray option. To my mind  
this is safe for release.)  

OK for trunk.  

Many thanks for this patch.  

Paul  


On 23 January 2018 at 05:45, Steve Kargl  
<s...@troutmask.apl.washington.edu> wrote:  
> I'm heading out of town for a meeting at the end of  
> week, so gfortran patches/reviews are on hold at the  
> moment. If someone else wants to step up to review  
> the patch, I won't object.  
>  
> --  
> steve  
>  
> On Mon, Jan 22, 2018 at 08:29:41PM -0800, Damian Rouson wrote:  
>> Is Fortran 2018 teams patch ok for trunk?  
>>  
>> Damian  
>>  
>> On January 19, 2018 at 2:47:39 PM, Alessandro Fanfarillo (elfa...@ucar.edu) 
>> wrote:  
>>  
>> I can confirm that the little change suggested by Steve passes the  
>> regtests (on x86_64-pc-linux-gnu) and the regular tests using  
>> OpenCoarrays.  
>>  
>> On Fri, Jan 19, 2018 at 10:33 AM, Steve Kargl  
>> <s...@troutmask.apl.washington.edu> wrote:  
>> > On Fri, Jan 19, 2018 at 09:18:14AM -0800, Damian Rouson wrote:  
>> >> Thanks for catching that, Steve, and for responding, Alessandro.  
>> >>  
>> >> Anything else?  
>> >>  
>> >  
>> > I've only just started to look at the patch. Unfortunately,  
>> > I know zero about teams, so need to read the patch and F2018  
>> > standard simultaneously.  
>> >  
>> > --  
>> > Steve  
>>  
>>  
>>  
>> --  
>>  
>> Alessandro Fanfarillo, Ph.D.  
>> Postdoctoral Researcher  
>> National Center for Atmospheric Research  
>> Mesa Lab, Boulder, CO, USA  
>> 303-497-1229  
>  
> --  
> Steve  
> 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4  
> 20161221 https://www.youtube.com/watch?v=IbCHE-hONow  



--  
"If you can't explain it simply, you don't understand it well enough"  
- Albert Einstein  

Re: [PATCH, fortran] Support Fortran 2018 teams

[Damian Rouson]

Is Fortran 2018 teams patch ok for trunk?   

Damian

On January 19, 2018 at 2:47:39 PM, Alessandro Fanfarillo (elfa...@ucar.edu) 
wrote:

I can confirm that the little change suggested by Steve passes the  
regtests (on x86_64-pc-linux-gnu) and the regular tests using  
OpenCoarrays.  

On Fri, Jan 19, 2018 at 10:33 AM, Steve Kargl  
<s...@troutmask.apl.washington.edu> wrote:  
> On Fri, Jan 19, 2018 at 09:18:14AM -0800, Damian Rouson wrote:  
>> Thanks for catching that, Steve, and for responding, Alessandro.  
>>  
>> Anything else?  
>>  
>  
> I've only just started to look at the patch. Unfortunately,  
> I know zero about teams, so need to read the patch and F2018  
> standard simultaneously.  
>  
> --  
> Steve  



--  

Alessandro Fanfarillo, Ph.D.  
Postdoctoral Researcher  
National Center for Atmospheric Research  
Mesa Lab, Boulder, CO, USA  
303-497-1229  

Re: [PATCH, fortran] Support Fortran 2018 teams

[Damian Rouson]

Thanks for catching that, Steve, and for responding, Alessandro.

Anything else?

Damian

On January 19, 2018 at 9:17:03 AM, Alessandro Fanfarillo (elfa...@ucar.edu) 
wrote:

Yes, definitively ar->team. 

On Fri, Jan 19, 2018 at 8:36 AM, Steve Kargl 
 wrote: 
> index 882fe577b76..b4baf5be554 100644 
> --- a/gcc/fortran/array.c 
> +++ b/gcc/fortran/array.c 
> @@ -158,6 +158,7 @@ gfc_match_array_ref (gfc_array_ref *ar, gfc_array_spec 
> *as, int init, 
> bool matched_bracket = false; 
> gfc_expr *tmp; 
> bool stat_just_seen = false; 
> + bool team_just_seen = false; 
> 
> memset (ar, '\0', sizeof (*ar)); 
> 
> @@ -230,8 +231,21 @@ coarray: 
> if (m == MATCH_ERROR) 
> return MATCH_ERROR; 
> 
> + team_just_seen = false; 
> stat_just_seen = false; 
> - if (gfc_match(" , stat = %e",) == MATCH_YES && ar->stat == NULL) 
> + if (gfc_match (" , team = %e", ) == MATCH_YES && ar->stat == NULL) 
> 
> 
> Is the 2nd ar->stat suppose to be ar->team? 
> 
> -- 
> Steve 



-- 

Alessandro Fanfarillo, Ph.D. 
Postdoctoral Researcher 
National Center for Atmospheric Research 
Mesa Lab, Boulder, CO, USA 
303-497-1229 

[PATCH, fortran] Support Fortran 2018 teams

[Damian Rouson]

 
All,

Attached please find what I hope is the final version of the patch that adds 
partial support for teams of images, the last remaining major Fortran 2018 
feature without current support in gfortran (or any other Fortran compiler of 
which I’m aware).  I submitted the first draft of this patch last September. 
Regression tests show no unexpected failures (i.e., the output of ‘grep -w FAIL 
gfortran.sum’ is empty). The Changelogs are below.

Among the details remaining for future commits are the following: support for 
the GET_TEAM intrinsic function is incomplete, the TEAM_NUMBER intrinsic 
function doesn’t yet accept the optional argument, and a SYNC TEAM test is 
needed.  Using any of the unsupported features generates a compile-time error 
message from gfortran or a runtime error message from OpenCoarrays. There are 
no internal compiler errors of which I’m aware.  And there remains one big, 
dissertation-worthy project in handling the use of teams in the presence of 
failed images.

Ok for trunk?

Damian


2018-01-18  Damian Rouson  <dam...@sourceryinstitute.org>
        Alessandro Fanfarillo  <fanfarillo@gmail.com>

        Partial support for Fortran 2018 teams features.

        * array.c (gfc_match_array_ref): add team attribute in coarray
        transfers.
        * check.c (gfc_check_get_team, gfc_check_team_number): add new 
        functions for get_team and team_number.
        * dump-parse-tree.c (show_code_node): add new statements: form team,
        change team, end team, and sync team.
        * expr.c (gfc_find_team_co): add new function.
        * gfortran.h: add new statements.
        * intrinsic.c (add_functions): add get_team and team_number functions.
        * intrinsic.h: add get_team and team_number prototypes for check,
        simplify, and resolve.
        * iresolve.c (gfc_resolve_get_team, gfc_resolve_team_number): add new 
        functions.
        * iso-fortran-env.def: add the team_type derived type.
        * match.c (gfc_match_if, gfc_match_form_team, gfc_match_team_number)
        (gfc_match_end_team, gfc_match_sync_team, gfc_match_change_team):
        add change team, end team, form team, sync team match and functions.
        * match.h: add new prototypes for change team, end team, form team,
        and sync team.
        * parse.c (decode_statement): add cases for change team, end team,
        form team, and sync team.
        * resolve.c: add cases for exec form team, change team, end team, and 
        sync team.
        * simplify.c (gfc_simplify_get_team): add new function for get team.
        * st.c (gfc_free_statement): add cases exec for change team, end team,
        form team, sync team.
        * trans-decl.c (gfor_fndecl_caf_form_team)
        (gfor_fndecl_caf_change_team, gfor_fndecl_caf_end_team)
        (gfor_fndecl_caf_sync_team, gfor_fndecl_caf_get_team)
        (gfor_fndecl_caf_team_number): add functions and definitions.
        * trans-intrinsic.c (conv_caf_send, conv_intrinsic_team_number): add 
        new function and team_type argument support.
        * trans-stmt.c (gfc_trans_form_team, gfc_trans_change_team)
        (gfc_trans_end_team, gfc_trans_sync_team): add new functions.
        * trans-stmt.h: add new prototypes.
        * trans-types.c (gfc_get_derived_type): check condition for team_type.
        * trans.c (trans_code): new exec cases for form team, change team, end 
        team, and sync team.
        * trans.h: add new prototypes.

2018-01-18  Damian Rouson  <dam...@sourceryinstitute.org>
        Alessandro Fanfarillo  <fanfarillo@gmail.com>

        Fortran 2018 teams tests.

        * gfortran.dg/team_number_1.f90: new test for team_number.
        * gfortran.dg/team_change_1.f90: new test for change team.
        * gfortran.dg/team_end_1.f90: new test for end team.
        * gfortran.dg/team_form_1.f90: new test for form team.





teams-patch.diff
Description: Binary data

Re: [PATCH] Implementation of RANDOM_INIT from F2018

[Damian Rouson]

Hi Steve,

Here are the results of compiling with the OpenCoarrays “caf” compiler wrapper, 
which uses -fcoarray=lib -lcaf_mpi:

1. random_init(repeatable=.true., image_distinct=.true.) gives repeatable 
sequences that are distinct on each image.
2. random_init(.true., .false.) gives repeatable sequences that are identical 
on all images.
3. random_init(.false.,.true.) gives non-repeatable sequences that are distinct 
on each image.
4. random_init(.false.,.false.) gives non-repeatable sequences that are 
distinct on each image.

The behavior with test 2 differs from the description in the email below. I 
hope this is helpful.  I can provide the raw output if so desired. 

In case it’s of interest, there’s a script in OpenCoarrays that checks out the 
trunk, applies a provided patch to it, and then does a non-bootstrap build of 
the patched trunk, MPICH, and OpenCoarrays.  These were my steps:

git clone https://github.com/sourceryinstitute/opencoarrays
cd opencoarrays
./developer-scripts/patched-trunk-instal.sh random_init.diff
source prerequisites/installations/setup.sh
caf repeatable-distinct.f90
cafrun -n 4 ./a.out

If you decide to try this, please let me know.  I can edit the above script to 
give an option for multithreaded builds to speed things up quite a bit.

Damian


On January 8, 2018 at 6:03:26 PM, Steve Kargl 
(s...@troutmask.apl.washington.edu) wrote:

On Mon, Jan 08, 2018 at 05:33:01PM -0800, Damian Rouson wrote:  
> I’ll be glad to test with -fcoarray=lib -lcaf_mpi with two caveats:  
>  
> 1. My turnaround time will probably usually be 48-72 hours for  
> such tests.  

Turn around time is unimportant to me. I'm simply interested if  
what I have done work or if I need to fix a bug.  

> 2. I don’t monitor this mailing list very closely so I might miss  
> similar requests unless they are also submitted as issues on the  
> OpenCoarrays GitHub repository.  

That's understandable. There is only so much time in a day.  

> For clarification, are you asking for simple execution of the  
> existing tests or do you suspect that the tests might need  
> modification (or new tests) to exercise the -fcoarray=lib option?  

Hopefully, this clarifies the situation. Suppose, you have a co-array  
program that causes execution of 2 images, say, image0 and image1.  
If the program contains  

call random_init(repeatable=.true., image_distinct=.true.)  

then image0 and image1 will have distinct PRNG sequences. Now, if you  
re-run the program, then image0 and image1 will have the same distinct  
sequences. If you have  

call  random_init(.true., .false.) 

image0 and image1 do not need to have distinct PRNG sequences, but  
I set up gfortran to have distinct sequences. If you re-run the  
program image0 and image1 should have the same sequences. Finally,  
if you have  

call random_init(.false.,.true.)  

image0 and image1 will have distinct sequence, and if you re-run the  
program image and image1 will should have different sequence than  
what was seen in the previous and these are distinct.  

There is one final detail, the standard says that calling random_init  
in one image cannot affect the PRNG sequence in another image if  
image_distinct=.false.  

--  
Steve  

Re: [PATCH] Implementation of RANDOM_INIT from F2018

[Damian Rouson]

I’ll be glad to test with -fcoarray=lib -lcaf_mpi with two caveats:

1. My turnaround time will probably usually be 48-72 hours for such tests.  
2. I don’t monitor this mailing list very closely so I might miss similar 
requests unless they are also submitted as issues on the OpenCoarrays GitHub 
repository.   

For clarification, are you asking for simple execution of the existing tests or 
do you suspect that the tests might need modification (or new tests) to 
exercise the -fcoarray=lib option?

Damian
On January 8, 2018 at 4:58:09 PM, Steve Kargl 
(s...@troutmask.apl.washington.edu) wrote:

On Sun, Jan 07, 2018 at 06:52:22PM -0800, Steve Kargl wrote:  
>  
> I have zero knowledge about co-arrays and especially zero  
> knowledge about gfortran internals for co-arrays. I'm  
> disinclined to waste another 12 hours trying to get gfortran  
> to emit essentially a call to this_image(). See iresolve.c  
> for details.  
>  

An epiphany came to me last night, which has led to the attach  
patch. This patch should be a complete implementation of  
RANDOM_INIT.  

RANDOM_INIT takes two LOGICAL, INTENT(IN) arguments. To  
avoid library bloat, these arguments are converted/casted to  
LOGICAL(4) in trans-intrinsic.c (conv_intrinsic_random_init).  
It is also in this function, that I set up the hidden argument  
that is needed to hopefully give standard conforming behavior  
when co-arrays are involved. I, however, cannot test -fcoarray=lib  
situation. I would appreciate feedback from a co-array user.  

Boostrapped and regression tested on x86_64-*-freebsd.  
OK to commit?  

2018-01-08 Steven G. Kargl   

* check.c (gfc_check_random_init): New function. Check arguments of  
random_init().  
* gfortran.h (gfc_isym_id): Add GFC_ISYM_RANDOM_INIT.  
* intrinsic.c (add_subroutines): Make random_init() an intrinsic  
subroutine.  
(gfc_check_intrinsic_standard): Check for Fortran 2018.  
* intrinsic.h: Add prototypes for gfc_check_random_init and  
gfc_resolve_random_init.  
* iresolve.c (gfc_resolve_random_init): New function. Add  
_gfortran_random_init to list of subroutines.  
* trans-decl.c: Describe gfor_fndecl_random_init.  
* trans-intrinsic.c (conv_intrinsic_random_init): New function.  
Translate random_init and added hidden argument.  
(gfc_conv_intrinsic_subroutine): Call conv_intrinsic_random_init.  
* trans.h: Declare gfor_fndecl_random_init.  

2018-01-08 Steven G. Kargl   

* gfortran.dg/random_init_1.f90: New test.  
* gfortran.dg/random_init_2.f90: New test.  

2018-01-08 Steven G. Kargl   

* gfortran.map: Add _gfortran_random_init to library map.  
* intrinsics/random.c (random_init): Implemenation of random_init.  

--  
steve  

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

[Damian Rouson]

I have now confirmed that the patch works the same for the 7 branch: it doesn’t 
break any previously passing tests.  

Damian

On January 1, 2018 at 9:44:59 AM, Paul Richard Thomas 
(paul.richard.tho...@gmail.com) wrote:

Committed to trunk as revision 256065.  

Damian, it would be good if you would confirm that there are no issues  
with applying the patch to 7-branch.  

Thanks for all the help.  

Paul  

On 28 December 2017 at 19:58, Damian Rouson  
<dam...@sourceryinstitute.org> wrote:  
> I applied the patch the trunk and confirmed that it doesn’t break any 
> previously  
> passing OpenCoarrays tests. Is that sufficient or should I also try applying 
> the  
> patch to the 7 branch?  
>  
> Damian  
>  
>  



--  
"If you can't explain it simply, you don't understand it well enough"  
- Albert Einstein  

Re: [patch, fortran] Implement simplification of minloc and maxloc

[Damian Rouson]

 



On January 2, 2018 at 10:02:01 AM, Paul Richard Thomas 
(paul.richard.tho...@gmail.com(mailto:paul.richard.tho...@gmail.com)) wrote:

> Somewhere, I have a list of situations where finalization is required  
> but not yet implemented. I'll dig it out and post it on the list.  

PR 37336 has a list of about a dozen cases:


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336


I haven’t looked at them, but from experience, I think most cases fail silently 
(i.e., leak memory) as opposed to causing an ICE or a runtime error.


Damian

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

[Damian Rouson]

I applied the patch the trunk and confirmed that it doesn’t break any previously
passing OpenCoarrays tests.  Is that sufficient or should I also try applying 
the 
patch to the 7 branch?

Damian

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

[Damian Rouson]

 
Thanks for the additional information Thomas. It sounds like I should test 
Paul’s patch. I should be able to do so today and will post the results by 
tomorrow. I’m adding OpenCoarrays developer Zaak Beekman to the cc and 
attaching the patch again in case he wants to try it as well. 

Zaak, the full thread is at https://gcc.gnu.org/ml/fortran/ and starts with a 
message from Paul on November 29.

Damian  

On December 27, 2017 at 11:09:29 AM, Thomas Koenig 
(tkoe...@netcologne.de(mailto:tkoe...@netcologne.de)) wrote:

> Hi Damian,
>  
> > Does breaking binary compatibility simply mean that CAF codes will need to 
> > be recompiled (which is fine)
>  
> Well... not really. We are not supposed to break binary compatibility
> in a release. For gcc-8, we have greater freedom because we had to
> do it anyway.
>  
> Now, the interesting question is the impact. If we break binary
> compatibilty for something that never worked anyway or was useless, or
> something that was broken by a gcc-7 regression, I think we're fine.
>  
> If not, well... one possible decision would be to wait for gcc-8 to
> fix this.
>  
> > or does it mean that there will need to be work done on OpenCoarrays
> to support the changes
>  
> This, I don't know, never having looked at the OpenCoarrays source.
>  
> Regards
>  
> Thomas


submit.diff
Description: Binary data

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

[Damian Rouson]

 
Hi Paul,

Does breaking binary compatibility simply mean that CAF codes will need to be 
recompiled (which is fine) or does it mean that there will need to be work done 
on OpenCoarrays to support the changes in this patch (which is unlikely to 
happen soon without new contributors to OpenCoarrays)? If it’s the latter, 
could you make the appropriate changes to OpenCoarrays before committing this? 
We’re still dealing with some regressions that Andre introduced a year ago 
through changes in gfortran that have never been reflected in OpenCoarrays. In 
fact, just within the past week, the number of such regressions was finally 
reduced from 3 to 2 for the first time in many months. I’m hopeful that we can 
continue vectoring toward 0 rather than increasing the number. It’s already the 
case that several projects won’t even beginning evaluating CAF for production 
use until our 2 current regressions get fixed and there’s one project that is 
still stuck using GCC 6 because of the current regressions. We actually had to 
publish results using GCC 6 for that reason (see 
https://github.com/sourceryinstitute/coarray-icar-paw17/blob/master/main.pdf).  

Damian  

On December 27, 2017 at 10:04:13 AM, Thomas Koenig 
(tkoe...@netcologne.de(mailto:tkoe...@netcologne.de)) wrote:

> Hi Paul,
>  
> by the way, the patch is OK for trunk. It is just gcc-7 that I am
> worried about.
>  
> Regards
>  
> Thomas

Re: [Patch] Edit contrib/ files to download gfortran prerequisites

[Damian Rouson]

 


On October 21, 2017 at 11:17:49 AM, Bernhard Reutner-Fischer 
(rep.dot@gmail.com(mailto:rep.dot@gmail.com)) wrote:

>  
> + die "Invoking wget and curl in the 'download_prerequisites' script failed."
>  
> I suggest "Neither wget nor curl found, cannot download tarballs.”

Thanks for the suggestion.  I have now replaced the previous message with your 
suggested one.

>  
> As an open-mpi user i question why this hardcodes MPICH, fwiw.

The primary reason is because Fortran 2015 has features that support the 
writing 
of fault-tolerant parallel algorithms. GCC 7 supports these features using 
OpenCoarrays,
which in turn uses features that are in MPICH 3.2.  I don’t think there is 
anything
comparable in an OpenMPI release yet, although I’m aware that OpenMPI 
developers are
working on it.  

Nonetheless, I would be glad to add a “—-with-mpi” flag that would enable users 
to specify
the MPI of their choice. We could also allow for non-MPI options.  For example, 
OpenSHEM
has been tested as an alternative recently.  Either way, I’m thinking I’ll hold 
off on 
investing any more time in this patch for now.  It seems unlikely to be 
approved for the
trunk until other work completes and it’s uncertain when the other work will 
complete.

Damian

Re: [Patch] Edit contrib/ files to download gfortran prerequisites

[Damian Rouson]

On October 23, 2017 at 3:54:22 AM, Richard Biener (richard.guent...@gmail.com) 
wrote:

On Sat, Oct 21, 2017 at 2:26 AM, Damian Rouson 
<dam...@sourceryinstitute.org> wrote: 
> 
> Hi Richard, 
> 
> Attached is a revised patch that makes the downloading of Fortran 
> prerequisites optional via a new --no-fortran flag that can be passed to 
> contrib/download_prerequisites as requested in your reply below. 
> 
> As Jerry mentioned in his response, he has been working on edits to the 
> top-level build machinery, but we need additional guidance to complete his 
> work. Given that there were no responses to his request for guidance and it’s 
> not clear when that work will complete, I’m hoping this minor change can be 
> approved independently so that this patch doesn’t suffer bit rot in the 
> interim. 

But the change doesn't make sense without the build actually picking up things. 
Each prerequisite tar ball contains build scripts so the change is useful even 
without the ultimate integration into the GCC build system.  Our first step was 
to get the tar balls onto the GCC ftp server.  Our next step was to set up for 
the files to be downloaded automatically with this patch.  For now, users can 
use the build scripts in the prerequisite tar balls.  Our final step will be to 
finish the integration into the GCC build system.   Jerry has requested 
guidance on this mailing list, but I don’t think there have been any replies to 
his request.  In the interim, I’m stuck updating this patch indefinitely.  I’ve 
already updated it several times because the files it patches are changing.  

Most importantly, the features these prerequisites enable are part of the 
Fortran standard so they are necessary for full access to the language — namely 
access to any Fortran 2008 or Fortran 2015 parallel features.  I hope I’ve made 
a case for the benefit of the patch. Is there a way in which the patch is 
harmful?

Damian

Re: [Patch] Edit contrib/ files to download gfortran prerequisites

[Damian Rouson]

 
Hi Richard,

Attached is a revised patch that makes the downloading of Fortran prerequisites 
optional via a new --no-fortran flag that can be passed to 
contrib/download_prerequisites as requested in your reply below. 

As Jerry mentioned in his response, he has been working on edits to the 
top-level build machinery, but we need additional guidance to complete his 
work.  Given that there were no responses to his request for guidance and it’s 
not clear when that work will complete, I’m hoping this minor change can be 
approved independently so that this patch doesn’t suffer bit rot in the interim.

Ok for trunk?

Damian




On September 21, 2017 at 12:40:49 AM, Richard Biener 
(richard.guent...@gmail.com(mailto:richard.guent...@gmail.com)) wrote:

> On Wed, Sep 20, 2017 at 10:35 PM, Damian Rouson
> wrote:
> > Attached is a patch that adds the downloading of gfortran prerequisites 
> > OpenCoarrays and MPICH in the contrib/download_prerequisites script. The 
> > patch also provides a useful error message when neither wget or curl are 
> > available on the target platform. I tested this patch with several choices 
> > for the command-line options on macOS (including --md5 and --sha512) and 
> > Ubuntu Linux (including --sha512). A suggested ChangeLog entry is
> >
> > * contrib/download_prerequisites: Download OpenCoarrays and MPICH.
> > * contrib/prerequisites.sha5: Add sha512 message digests for OpenCoarrays 
> > and MPICH.
> > * contrib/prerequisites.md5: Add md5 message digests for OpenCoarrays and 
> > MPICH.
> >
> >
> > OK for trunk? If so, I’ll ask Jerry to commit this. I don’t have commit 
> > rights.
>  
> Can you make this optional similar to graphite/isl? Also I see no support in
> the toplevel build machinery to build/install the libs as part of GCC
> so how does
> that work in the end?
>  
> Thanks,
> Richard.
>  
> > Damian


downlaod-prereqs.diff
Description: Binary data

[Patch] Edit contrib/ files to download gfortran prerequisites

[Damian Rouson]

Attached is a patch that adds the downloading of gfortran prerequisites 
OpenCoarrays and MPICH in the contrib/download_prerequisites script.  The patch 
also provides a useful error message when neither wget or curl are available on 
the target platform.  I tested this patch with several choices for the 
command-line options on macOS (including --md5 and --sha512) and Ubuntu Linux 
(including --sha512).    A suggested ChangeLog entry is

        * contrib/download_prerequisites: Download OpenCoarrays and MPICH.
        * contrib/prerequisites.sha5: Add sha512 message digests for 
OpenCoarrays and MPICH.
        * contrib/prerequisites.md5: Add md5 message digests for OpenCoarrays 
and MPICH.


OK for trunk?  If so, I’ll ask Jerry to commit this.  I don’t have commit 
rights.

Damian

download-opencoarrays-mpich.diff
Description: Binary data

Re: [Patch, fortran] Parameterized Derived Types

[Damian Rouson]

 
Thanks for your tireless efforts on this, Paul! I look forward to trying this 
out after it hits the trunk.  

Your phrase “last unimplemented F2003” feature bolsters my suspicion that it 
might be ok to switch the features listed as “Partial” on the Fortran wiki to 
“Yes." I suppose the difference depends on developer intent. If the 
developer(s) intended to leave some aspect of a feature unimplemented (as might 
be evidenced by an appropriate compiler message), then “Partial” seems best. 
Otherwise, “Yes” seems appropriate even in the presence of bugs. I’ll send a 
separate email to the list with further thoughts on this.  


Best Regards,  
___  
Damian Rouson, Ph.D., P.E.
President, Sourcery Institute
www.sourceryinstitute.org(http://www.sourceryinstitute.org)
+1-510-600-2992 (mobile)



On September 6, 2017 at 6:04:47 AM, Paul Richard Thomas 
(paul.richard.tho...@gmail.com(mailto:paul.richard.tho...@gmail.com)) wrote:

> Dear All,
>  
> Since my message to the list of 16 August 2017 I have put in another
> intense period of activity to develop a patch to implement PDTs in
> gfortran. I have now temporarily run out of time to develop it
> further; partly because of a backlog of other patches and PRs to deal
> with but also pressure from daytime work.
>  
> The patch adds the last unimplemented F2003 feature to gfortran.
>  
> As in the provisional patch, I have attached some notes on the
> implementation. This indicates some of the weaknesses, problem areas
> and TODOs.
>  
> Suggest that a good read of Mark Leair's excellent PGInsider article
> on PDTs - http://www.pgroup.com/lit/articles/insider/v5n2a4.htm is a
> worthwhile exercise.
>  
> To judge by the complete silence following my previous message, I will
> have a problem getting this patch reviewed. I would welcome any
> remarks or reviews but intend to commit, warts and all, on Saturday
> unless something fundamentally wrong comes out of the woodwork.
>  
> Note that the PDT parts in the compiler are rather well insulated from
> the rest of fortran and that I do not believe that any regressions
> will result.
>  
> I hope that a month or two of testing in other hands will add to the
> list of TODOs and that when I return to PDTs a greatly improved
> version will result.
>  
> Bootstrapped and regtested on FC23/x86_4 - OK for trunk? (Note above
> remark about committing on Saturday in the absence of a review.)
>  
> Best regards
>  
> Paul
>  
> 2017-09-05 Paul Thomas  
>  
> * decl.c : Add decl_type_param_list, type_param_spec_list as
> static variables to hold PDT spec lists.
> (build_sym): Copy 'type_param_spec_list' to symbol spec_list.
> (build_struct): Copy the 'saved_kind_expr' to the component
> 'kind_expr'. Check that KIND or LEN components appear in the
> decl_type_param_list. These should appear as symbols in the
> f2k_derived namespace. If the component is itself a PDT type,
> copy the decl_type_param_list to the component param_list.
> (gfc_match_kind_spec): If the KIND expression is parameterized
> set KIND to zero and store the expression in 'saved_kind_expr'.
> (insert_parameter_exprs): New function.
> (gfc_insert_kind_parameter_exprs): New function.
> (gfc_insert_parameter_exprs): New function.
> (gfc_get_pdt_instance): New function.
> (gfc_match_decl_type_spec): Match the decl_type_spec_list if it
> is present. If it is, call 'gfc_get_pdt_instance' to obtain the
> specific instance of the PDT.
> (match_attr_spec): Match KIND and LEN attributes. Check for the
> standard and for type/kind of the parameter. They are also not
> allowed outside a derived type definition.
> (gfc_match_data_decl): Null the decl_type_param_list and the
> type_param_spec_list on entry and free them on exit.
> (gfc_match_formal_arglist): If 'typeparam' is true, add the
> formal symbol to the f2k_derived namespace.
> (gfc_match_derived_decl): Register the decl_type_param_list
> if this is a PDT. If this is a type extension, gather up all
> the type parameters and put them in the right order.
> *dump-parse-tree.c (show_attr): Signal PDT templates and the
> parameter attributes.
> (show_components): Output parameter atrributes and component
> parameter list.
> (show_symbol): Show variable parameter lists.
> * expr.c (expr.c): Copy the expression parameter list.
> (gfc_is_constant_expr): Pass on symbols representing PDT
> parameters.
> (gfc_check_init_expr): Break on PDT KIND parameters and
> PDT parameter expressions.
> (gfc_check_assign): Assigning to KIND or LEN components is an
> error.
> (derived_parameter_expr): New function.
> (gfc_derived_parameter_expr): New function.
> (gfc_spec_list_type): New function.
> * gfortran.h : Add enum gfc_param_spec_type. Add the PDT attrs
> to

Re: port contrib/download_prerequisites script to macOS

[Damian Rouson]

Resending as plain text:

 On April 12, 2017 at 3:03:19 PM, Jeff Law 
(l...@redhat.com(mailto:l...@redhat.com)) wrote:
 
 > > 
 > > 2017-04-05 Damian Rouson 
 > > 
 > > * download_prerequisites (md5_check): New function emulates Linux 
 > > 'md5 --check' on macOS. Modified script for macOS compatibility. 
 > I wonder if we should just switch to curl from wget in general rather 
 > than conditionalizing the code at all. 
 
 Hi Jeff,
 
 
Thanks for your comments. The conditionals are more portable than hardwiring 
one choice. On macOS, curl is always present but not wget. On the Linux 
distribution that I use (Lubuntu), wget is always present but curl isn’t 
installed by default. My goal was to support as many users as possible without 
requiring them to install prerequisites just to download the prerequisites. :) 
As my first contribution of a patch to GCC, I took the baby step of allowing 
for the use of curl. If acceptable, my next step would be to allow for the use 
of ftp when neither curl nor wget is present. That’s what I do in the scripts 
from which I culled the code in the patch. In those scripts, I invoke ftp via 
the following function: 
 
https://github.com/sourceryinstitute/OpenCoarrays/blob/master/prerequisites/build-functions/ftp_url.sh
 
 > 
 > 
 > For the sums, rather than doing a check of the OS, just see if  
 > sha512/md5sum exists. If not, then fallback to the Darwin defaults. 
 
I think I tried that first and ran into some difficulties. I’ll make another 
attempt. My recent shell programming experience is with the bash shell and I 
have some experience with the C-shell from years ago, but I had no experience 
with writing Bourne shell scripts before writing this patch and I think the 
problem I encountered was related to differences between Bourne and bash.
 
 
 Damian

port contrib/download_prerequisites script to macOS

[Damian Rouson]

All,

The attached patch modifies the contrib/download_prerequisites script to work 
on macOS. 
The revised script detects the operating system and adjusts the shasum and md5 
commands 
to their expected name and arguments on macOS.  The revised script also uses 
curl if 
wget is not present.  macOS ships with curl but not wget.

Tested on macOS and Lubuntu and Fedora Linux distributions. 

Ok for trunk?

Damian


2017-04-05  Damian Rouson  <dam...@sourceryinstitute.org>

        * download_prerequisites (md5_check): New function emulates Linux
        'md5 --check' on macOS.  Modified script for macOS compatibility.



macOS-download_prerequisites.diff
Description: Binary data

Re: New prerequisites to support multi image COARRAY in gfortran

[Damian Rouson]

 



On April 4, 2017 at 9:48:23 AM, Jerry DeLisle 
(jvdeli...@charter.net(mailto:jvdeli...@charter.net)) wrote:

> Gerald, (or who does this)  
>  
> Since shared memory parallel programming with Fortran is now a Standard 
> feature  
> of the language, we would like to support full parallelism through the use of 
>  
> mpich and OpenCorrays.  


Clarification: Fortran’s parallel programming model is agnostic about the 
memory architecture. The 2008 standard made Fortran the only widely used 
language with a parallel programming model that works in shared- or 
distributed-memory systems.  I’ve seen papers in which people have run coarray 
Fortran (CAF) on over 100,000 cores with impressive results.

As a side note, the draft 2015 standard makes Fortran also the only widely used 
language with support for fault tolerance, which makes Alessandro’s and Andre’s 
work on failed-image support truly exciting and I’m amazed that there already 
exists an MPI limitation with some support for what is needed to support 
failed-image detection. 

Damian

Re: New prerequisites to support multi image COARRAY in gfortran

[Damian Rouson]

 
Resending as plain text (although now I realize my reply is at least partially 
redundant since reading Andre’s email):

On April 4, 2017 at 10:44:09 AM, FX 
(fxcoud...@gmail.com(mailto:fxcoud...@gmail.com)) wrote:

> > We choose mpich as a default only because it is very stable.
>  
> Why are why tying ourselves to one MPI implementation?
>  


Jerry’s request is just to put an MPICH tar ball on the GCC ftp server as a 
default.  When we modify “configure,” there will be a --with-mpi option that 
enables users to choose their own MPI implementation. 

Damian

Re: Ping : [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)

[Damian Rouson]

 



On August 27, 2016 at 1:15:51 PM, Janne Blomqvist 
(blomqvist.ja...@gmail.com(mailto:blomqvist.ja...@gmail.com)) wrote:
>  
> Anyway, a small nit I found was the function st_set_nml_var in
> libgfortran. This is an exported function, and thus part of the ABI.
> So you cannot add arguments to it, as that would break backwards
> compatibility. I suggest you make a new function (say,
> st_set_nml_var2, or whatever), and make the old one a simple wrapper
> that calls the new one with the additional arguments set to null.
>

As another small nit, I hope the chosen name is more descriptive than one 
obtained by appending “2” to the name. :)

Damian

Update GCC 6 release page

[Damian Rouson]

The patch below expands the list of new Fortran support for the GCC 6 Release 
Series Changes, New Features, Fixes page at 
.https://gcc.gnu.org/gcc-6/changes.html.  Please let me know whether this is 
acceptable and will be applied.

Damian

--- original.html   2016-05-03 22:25:23.0 -0700
+++ update.html 2016-05-03 22:42:21.0 -0700
@@ -366,6 +366,10 @@
 
 Fortran
   
+Fortran 2008 SUBMODULE support.
+Fortran 2015 EVENT_TYPE, EVENT_POST, 
EVENT_WAIT, and EVENT_QUERY support.
+Improved support for Fortran 2003 deferred-length character variables.
+Improved support for OpenMP and OpenACC.
 The MATMUL intrinsic is now inlined for straightforward
   cases if front-end optimization is active.  The maximum size for
   inlining can be set to n with the

Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

[Damian Rouson]

> On Apr 3, 2016, at 3:04 PM, Andre Vehreschild  wrote:
> 
> Hi Damian,
> 
> To say it quite bluntly, I don't know. I took care of the ICE only, but I 
> don't have a deeper understanding of the coarray usage, therefore I can't 
> answer your question.

Hi Andre,

No problem.  Thanks for the quick reply.

> What should the meaning of the line in question be? Doesn't it overwrite the 
> allocated reference with the one of image 1? And how would you expect to 
> continue from there?

It’s just a check to see what the compiler will do.  It could be thought of as 
a poorly written broadcast.  To be a correct broadcast, it would require a 
“sync all” just after the first assignment. Then the second assignment would 
give every image a copy of the caf component that was on image 1, which has an 
x component with the value 1.   Even with this correction, it would of course 
exhibit poor scaling due to network contention and it would be better to call 
co_broadcast.  

I just wrote it to see if there had been additional progress toward supporting 
derived type coarrays with allocatable or pointer components.  If so, that will 
be of great interest to the users of OpenCoarrays and I would announce it on 
the OpenCoarrays mailing list.

Damian

Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

[Damian Rouson]

Hi Andre,

Thanks for submitting this patch .  What can a program do with the object after 
it has been allocated?  Below is a simplified version of the code submitted in 
pr65795 and the compile-time error that results from attempting accessing the 
co-indexed component of the allocated object.  Does the patch address this 
error?

Damian

$ cat bug65795.f90 
implicit none

type t2
  integer, allocatable :: x
end type t2

type t3
  type(t2), allocatable :: caf[:]
end type t3

type(t3) :: c

allocate(c%caf[*])
c%caf%x = this_image()
c%caf = c%caf[1]
end

$ caf bug65795.f90 
bug65795.f90:15:8:

 c%caf = c%caf[1]
1
Error: Sorry, coindexed coarray at (1) with allocatable component is not yet 
supported

$ gfortran --version
GNU Fortran (MacPorts gcc6 6-20160306_0) 6.0.0 20160306 (experimental)




> On Apr 3, 2016, at 6:35 AM, Andre Vehreschild <ve...@gmx.de> wrote:
> 
> Hi all,
> 
> attached patch fixes a segfault when allocating a coarray of a type
> that has allocatable components. Before the patch the compiler tried
> to ref the component to nullify from the coarray's base address and not
> from its .data component. The proposed patch fixes this by preventing
> the nullify of the components in the array_allocate() for coarrays,
> because the components are nullified again afterwards by copying a
> fully nullified copy of the type to the coarray's data component.
> 
> There albeit is an alternative to this patch:
> 
> trans-array.c: 5556+
> 
> -   tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, se->expr,
> +   tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, coarray ?
> + pointer : se->expr, 
> ref->u.ar.as->rank);
> 
> The above adds a second nullify to the generated code before the one
> done the object copy mentioned above. 
> 
> Because I am unsure which patch is best, I propose both. I do favor of
> course the one without the duplicate nullify as attached.
> 
> Bootstrapped and regtested ok on x86_64-linux-gnu/F23. Ok for trunk?
> 
> The patch also applies (with a small delta) to gcc-5 w/o any
> regressions. Ok for gcc-5-branch?
> 
> Regards,
>   Andre
> -- 
> Andre Vehreschild * Email: vehre ad gmx dot de 
> 


Damian Rouson, Ph.D., P.E.
President, Sourcery Institute
http://www.sourceryinstitute.org
+1-510-600-2992 (mobile)

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

[Damian Rouson]

> On Nov 25, 2015, at 9:24 AM, Alessandro Fanfarillo  
> wrote:
> 
> Dear all,
> 
> in attachment the previous patch compatible with the current trunk.
> The patch also includes the changes introduced in the latest TS 18508.
> 
> Built and regtested on x86_64-pc-linux-gnu.
> 
> PS: I will add the test cases in a different patch.

All,

As I mentioned previously, WG5 approved the latest TS 18508 document in 
September and forwarded it to SC22 for approval for publishing so it is 
essentially final.  This is an opportune time to commit the feature. I believe 
it also puts gfortran in the lead on Fortran 2015 parallel programming support. 
 I don’t think even the Cray compiler supports EVENTs yet.  Hopefully this is 
ok for committing during Stage 3 given that the original version of the patch 
was submitted by Tobias in April.

This feature could have significant, positive impact on parallel performance so 
it will be exciting to see it hit the trunk.  If it gets committed before my 
next short course, December 7-8, then I’ll incorporate some discussion of 
EVENTs into the course.

Damian

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Damian Rouson]

I love this idea and had similar thoughts as well.  

:D 

Sent from my iPhone

 On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas 
 paul.richard.tho...@gmail.com wrote:
 
 Dear Mikael,
 
 It had crossed my mind also that a .mod and a .smod file could be
 written. Normally, the .smod files are produced by the submodules
 themselves, so that their descendants can pick up the symbols that
 they generate. There is no reason at all why this could not be
 implemented; early on in the development I did just this, although I
 think that it would now be easier to modify this patch.
 
 One huge advantage of proceeding in this way is that any resulting
 library can be distributed with the .mod file alone so that the
 private entities are never exposed. The penalty is that a second file
 is output.
 
 With best regards
 
 Paul
 
 On 23 July 2015 at 17:42, Mikael Morin mikael.mo...@sfr.fr wrote:
 Hello Paul,
 
 Le 23/07/2015 09:46, Paul Richard Thomas a écrit :
 
 Since all the private entities in a module have to be transmitted to
 their descendant submodules, whilst keeping them hidden from normal
 use statements, I have chosen to write the module file as usual and
 add a second part that contains the private entities. This latter is
 only read when processing submodule statements.
 why not write them to the/a .smod file?  It was its primary purpose, wasn't
 it?
 [Sorry, I followed the submodule stuff very remotely].
 
 It's probably bad practice to put private entities in module files, at least
 now that submodules are supported.  Nevertheless with your change,
 modifications made to private entities produce recompilation cascades, even
 though the public interfaces are left unchanged.
 
 Mikael
 
 
 
 -- 
 Outside of a dog, a book is a man's best friend. Inside of a dog it's
 too dark to read.
 
 Groucho Marx

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Damian Rouson]

 On Jul 23, 2015, at 12:46 AM, Paul Richard Thomas 
 paul.richard.tho...@gmail.com wrote:
 
 Since all the private entities in a module have to be transmitted to
 their descendant submodules, whilst keeping them hidden from normal
 use statements, I have chosen to write the module file as usual and
 add a second part that contains the private entities. This latter is
 only read when processing submodule statements.

Hi Paul,

Could you comment on whether this approach alleviates compilation cascades as 
seems to have been envisioned when submodules were added to the standard?  My 
guess is that a developer could adopt a policy of putting only public 
information in a
module and reserving all private information for submodules, which would 
mitigate
against unnecessary compilation cascades and would be consistent with putting
the interface in the module and the implementation in a submodule.. 

 It does cross my mind that all of this part of the submodule
 implementation could be subject to the condition that a compiler
 option is set. I am struck by the notion that making private module
 entities available to submodules is an unnecessary complication and
 that it amounts to be an error in the standard. This is why I am
 suggesting the possibility of a specific compiler option.

I strongly advocate against having to pass flags to force standard-compliant 
behavior 
(I happened to have just posted to c.l.f on a frustrating way in which two 
compilers
currently require flags to comply with the standard), although it sounds like 
it might 
not matter in this case if one adopts the aforementioned policy 
of putting only pubic information in modules.

Damian

Re: [Fortran, Patch] Passing function pointer to co_reduce

[Damian Rouson]

Thank you!

Damian

 On Jul 17, 2015, at 9:50 AM, Mikael Morin mikael.mo...@sfr.fr wrote:
 
 Le 17/07/2015 11:02, Mikael Morin a écrit :
 Le 16/07/2015 16:34, Damian Rouson a écrit :
 Alternatively, if it’s easy, please feel free to add the directives and 
 commit.  
 
 
 Never mind, I'll take care of it all.
 
 This is what I have committed:
 https://gcc.gnu.org/r225930 (trunk)
 https://gcc.gnu.org/r225932 (5 branch)
 
 Mikael
 r225930.diff

Re: [Fortran, Patch] Passing function pointer to co_reduce

[Damian Rouson]

 On Jul 15, 2015, at 8:58 AM, Mikael Morin mikael.mo...@sfr.fr wrote:
 
 The patch itself looks good to me.
 A ChangeLog entry should be provided with it.
 The test is missing the usual dejagnu pattern matching directives to
 check the generated code.
 Do you have commit rights?

Hi Mikael,

Thanks for the quick review.   I know Alessandro is not a reviewer. Assuming 
commit rights go with review rights, I’m guessing he doesn’t have commit 
rights.  I’ll let him confirm.  If he doesn’t have commit rights, could you 
commit it for us after he adds the derange pattern-matching directives?  
Alternatively, if it’s easy, please feel free to add the directives and commit. 
 

Your fast response is very helpful to us.  The co_reduce collective is the 
final feature that we hope to finish before taking a snapshot of OpenCoarrays 
and designating it as our 1.0.0 release. :)   Toward that end, could this fix 
also be applied to the GCC 5 branch?  Soon after posting a tar ball of 
OpenCoarrays 1.0.0 on the web, Alessandro will submit a Portfile to the 
Macports developers that will enable OS X users to install OpenCoarrays 1.0.0 
for use with GCC 5. It would be great for Macports users to have co_reduce when 
the next GCC 5 update releases.

Damian

Re: [Patch, fortran, PR44672, v9] [F08] ALLOCATE with SOURCE and no array-spec

[Damian Rouson]

All, 

I sincerely hope this patch will hit the trunk soon.  There are 9 users on the 
cc list for this bug so it is clearly of considerable user interest.I was 
recently informed that the following three-line program does not compile:

$ cat source-allocation.f90 
  integer, allocatable :: x(:)
  allocate(x,source=[1])
end

$ gfortran source-allocation.f90 
source-allocation.f90:2:11:

   allocate(x,source=[1])
   1
Error: Array specification required in ALLOCATE statement at (1)

$ gfortran --version
GNU Fortran (GCC) 6.0.0 20150607 (experimental)

I was heartened to find out from the initial bug report that it’s a Fortran 
2008 feature, which makes the behavior somewhat understandable, but it’s a 
fairly simple use case that I would imagine will be used widely.  FYI, the 
above three-line program compiles and executes cleanly with the NAG, Cray, 
Intel, and Portland Group compilers.


Damian Rouson, Ph.D., P.E.
Founder  President, Sourcery, Inc.
510-600-2992 (mobile)
http://www.sourceryinstitute.org
http://rouson.youcanbook.me

 On Jun 5, 2015, at 4:04 AM, Andre Vehreschild ve...@gmx.de wrote:
 
 Hi all,
 
 attached is the most recent version of the patch. It addresses the standard
 violation of allocate(foo, source=[bar(something)]), where foo after the
 allocate was a zero-based array instead of a one-based. Furthermore does this
 patch fix calling _vptr-_copy () routines, which come without an interface
 specification leading to pass all arguments by reference. When copying a
 deferred length string this is hazardous, because a __copy_character_* ()
 routines third and fourth arguments are passed by value. This is fixed by
 simply counting the actual arguments and using pass by value for third and
 fourth to _copy routine.
 
 Bootstraps and regtests ok on x86_64-linux-gnu/f21.
 
 Ok for trunk?
 
 - Andre
 -- 
 Andre Vehreschild * Email: vehre ad gmx dot de 
 pr44672_9.clogpr44672_9.patch