Re: [Patch] OpenMP/Fortran: Handle polymorphic scalars in data-sharing FIRSTPRIVATE [PR86470]
*PING* (OpenMP patches: I note that the reduction + firstprivate→tofrom patch is still being reviewed and that there are bunch of recently posted patches by ChungLin + Julian which are also pending review.) (There is also one patch (affinity + iterator) I still have to repost – and will happen soon.) Tobias On 10.03.21 11:55, Tobias Burnus wrote: Belated follow-up to the patch from August ... https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552588.html This patch handles CLASS variables in the FIRSTPRIVATE data-sharing clause, including freeing the memory at the end. Technically this patch fixes a regression as the ICE is new – before the code was just rejected. It is also rather contained. OK for mainline? Tobias PS: The dtor can be extended rather simply to support arrays, for the copy_ctor, some scalarization loop is needed. Todo: 'private', which has to allocate the dynamic type and copy the default initialization for this the dynamic type. - Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf
[Patch, committed] fortran/intrinsic.texi: Use proper variable name (Re: online doc corr.)
Hi Johannes, hi all,
On 22.05.21 23:06, Johannes Nendwich via Gcc wrote:
https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gfortran/ATOMIC_005fADD.html#ATOMIC_005fADD
"ATOMIC_ADD(ATOM, VALUE) atomically adds the value of VAR to the
variable ATOM."
--> "... adds the value of VALUE ..." ?
Indeed – and the same a bit later in ATOMIC_FETCH_ADD.
Now fixed on mainline (GCC 12, commit
r12-1002-g5d3ef9189a7c57679b5fb06e51c90479df0548b0, cf. attachment) and
on GCC 11 (commit r11-8458-g9ee61d2b51df012c659359873637cc2162ecccf3).
Thanks for the report!
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
commit 5d3ef9189a7c57679b5fb06e51c90479df0548b0
Author: Tobias Burnus
Date: Sun May 23 11:56:39 2021 +0200
fortran/intrinsic.texi: Use proper variable name
gcc/fortran/ChangeLog:
* intrinsic.texi (ATOMIC_ADD, ATOMIC_FETCH_ADD): Use the
proper variable name in the description.
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index a62508745fd..ad164137986 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -1870,7 +1870,7 @@ Inverse function: @gol
@table @asis
@item @emph{Description}:
-@code{ATOMIC_ADD(ATOM, VALUE)} atomically adds the value of @var{VAR} to the
+@code{ATOMIC_ADD(ATOM, VALUE)} atomically adds the value of @var{VALUE} to the
variable @var{ATOM}. When @var{STAT} is present and the invocation was
successful, it is assigned the value 0. If it is present and the invocation
has failed, it is assigned a positive value; in particular, for a coindexed
@@ -2090,7 +2090,7 @@ end program atomic
@table @asis
@item @emph{Description}:
@code{ATOMIC_FETCH_ADD(ATOM, VALUE, OLD)} atomically stores the value of
-@var{ATOM} in @var{OLD} and adds the value of @var{VAR} to the
+@var{ATOM} in @var{OLD} and adds the value of @var{VALUE} to the
variable @var{ATOM}. When @var{STAT} is present and the invocation was
successful, it is assigned the value 0. If it is present and the invocation
has failed, it is assigned a positive value; in particular, for a coindexed
Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran
Hi Martin, thanks for pointing that out. I haven't committed for quite some time now and could not find on the webpage how this works nowadays. I was thinking that the special gcc-git-command should have added the Changelog entries automagically and immediately. That they are added by a daily bump is new to me. Thanks for giving me more insight. So do I need to revert the commit c4771b3438a8cd9afcef1762957b763f8df3fa6e to fix the Changelogs or how do we proceed from here? Is there a webpage which describes the current state-of-art of committing to gcc for folks that do not follow every discussion on the mailing lists? Thanks for your help, Andre On Sat, 22 May 2021 19:58:57 +0200 Martin Liška wrote: > On 5/22/21 1:39 PM, Andre Vehreschild via Gcc-patches wrote: > > Hi Steve and Jerry, > > > > thanks for the ok'ing. > > > > Committed as https://gcc.gnu.org/g:26ca6dbda23bc6dfab96ce07afa70ebacedfaf9c > > and https://gcc.gnu.org/g:c4771b3438a8cd9afcef1762957b763f8df3fa6e (for the > > missing changelog entries). > > Hello. > > About the missing changelog entries. The will be added automatically by Daily > bump. You can check it with: > ./contrib/gcc-changelog/git_check_commit.py > 26ca6dbda23bc6dfab96ce07afa70ebacedfaf9c -p > > What's missing for you so that you pushed > c4771b3438a8cd9afcef1762957b763f8df3fa6e? > > Thanks, > Martin > > > > > - Andre > > > > On Fri, 21 May 2021 19:38:00 -0700 > > Jerry D wrote: > > > >> yes, please commit > >> > >> On 5/21/21 8:08 AM, Steve Kargl via Fortran wrote: > >>> On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote: > Ping, ping! > > Please find attached a rebased version of the patch for the RANDOM_INIT > issue with coarray Fortran. Nothing changed to the previous version, just > rebased to current master. > > Regtested fine on x86_64-linux/f33. Ok for trunk? > > >>> I think you've down your due diligence with 2 pings. > >>> I would commit. > >>> > >> > > > > > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran
On 5/23/21 1:59 PM, Andre Vehreschild wrote: Hi Martin, thanks for pointing that out. I haven't committed for quite some time now and could not find on the webpage how this works nowadays. I was thinking that the special gcc-git-command should have added the Changelog entries automagically and immediately. That they are added by a daily bump is new to me. Thanks for giving me more insight. Sure, I'm fully aware that occasional committers are not aware of that. So do I need to revert the commit c4771b3438a8cd9afcef1762957b763f8df3fa6e to fix the Changelogs or how do we proceed from here? I've just done that. Is there a webpage which describes the current state-of-art of committing to gcc for folks that do not follow every discussion on the mailing lists? It's documented here: https://gcc.gnu.org/codingconventions.html#ChangeLogs But it's far from a good location. I'm going to improve it. Cheers, Martin Thanks for your help, Andre On Sat, 22 May 2021 19:58:57 +0200 Martin Liška wrote: On 5/22/21 1:39 PM, Andre Vehreschild via Gcc-patches wrote: Hi Steve and Jerry, thanks for the ok'ing. Committed as https://gcc.gnu.org/g:26ca6dbda23bc6dfab96ce07afa70ebacedfaf9c and https://gcc.gnu.org/g:c4771b3438a8cd9afcef1762957b763f8df3fa6e (for the missing changelog entries). Hello. About the missing changelog entries. The will be added automatically by Daily bump. You can check it with: ./contrib/gcc-changelog/git_check_commit.py 26ca6dbda23bc6dfab96ce07afa70ebacedfaf9c -p What's missing for you so that you pushed c4771b3438a8cd9afcef1762957b763f8df3fa6e? Thanks, Martin - Andre On Fri, 21 May 2021 19:38:00 -0700 Jerry D wrote: yes, please commit On 5/21/21 8:08 AM, Steve Kargl via Fortran wrote: On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote: Ping, ping! Please find attached a rebased version of the patch for the RANDOM_INIT issue with coarray Fortran. Nothing changed to the previous version, just rebased to current master. Regtested fine on x86_64-linux/f33. Ok for trunk? I think you've down your due diligence with 2 pings. I would commit. -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH] PR fortran/100551 - [11/12 Regression] Passing return value to class(*) dummy argument
Hi Harald, I meant to deal with this myself since I am the guilty party. However, the last two weeks have been taken up by a house move and so gfortran has been on the backburner. The patch looks good and seems to do the job - OK for master and 11-branch. Thanks a million for dealing with it! Paul PS If I walk 200m I can now see the "dreaming spires" of Oxford! Better still, there are no fewer than three very good pub/restaurants within walking distance :-) On Thu, 20 May 2021 at 23:22, Harald Anlauf via Fortran wrote: > The fix for PR93924/5 has caused a regression for code such as given > in the present PR. This can be remedied by adjusting the check when > to invoke the implicit conversion of actual argument to an unlimited > polymorphic procedure argument. > > Regtested on x86_64-pc-linux-gnu. > > OK for mainline and backport to 11-branch? > > Thanks, > Harald > > > Fortran: fix passing return value to class(*) dummy argument > > gcc/fortran/ChangeLog: > > PR fortran/100551 > * trans-expr.c (gfc_conv_procedure_call): Adjust check for > implicit conversion of actual argument to an unlimited polymorphic > procedure argument. > > gcc/testsuite/ChangeLog: > > PR fortran/100551 > * gfortran.dg/pr100551.f90: New test. > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
