gcc/testsuite/ChangeLog
* c-c++-common/gomp/metadirective-device.c: Don't add extra options
for target ia32.
* c-c++-common/gomp/metadirective-target-device-1.c: Likewise.
---
gcc/testsuite/c-c++-common/gomp/metadirective-device.c | 2 +-
gcc/testsuite/c-c++-common
On 1/14/25 20:38, Sandra Loosemore wrote:
I've incorporated a fix for Tobias's recent comment about recognizing
C_OMP_DIR_META in the "assumes" directive in the C and C++ front ends, but
I've deferred fixing the wording of the existing error message because it
af
: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
Co-Authored-By: Tobias Burnus
Co-Authored-By: Paul-Antoine Arras
---
gcc/fortran/decl.cc | 29 +
gcc/fortran/dump-parse-tree.cc| 20 +
gcc/fortran/gfortran.h
libgomp/ChangeLog
* libgomp.texi (OpenMP 5.0): Mark metadirective and declare variant
as implemented.
(OpenMP 5.1): Mark target_device as supported.
Add changed interaction between declare target and OpenMP context
and dynamic selector support.
(OpenM
.
* testsuite/libgomp.c-c++-common/metadirective-late-2.c: New.
* testsuite/libgomp.c-c++-common/metadirective-target-device-1.c: New.
* testsuite/libgomp.c-c++-common/metadirective-target-device-2.c: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
o-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
gcc/c-family/c-common.h | 4 +-
gcc/c-family/c-gimplify.cc| 27 +
gcc/c-family/c-omp.cc | 60 ++-
gcc/c-family/c-pragma.cc | 1 +
gcc/
The code and test case previously implemented the OpenMP 5.0 spec,
which said in section 2.3.1:
"For functions within a declare target block, the target trait is added
to the beginning of the set..."
In OpenMP 5.1, this was changed to
"For device routines, the target trait is added to the beginni
* testsuite/libgomp.c++/metadirective-template-1.C: New.
* testsuite/libgomp.c++/metadirective-template-2.C: New.
* testsuite/libgomp.c++/metadirective-template-3.C: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
gcc/cp/cp-tree.h
iew comments on the C behavior that look like
rat holes. At this point I think we are both on the same page as far
as not letting the perfect become the enemy of the good, and it will
be much easier to both hack up and review incremental improvements
once the base patches are in.
-Sandra
Sandra Loo
iteration
on your main/middle-end patch #2, which I still have to finish studying.
But now comments to this patch - or C testing as at least one comment
relates to code in Patch #2.
Sandra Loosemore wrote:
Additional shared C/C++ testcases are included in a subsequent patch
in this
series.
I started
After reimplementing late resolution of "declare variant", the
declare_variant_alt and calls_declare_variant_alt flags on struct
cgraph_node are no longer used by anything. For the purposes of
marking functions that need late resolution, the
has_omp_variant_constructs flag has replaced
calls_decla
tran.dg/gomp/declare-variant-13.f90: Test that this is resolvable
after gimplification, not just final resolution.
* gfortran.dg/gomp/declare-variant-14.f90: Tweak testcase to ensure
that -O causes dead code to be optimized away.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-
asive ways. So I'm *very* relieved at getting the
most complicated parts of the set in, finally. There are still bugs
and incomplete functionality, but spending less time on resolving
merge conflicts means more time for fixing those issues.
-Sandra
Sandra Loosemore (3):
OpenMP: New tr
ew.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
gcc/doc/generic.texi | 63 +++
gcc/fold-const.cc| 2 +
gcc/gimple-expr.cc | 5 +++
gcc/gimple.cc| 4 +-
gcc/tree-cfg.cc | 1 +
gcc/tree-inline.cc |
On 1/13/25 16:43, Tobias Burnus wrote:
Hi all,
Tobias Burnus wrote:
Tobias Burnus wrote:
Sandra Loosemore wrote:
This patch reimplements the middle-end support for "declare variant"
and extends the resolution mechanism to also handle metadirectives
(PR112779). It also adds parti
uisite for part 5, the C support for metadirective.
-SandraFrom 83e9dbbac718d439724f81c0f3a706d5cea389cf Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Fri, 3 Jan 2025 17:35:03 +
Subject: [PATCH] OpenMP: Robustify C front end handling of attribute-syntax
pragmas
Presently, the code
On 1/2/25 20:22, Maciej W. Rozycki wrote:
On Tue, 31 Dec 2024, Sandra Loosemore wrote:
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index d11d37761d9..b47180126ca 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -1577,7 +1577,7 @@ if @var{Y
gcc/fortran/ChangeLog
* gfortran.texi (Function ABI Documentation): Make menu ordering
consistent with subsection ordering.
---
gcc/fortran/gfortran.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index
In English usage, "that" introduces a restrictive clause while "which"
introduces a non-restrictive or descriptive clause. "That" is almost
never preceded by a comma while "which" often is. The Fortran manual
had many instances where these uses were reversed, or where a comma
was used with "that"
Continuing a series of patches to tidy the Fortran manual, this
installment fixes problems with inappropriate use of future tense and
adds some missing markup I noticed in passing.
gcc/fortran/ChangeLog
* intrinsic.texi: Grammar and markup fixes throughout
the file.
---
gcc/fortra
Per comments in invoke.texi, target option groups in the Option
Summary section are supposed to be alphabetized and in the same order
as the documentation sections they refer to. "M32C Options" was
misordered in the Option Summary. "Cygwin and MinGW Options" was
ordered incorrectly in both places
When looking through the gfortran manual, I noted some problems with
hyphens being used where they're not correct or necessary,
e.g. "non-standard" vs "nonstandard", "null-pointer" vs "null pointer"
(as a noun), etc. I've made a pass through the documentation to
correct at least some of those uses
The present tense is preferred for expressing facts or enduring
behavior. Thus we should say "option X does Y" instead of "option X
will do Y", reserving the future tense for things that happen at some
later time (such as in a future release of GCC, or at run time as
explicitly contrasted with com
While working on something else I noticed there were numerous places
in the GNU Fortran manual with incorrect/missing Texinfo markup. I
made a pass through about the first third of the manual (not yet the
coarray API or intrinsics documentation) to fix at least some of those
issues, plus some typo
e at least an incremental improvement.
-Sandra
Sandra Loosemore (3):
Fortran: Fixes for markup, typos, and indexing in manual
Fortran: Use the present tense for the manual.
Fortran: Fix hyphenation errors in the manual
gcc/fortran/gfortran.texi | 431 -
This is a long-standing documentation bug in the Fortran manual,
initially reported in 2012 as PR51820, with a quick fix applied later
for PR109216. The patch here incorporates more of the discussion from
the original issue.
gcc/fortran/ChangeLog
PR fortran/51820
PR fortran/89632
On 12/17/24 14:21, Tobias Burnus wrote:
Hi Sandra,
thanks for the patch! One minor nit:
Sandra Loosemore wrote:
+To enable the processing of OpenACC directives @samp{#pragma omp}
#pragma acc – not #pragma omp.
Sigh, I need to get new glasses! Fixed with the attached patch.
-SandraFrom
PR c/26154 is one of our oldest documentation issues. The only
discussion of OpenMP support in the GCC manual is buried in the "C
Dialect Options" section, with nothing at all under "Extensions". The
Fortran manual does have separate sections for OpenMP and OpenACC
extensions so I have copy-edite
My previous attempt to fix this issue ended up garbling the text
instead. Trying again to make the descriptions of the attribute and
command-line option consistent.
gcc/ChangeLog
PR middle-end/111659
* doc/extend.texi (Common Variable Attributes): Copy-edit description
of
I noticed there is this new generated file that needs to be updated by
"make regenerate-attr-urls" similarly to "make regenerate-opt-urls", but
nobody had done that recently as the buildbot does not nag about it yet.
gcc/ChangeLog
* attr-urls.def: Regenerate.
---
gcc/attr-urls.def | 9 ++
The list of -Wsuggest-attribute= variants was out of date in the option
summary (and getting too long to fit on one line), and an index entry was
missing for -Wsuggest-attribute=returns_nonnull.
gcc/c-family/ChangeLog
PR c/115532
* c.opt.urls: Regenerated.
gcc/ChangeLog
PR
On 12/12/24 03:53, Sam James wrote:
r15-6128-gfa878dc8c45fa3 missed the regeneration of the URL doc map, so
regenerate it here to make the buildbots happy.
I apologize for this breakage. :-( Can someone explain how I can
detect this problem *before* submitting patches, and how to fix it, so
Commit e1769bdd4cef522ada32aec863feba41116b183a accidentally inserted
the documentation for the x86 -mstack-protector-guard-symbol option in the
wrong place. Fixed thusly.
gcc/ChangeLog
PR target/117150
* doc/invoke.texi (RS/6000 and PowerPC Options): Move description
of -
: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
Co-Authored-By: Tobias Burnus
Co-Authored-By: Paul-Antoine Arras
---
gcc/fortran/decl.cc | 29 +
gcc/fortran/dump-parse-tree.cc| 20 +
gcc/fortran/gfortran.h
* testsuite/libgomp.c++/metadirective-template-2.C: New.
* testsuite/libgomp.c++/metadirective-template-3.C: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
gcc/cp/cp-tree.h | 2 +
gcc/cp/parser.cc
The code and test case previously implemented the OpenMP 5.0 spec,
which said in section 2.3.1:
"For functions within a declare target block, the target trait is added
to the beginning of the set..."
In OpenMP 5.1, this was changed to
"For device routines, the target trait is added to the beginni
properties.
(analyze_metadirective_body): New.
(c_parser_omp_metadirective): New.
gcc/testsuite/
PR middle-end/112779
* c-c++-common/gomp/declare-variant-2.c: Adjust expected output for C.
* gcc.dg/gomp/metadirective-1.c: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
libgomp/ChangeLog
* libgomp.texi (OpenMP 5.0): Mark metadirective and declare variant
as implemented.
(OpenMP 5.1): Mark target_device as supported.
Add changed interaction between declare target and OpenMP context
and dynamic selector support.
(OpenM
: New.
* testsuite/libgomp.c-c++-common/metadirective-late-2.c: New.
* testsuite/libgomp.c-c++-common/metadirective-target-device.c: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
.../c-c++-common/gomp/attrs-metadirective-1.c | 47 +
.../c-c
After reimplementing late resolution of "declare variant", the
declare_variant_alt and calls_declare_variant_alt flags on struct
cgraph_node are no longer used by anything. For the purposes of
marking functions that need late resolution, the
has_omp_variant_constructs flag has replaced
calls_decla
f90: Likewise.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
Co-Authored-By: Marcel Vollweiler
---
gcc/Makefile.in |2 +-
gcc/c/c-parser.cc |4 +-
gcc/cgraph.h |3 +
gcc/c
Presently, the code to handle OpenMP attribute-syntax pragmas in the C
front end assumes nothing else is messing with redirecting
parser->tokens, and makes no provision for restoring it from anything
other than parser->tokens_buf when the buffer allocated for the pragma
is exhausted. Adding suppor
construct.
I still hope this functionality can make it into GCC 15.
-Sandra
Sandra Loosemore (10):
OpenMP: New tree nodes for metadirective and dynamic selector support.
OpenMP: Re-work and extend context selector resolution
OpenMP: Remove dead code from declare variant reimplementation
ew.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
gcc/doc/generic.texi | 63 +++
gcc/fold-const.cc| 2 +
gcc/gimple-expr.cc | 5 +++
gcc/gimple.cc| 4 +-
gcc/tree-cfg.cc | 1 +
gcc/tree-inline.cc |
---
htdocs/gcc-15/changes.html | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 80604ab8..6c9ebaac 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -29,7 +29,9 @@ a work-in-progress.
C
r PR114596.
* gfortran/gomp/declare-variant-13.f90: Tweak testcase to ensure
that -O causes dead code to be optimized away.
* gfortran/gomp/declare-variant-14.f90: Likewise.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
Co-Authored-By: Marcel Vollweiler
---
* testsuite/libgomp.c++/metadirective-template-2.C: New.
* testsuite/libgomp.c++/metadirective-template-3.C: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
gcc/cp/cp-tree.h | 2 +
gcc/cp/parser.cc
-late-2.c: New.
* testsuite/libgomp.c-c++-common/metadirective-target-device.c: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
.../c-c++-common/gomp/attrs-metadirective-1.c | 47 +
.../c-c++-common/gomp/attrs-metadirective-2.c | 76
.../c-c
: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
Co-Authored-By: Tobias Burnus
Co-Authored-By: Paul-Antoine Arras
---
gcc/fortran/decl.cc | 29 +
gcc/fortran/dump-parse-tree.cc| 20 +
gcc/fortran/gfortran.h
libgomp/ChangeLog
* libgomp.texi (OpenMP 5.0): Mark metadirective and declare variant
as implemented.
(OpenMP 5.1): Mark target_device as supported.
Add changed interaction between declare target and OpenMP context
and dynamic selector support.
(OpenM
The code and test case previously implemented the OpenMP 5.0 spec,
which said in section 2.3.1:
"For functions within a declare target block, the target trait is added
to the beginning of the set..."
In OpenMP 5.1, this was changed to
"For device routines, the target trait is added to the beginni
properties.
(analyze_metadirective_body): New.
(c_parser_omp_metadirective): New.
gcc/testsuite/
PR middle-end/112779
* c-c++-common/gomp/declare-variant-2.c: Adjust expected output for C.
* gcc.dg/gomp/metadirective-1.c: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
After reimplementing late resolution of "declare variant", the
declare_variant_alt and calls_declare_variant_alt flags on struct
cgraph_node are no longer used by anything. For the purposes of
marking functions that need late resolution, the
has_omp_variant_constructs flag has replaced
calls_decla
Presently, the code to handle OpenMP attribute-syntax pragmas in the C
front end assumes nothing else is messing with redirecting
parser->tokens, and makes no provision for restoring it from anything
other than parser->tokens_buf when the buffer allocated for the pragma
is exhausted. Adding suppor
ew.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
gcc/doc/generic.texi | 63 +++
gcc/fold-const.cc| 2 +
gcc/gimple-expr.cc | 5 +++
gcc/gimple.cc| 4 +-
gcc/tree-cfg.cc | 1 +
gcc/tree-inline.cc |
iant" that I have not
yet submitted because I've been blocked on getting these
infrastructure changes in first.
-Sandra
Sandra Loosemore (10):
OpenMP: New tree nodes for metadirective and dynamic selector support.
OpenMP: Re-work and extend context selector resolution
OpenMP: Remove
On 11/14/24 07:51, Gerald Pfeifer wrote:
On Thu, 14 Nov 2024, mmalcom...@nvidia.com wrote:
gcc/ChangeLog:
* doc/extend.texi: Document ability to use floating point atomic
fetch_add/fetch_sub/add_fetch/sub_fetch builtins.
+Moreover, the @samp{__atomic_fetch_add}, @samp{__atomi
On 10/8/24 09:35, Jan Beulich wrote:
On 08.10.2024 17:30, Sandra Loosemore wrote:
[snip]
Hmmm, looking at the complete documentation for this built-in, and the
code, I think I'd go a little farther with fixing up the docs.
Since requiring the first operand to be a constant is also diff
On 10/8/24 08:12, Jan Beulich wrote:
On 19.06.2024 16:01, Jan Beulich wrote:
Present wording has misled people to believe the ?: operator would be
evaluating all three of the involved expressions.
gcc/
* doc/extend.texi: Clarify __builtin_choose_expr() similarity to
the ?: oper
On 9/24/24 14:08, haochen.jiang wrote:
On Linux/x86_64,
96246bff0bcd9e5cdec9e6cf811ee3db4997f6d4 is the first bad commit
commit 96246bff0bcd9e5cdec9e6cf811ee3db4997f6d4
Author: Sandra Loosemore
Date: Fri Sep 6 20:58:13 2024 +
OpenMP: Check additional restrictions on context
On 9/21/24 22:52, Jakub Jelinek wrote:
On Sat, Sep 21, 2024 at 08:08:29PM -0600, Sandra Loosemore wrote:
On 9/20/24 01:41, Jakub Jelinek wrote:
+
+ /* Check for unknown properties. */
if (omp_ts_map[ts_code].valid_properties == NULL)
continue;
-
Why?
Why what
On 9/20/24 01:41, Jakub Jelinek wrote:
+
+ /* Check for unknown properties. */
if (omp_ts_map[ts_code].valid_properties == NULL)
continue;
-
Why?
Why what? I made this change because when I added another check in this
loop I was temporarily confused about the
On 9/9/24 04:46, Tobias Burnus wrote:
I wonder whether we should do something like the following.
[The following is a mix between compile code and generated code, for
illustrative
purpose.]
Inside the compiler do:
#ifndef ACCEL_COMPILER
intr = 0; if (targetm.omp.device_kind_arch_isa != NULL
On 9/9/24 14:55, Sandra Loosemore wrote:
On 9/9/24 05:01, Jakub Jelinek wrote:
I think also testing the device={kind(any,any)} and
device={kind("any",any)}
and device={kind(any,"any"))} would be useful.
Hmmm, it looks like GCC does not presently check for the rest
On 9/9/24 05:01, Jakub Jelinek wrote:
I think also testing the device={kind(any,any)} and device={kind("any",any)}
and device={kind(any,"any"))} would be useful.
Hmmm, it looks like GCC does not presently check for the restriction
"Each trait-property may only be specified once in a trait sel
ched; I'll push it in the next day or two if there is no further
objection.
-SandraFrom 23a82bea26805f2a430354d56b444d5bb7eaed3f Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Fri, 6 Sep 2024 20:58:13 +
Subject: [PATCH] OpenMP: Reject other properties with kind(any)
TR13 (pre-6.0
On 8/16/24 04:30, Jakub Jelinek wrote:
On Sat, Jul 20, 2024 at 02:42:23PM -0600, Sandra Loosemore wrote:
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -263,9 +263,24 @@ struct GTY(()) c_parser {
otherwise NULL. */
vec *in_omp_attribute_pragma;
+ /* When
On 8/27/24 11:06, Tobias Burnus wrote:
Hi FX,
FX Coudert wrote:
Give it’s a doc patch, I think it might fall under the obvious rule,
and will commit in a week if there is no objection.
The patch clearly fixes a bug in the current specification and is fine,
I just wonder …
* libquadmath.te
On 8/24/24 09:13, Tobias Burnus wrote:
+@node Foreign-runtime support for AMD GPUs
+@subsection OpenMP @code{interop} -- Foreign-Runtime Support for AMD GPUs
Em-dash in Texinfo is three dashes with no surrounding spaces. I
believe that the libgomp manual uses the incorrect markup you have he
On 8/23/24 07:03, Tobias Burnus wrote:
Add documentation for OpenMP's interoperability routines.
I have only a few copy-editing type comments.
+Implementation remark: In GCC, the Fortran interface differs from the one shown
+below: the function has C binding, @var{interop} is passed by value
On 8/10/24 02:02, Jakub Jelinek wrote:
On Sat, Aug 10, 2024 at 09:18:24AM +0200, Jakub Jelinek wrote:
On Fri, Aug 09, 2024 at 07:12:48PM +0200, Jakub Jelinek wrote:
--- a/gcc/gimple.def
+++ b/gcc/gimple.def
@@ -398,6 +398,13 @@ DEFGSCODE(GIMPLE_OMP_TEAMS, "gimple_omp_teams",
GSS_OMP_PARALLEL_L
On 8/9/24 10:42, Jakub Jelinek wrote:
Why needs omp-general.h the move in GTFILES etc.? Will just moving
those definitions be ok?
I just double-checked that. The Makefile.in change to reorder
omp-general.h in GTFILES is because of moving the definition of
score_wide_int there from omp-gene
On 8/13/24 11:18, Andrew Carlotti wrote:
I'm still waiting for review for this patch. I've asked Richard
Sandiford about it, and he'd like a docs maintainer to review the
patch (so I've cc'd the rest of them now as well).
I'm sorry, I've seen this patch go by before, but every time I've looked
On 8/10/24 13:24, Gerald Pfeifer wrote:
+With @code{-fprofile-use} all portions of programs not executed during
+training runs are optimized aggressively for size rather than speed.
+In some cases it is not practical to train all possible hot paths in
+the program. (For example, a program may co
On 8/8/24 06:21, Tobias Burnus wrote:
Update for the very recently released TR13. Unsurprisingly, most item
are still unimplemented.
→ https://www.openmp.org/specifications/ → Technical Report 13
Comments, suggestions, typo fixes? — If not, I will commit it later today.
I've got a few things
On 8/8/24 06:20, Jakub Jelinek wrote:
On Thu, Aug 08, 2024 at 02:18:48PM +0200, Tobias Burnus wrote:
Document -fno-builtin-omp_is_initial_device as discussed:
Jakub Jelinek wrote:
RFC: Should be document this new built-in some where? If so, where? As part
of the routine description in libgomp
On 7/29/24 06:12, Tobias Burnus wrote:
I recently stumbled over omp_get_default_device returning -1 (=
omp_initial_device)
vs. returning omp_get_num_devices(). Thus, it makes sense to document
this properly.
I also updated some wording and made a tiny step to documenting the
missing functions
xist.
Can you eventually take care of the last two items?
Yes.
(For the last item: e.g. 'target_device' for declare_variant, for which
'sorry' already existed.)
* * *
I might have asked the following question before – and you might have
answered it already:
Sandra Loo
irective-5.f90: New.
* testsuite/libgomp.fortran/metadirective-6.f90: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
Co-Authored-By: Tobias Burnus
Co-Authored-By: Paul-Antoine Arras
---
gcc/fortran/decl.cc | 29 +
gcc/fortran/dump-parse-tre
The code and test case previously implemented the OpenMP 5.0 spec,
which said in section 2.3.1:
"For functions within a declare target block, the target trait is added
to the beginning of the set..."
In OpenMP 5.1, this was changed to
"For device routines, the target trait is added to the beginni
This patch extends the mechanisms previously added to support dynamic
selectors in metavariant constructs to also apply to "declare
variant". The front-end mechanisms used to handle "declare variant"
via attributes attached to the function decls remain the same, but the
gimplifier now uses the sam
After reimplementing late resolution of "declare variant" to use the
same mechanisms as metadirective, the declare_variant_alt and
calls_declare_variant_alt flags on struct cgraph_node are no longer
used by anything. For the purposes of marking functions that need
late resolution, the has_metadire
.
* testsuite/libgomp.c-c++-common/metadirective-target-device.c: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
.../c-c++-common/gomp/attrs-metadirective-1.c | 41
.../c-c++-common/gomp/attrs-metadirective-2.c | 75
.../c-c++-common/gomp/attrs
++/metadirective-template-2.C: New.
* testsuite/libgomp.c++/metadirective-template-3.C: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
gcc/cp/parser.cc | 524 +-
gcc/cp/parser.h | 7 +
gcc
libgomp/ChangeLog
* libgomp.texi (OpenMP 5.0): Mark metadirective and declare variant
as implemented.
(OpenMP 5.1): Mark target_device as supported.
Add changed interaction between declare target and OpenMP context
and dynamic selector support.
(OpenM
/testsuite/ChangeLog
* gcc.dg/gomp/metadirective-1.c: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
gcc/c-family/c-common.h | 4 +-
gcc/c-family/c-gimplify.cc | 27 +
gcc/c-family/c-omp.cc | 60
The OpenMP spec says:
"If trait-property any is specified in the kind trait-selector of the
device selector set or the target_device selector sets, no other
trait-property may be specified in the same selector set."
GCC was not previously enforcing this restriction and several testcases
included
.
* tree-ssa-operands.cc: Include omp-general.h.
(operands_scanner::parse_ssa_operands): Handle
GIMPLE_OMP_METADIRECTIVE.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
Co-Authored-By: Marcel Vollweiler
---
gcc/cgraph.h | 3 +
gcc
plugin function.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
include/cuda/cuda.h | 2 +
libgomp/Makefile.am | 2 +-
libgomp/Makefile.in | 5 +-
libgomp/config/gcn/selector.c | 102 +++
libgomp/config
re_variant): Update calls to
omp_check_context_selector and omp_context_selector_matches.
* types.def (BT_FN_BOOL_INT_CONST_PTR_CONST_PTR_CONST_PTR): New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
gcc/Makefile.in | 2 +-
gcc/builtin
pieces
in some other way, please let me know what would help to expedite the
process. I'd really like to get these patches in somehow or another,
so I don't have to continue to spend so much time maintaining them out
of tree. :-S
-Sandra
Sandra Loosemore (12):
OpenMP: metadirective tr
On 7/16/24 06:53, Tobias Burnus wrote:
Question: Is now everything clear - or are you still confused by my
writing?
Well, I still do not understand why backward compatibility concerns
specific to some other directive should affect the ABI for a new
directive that does not have any current li
On 5/31/24 06:22, Tobias Burnus wrote:
I have to admit that I don't really see the use of metadirective_p as …
int
-omp_context_selector_matches (tree ctx)
+omp_context_selector_matches (tree ctx, bool metadirective_p, bool
delay_p)
...
+ if (metadirective_p && delay_p)
+
On 7/1/24 11:39, Matthew Malcomson wrote:
Ping plus some extra people on Cc since I wasn't sure who to ask for
review.
(Adding maintainers for `middle-end` plus Richard S).
gcc/ChangeLog:
* doc/tm.texi (function_attribute_inlinable_p,
unspec_may_trap_p): Update documentation.
* t
This function had a reference to an uninitialized variable on the
error path. The problem was diagnosed by clang but not gcc. It seems
the cleanest solution is to initialize all the loop-clause variables
at the point of declaration rather than at different places in the
code.
The C++ front end d
On 6/2/24 21:01, Kewen Lin wrote:
This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
defines in nios2 port.
gcc/ChangeLog:
* config/nios2/nios2.h (FLOAT_TYPE_SIZE): Remove.
(DOUBLE_TYPE_SIZE): Likewise.
(LONG_DOUBLE_TYPE_SIZE): Likewise.
Fine with me, but somewh
On 6/6/24 06:06, Tobias Burnus wrote:
Hi Thomas,
regarding the commit r15-1070-g3a4775d4403f2e /
https://gcc.gnu.org/r15-1070
First, thanks for adding I/O support to nvptx offloading.
I have a wording nit, to be confirmed by a native speaker:
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgom
After reimplementing late resolution of "declare variant" to use the
same mechanisms as metadirective, the declare_variant_alt and
calls_declare_variant_alt flags on struct cgraph_node are no longer
used by anything. For the purposes of marking functions that need
late resolution, the has_metadire
The code and test case previously implemented the OpenMP 5.0 spec,
which said in section 2.3.1:
"For functions within a declare target block, the target trait is added
to the beginning of the set..."
In OpenMP 5.1, this was changed to
"For device routines, the target trait is added to the beginni
.
* testsuite/libgomp.c-c++-common/metadirective-4.c: New.
* testsuite/libgomp.c-c++-common/metadirective-5.c: New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
---
.../c-c++-common/gomp/metadirective-1.c | 52 +
.../c-c++-common/gomp/metadirective-2.c
1 - 100 of 1065 matches
Mail list logo
