[wwwdocs][Patch] gcc-15/changes: Fortran + offload (C++) update | project/gomp: GCC 15 update
Hi all,
@Fortraners: Comments to the added 'do concurrent' item?
@Thomas: Are you fine with this C++ wording?
@Andrew: Likewise for C++ and ROCm bump?
Anyone: comments are welcome.
Affected pages:
* https://gcc.gnu.org/gcc-15/changes.html
* https://gcc.gnu.org/projects/gomp/
Cheers,
Tobias
gcc-15/changes: Fortran + offload (C++) updated | project/gomp: GCC 15 update
* The C++ support with offloading was extended; mention it under general
improvements and for Nvptx/GCN (as libstdc++ is now build by default).
* Generic support for AMD GPU required ROCm 6.4.0 - now released, we can
name that version.
* Fortran: 'do concurrent' locality-spec are now supported (local, local_init,
shared, reduce, default(none).
In projects/gomp, the impl.status links have been updated, esp. for GCC 15/16.
htdocs/gcc-15/changes.html | 15 ---
htdocs/projects/gomp/index.html | 10 ++
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index b4200df3..4e3c9b73 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -69,7 +69,8 @@ a work-in-progress.
For offloading using OpenMP and OpenACC, issues preventing some
host–device architecture combinations have been resolved. In particular,
-offloading from aarch64 hosts to nvptx devices is now supported.
+offloading from aarch64 hosts to nvptx devices is now supported. Additionally,
+the support for using C++ in offload regions has been extended.
Improvements for compiling very large input files. The compile time for
@@ -592,6 +593,10 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
Fortran
+
+Fortran 2018 and 2023 locality specifiers to do concurrent are
+now supported.
+
Experimental support for unsigned modular integers,
enabled by -funsigned;
@@ -665,6 +670,8 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
AMD GPU (GCN)
+ The standard C++ library (libstdc++) is now supported
+and enabled.
Experimental support for supporting generic devices has been added;
specifying gfx9-generic, gfx10-3-generic,
or gfx11-generic to
@@ -678,8 +685,8 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
gfx1101, gfx1102, gfx1150,
and gfx1151. To use any of the listed new devices including
the generic ones, GCC has to be configured to build the runtime library
-for the device. Note that generic support requires a future ROCm (newer
-than 6.3.2). For details, consult GCC's
+for the device. Note that generic support requires ROCm 6.4.0 (or newer).
+For details, consult GCC's
https://gcc.gnu.org/install/specific.html#amdgcn-x-amdhsa";>
installation notes.
Support for Fiji (gfx803) devices has been removed (this was already
@@ -833,6 +840,8 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
NVPTX
+ The standard C++ library (libstdc++) is now supported
+and enabled.
GCC's nvptx target now supports constructors and destructors.
For this, a recent version of https://gcc.gnu.org/install/specific.html#nvptx-x-none";
diff --git a/htdocs/projects/gomp/index.html b/htdocs/projects/gomp/index.html
index dcb56a50..07b872ef 100644
--- a/htdocs/projects/gomp/index.html
+++ b/htdocs/projects/gomp/index.html
@@ -144,12 +144,14 @@ filing a bug report.
Implementation status in libgomp manual:
https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Implementation-Status.html";
->Mainline (GCC 15),
-https://gcc.gnu.org/onlinedocs/gcc-14.1.0/libgomp/OpenMP-Implementation-Status.html";
+>Mainline (GCC 16),
+https://gcc.gnu.org/onlinedocs/gcc-15.1.0/libgomp/OpenMP-Implementation-Status.html";
+>GCC 15,
+https://gcc.gnu.org/onlinedocs/gcc-14.2.0/libgomp/OpenMP-Implementation-Status.html";
>GCC 14,
-https://gcc.gnu.org/onlinedocs/gcc-13.2.0/libgomp/OpenMP-Implementation-Status.html";
+https://gcc.gnu.org/onlinedocs/gcc-13.3.0/libgomp/OpenMP-Implementation-Status.html";
>GCC 13,
-https://gcc.gnu.org/onlinedocs/gcc-12.3.0/libgomp/OpenMP-Implementation-Status.html";
+https://gcc.gnu.org/onlinedocs/gcc-12.4.0/libgomp/OpenMP-Implementation-Status.html";
>GCC 12.
Disclaimer: A feature might be only fully supported in a later GCC version
Re: [wwwdocs][Patch] gcc-15/changes: Fortran + offload (C++) update | project/gomp: GCC 15 update
On 17/04/2025 15:10, Tobias Burnus wrote: Hi all, @Fortraners: Comments to the added 'do concurrent' item? @Thomas: Are you fine with this C++ wording? @Andrew: Likewise for C++ and ROCm bump? This part is fine with me. Andrew Anyone: comments are welcome. Affected pages: * https://gcc.gnu.org/gcc-15/changes.html * https://gcc.gnu.org/projects/gomp/ Cheers, Tobias
[Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support (was: Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support)
Hi Jerry,
thanks for the review and sorry for the long delay. With publishing the team's
patches for gfortran, I also created a pull request for OpenCoarrays. There I
was asked to add some testcase with more "beef" in it. I.e. something that
really makes use of teams and not only smoke tests it. This unfortunately made
me discover some issues, that I needed to fix. The attached patch 6/5
addresses these issues. Some of them were as easy as not being able to exit out
of change team block or an end team with a label not being parsed correctly and
not generated in resulting binary. Others were more subtle, like having to
create coarray tokens for association in the change team.
The attached patch addresses all these issues and
bootstraps and regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Btw, do I still merge to master, or am I to wait for the bump to 16th master?
Regards,
Andre
On Sun, 13 Apr 2025 18:40:44 -0700
Jerry D wrote:
> On 4/10/25 5:59 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > I again have a series of patches. This time to improve the teams support in
> > gfortran.
> >
> > 1/5: Improves/Unifies handling of STAT= and ERRMSG= handling, which is part
> > of all TEAM statements. I wanted to prevent repeating myself over and over
> > so I factored this out (DRY principle). Because the standard's rule name
> > for this is sync_stat the structure to store the information in gfc_code is
> > named like that.
> >
> > 2/5: Rework (FORM|CHANGE|END|SYNC) TEAM and CRITICAL to use sync_stat and
> > adhere to F2018 standard as much as possible. Because CHANGE TEAM has kind
> > of an association list (but for coarrays only), I choose to factor out that
> > parsing and other preparations from ASSOCIATE. Added support to caf_single
> > for testing.
> >
> > 3/5: Update/Implement get_team()/team_number() and image_status() parsing
> > and also add testcases as well as support in caf_single.
> >
> > 4/5: Update this_image() parsing and treatment as well as adding testcases
> > and support in caf_single.
> >
> > 5/5: Update image_index() and num_images() support also in caf_single.
> >
> > All patches together have been bootstrapped and regtested ok on
> > x86_64-pc-linux-gnu.
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
> I have reviewed the five patches and have the following nits shown
> below. These are simply white space fixes.
>
> I had a couple of reject hunks in intrinsics.texi when applying the
> patches.
>
> All applies cleanly and regression tests here as well.
>
> It looks OK to commit.
>
> Regards,
>
> Jerry
>
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -11467,12 +11467,11 @@ resolve_scalar_variable_as_arg (const char
> *name, bt exp_type, int exp_kind,
> gfc_expr *e)
> {
> gfc_resolve_expr (e);
>if (e
> && (e->ts.type != exp_type || e->ts.kind < exp_kind || e->rank != 0
> || e->expr_type != EXPR_VARIABLE))
> gfc_error (
> "%s argument at %L must be a scalar %s variable of at least kind %d",
>name, &e->where, gfc_basic_typename (exp_type), exp_kind);
>
> @@ -11685,8 +11684,7 @@ resolve_branch (gfc_st_label *label, gfc_code *code)
>
> if (code->here == label)
> {
> gfc_warning (0,
> "Branch at %L may result in an infinite loop", &code->loc);
> return;
> }
>
> @@ -11753,8 +11751,7 @@ resolve_branch (gfc_st_label *label, gfc_code *code)
>allowed in Fortran 66, so we allow it as extension. No
>further checks are necessary in this case. */
> gfc_notify_std (GFC_STD_LEGACY, "Label at %L is not in the same block "
> "as the GOTO statement at %L", &label->where, &code->loc);
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
From d3db7fc88a52310bfec0d362080a1631d2b87efb Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Tue, 15 Apr 2025 15:21:26 +0200
Subject: [PATCH 6/6] Fortran: Various fixes on F2018 teams.
gcc/fortran/ChangeLog:
* match.cc (match_exit_cycle): Allow to exit team block.
(gfc_match_end_team): Create end_team node also without
parameter list.
* trans-intrinsic.cc (conv_stat_and_team): Team and team_number
only need to be a single pointer.
* trans-stmt.cc (trans_associate_var): Create a mapping coarray
token for coarray associations or it is not addressed correctly.
* trans.h (enum gfc_coarray_regtype): Add mapping mode to
coarray register.
libgfortran/ChangeLog:
* caf/libcaf.h: Add mapping mode to coarray's register.
* caf/single.c (_gfortran_caf_register): Create a token sharing
another token's memory.
(check_team): Check team parameters to coindexed expressions are
valid.
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray/coindexed_3.f08: Add minimal test for
get_team().
* gfortran.dg/team_change_2.f90: Add test for change team with
label and exiting out of it.
* gfortran.dg/team_end_2.f90: Check parsing
Re: [wwwdocs][Patch] gcc-15/changes: Fortran + offload (C++) update | project/gomp: GCC 15 update
On Thu, 17 Apr 2025, Tobias Burnus wrote: > * https://gcc.gnu.org/projects/gomp/ This is a no-brainer. Please go ahead and push (and any such changes in the future). It does make me wonder whether we really need/want distinct docs for minor releases or shouldn't better keep just one for the branch? Gerald
15 is now at or very near release
I now see this in git: remotes/origin/releases/gcc-15 So we are at or very close to the release. Cheers, Jerry
Re: 15 is now at or very near release
On Thu, Apr 17, 2025 at 5:31 PM Jerry D wrote: > > I now see this in git: > > remotes/origin/releases/gcc-15 > > So we are at or very close to the release. Very close. See https://gcc.gnu.org/pipermail/gcc/2025-April/245943.html . Thanks, Andrew > > Cheers, > > Jerry
Re: [wwwdocs][Patch] gcc-15/changes: Fortran + offload (C++) update | project/gomp: GCC 15 update
Gerald Pfeifer wrote: On Thu, 17 Apr 2025, Tobias Burnus wrote: * https://gcc.gnu.org/projects/gomp/ This is a no-brainer. Well, it still adds GCC 16 … It does make me wonder whether we really need/want distinct docs for minor releases or shouldn't better keep just one for the branch? I think the branch one should be enough – the differences are usually very small and the chance that one has a newer version than .1 (albeit often not necessarily the latest) is high. * * * Talking about documentation, what I think would be useful to have is the install documentation under https://gcc.gnu.org/onlinedocs/ — it is generated like the rest of the documentation but it is only linked to https://gcc.gnu.org/install/ Having it under /install is fine, but it can be useful at times to have the install documentation for the last stable release or the one before – and not only for mainline – available somewhere. BTW 2: I think we should somehow make the " host/target specific installation notes" more prominent (Bold? Adding it to the 1 to 6 step list? …). While listed on the installation landing page, https://gcc.gnu.org/install/ one quickly jumps to the 1 to 6 bullet list without properly reading the words – and then misses https://gcc.gnu.org/install/specific.html – but it contains really important pieces of information for some architectures. Tobias
Re: [wwwdocs][Patch] gcc-15/changes: Fortran + offload (C++) update | project/gomp: GCC 15 update
On Thu, 17 Apr 2025, Tobias Burnus wrote: > Anyone: comments are welcome. > + The standard C++ library (libstdc++) is now supported I wouldn't mark up libstdc++ as in this context; we are pretty much treating it as a proper name/project name. (Two occurrences.) Looks good to me otherwise, though not an expert on the subject matter. Gerald
