gcc/ChangeLog
PR c/88382
* doc/extend.texi (Syntax Extensions): Adjust menu.
(Raw String Literals): New section.
---
gcc/doc/extend.texi | 20
1 file changed, 20 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 5bc2785f802..09
-Q does something completely different in conjunction with --help than it
does otherwise; its main entry in the manual didn't mention that, nor did
-Q have an entry in the index for the --help usage.
gcc/ChangeLog
PR driver/90465
* doc/invoke.texi (Overall Options): Add a @cindex f
On 4/15/25 19:11, Alex wrote:
Here is a follow up patch for documentation of the omp.h allocators,
I'm not super happy with it but I wanted to get eyes on it before I go
to sleep tonight.
> From c8cef447baf16743f7bf0d887d3fd09108d3a607 Mon Sep 17 00:00:00 2001
From: waffl3x
Date: Tue, 15 Apr 20
There's a blurb at the top of the "Optimize Options" node telling
people that most optimization options are completely disabled at -O0
and a similar blurb in the entry for -Og, but nothing at the entry for
-O0. Since this is a continuing point of confusion it seems wise to
duplicate the informatio
gcc/ChangeLog
PR ipa/113203
* doc/extend.texi (Common Function Attributes): Explain how to
use always_inline in programs that have multiple translation
units, and that LTO inlining additionally needs optimization
enabled.
---
gcc/doc/extend.texi | 7 +++
gcc/ChangeLog
PR target/42683
* doc/invoke.texi (x86 Options): Clarify that -march=pentiumpro
doesn't include MMX.
---
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 67155eeeda7..1f7657
On 4/12/25 01:10, Paul Richard Thomas wrote:
Hi All,
Now that the reduce intrinsic seems to be OK on all platforms, I thought
that it was time to catch up with the documentation.
The attached produces good .html without any additional warnings or
errors using texi2any and ~/share/info/gfortr
gcc/ChangeLog
PR target/97585
* doc/invoke.texi (x86 Options): Document list of extensions
supported by -march=x86_64, according to the declaration of
PTA_X86_64_BASELINE in config/i386/i386.h.
---
gcc/doc/invoke.texi | 3 ++-
1 file changed, 2 insertions(+), 1 dele
gcc/ChangeLog
PR c++/106618
* doc/invoke.texi (Option Summary): Remove -fargs-in-order, add
-fstrong-eval-order.
(C++ Dialect Options): Explicitly document that -fstrong-eval-order
takes an optional argument and what the choices are. Generalize
refer
gcc/ChangeLog
PR middle-end/105548
* doc/invoke.texi (Optimize Options): Delete misleading sentence
about conversions.
---
gcc/doc/invoke.texi | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ffde9df85f
gcc/ChangeLog
PR tree-optimization/87909
* common.opt.urls: Regenerate.
* doc/invoke.texi (Option Summary): Add -ftree-cselim.
(Optimize Options): Likewise.
---
gcc/common.opt.urls | 3 +++
gcc/doc/invoke.texi | 10 --
2 files changed, 11 insertions(+), 2 d
gcc/ChangeLog
PR middle-end/14708
* doc/invoke.texi (Optimize Options): List -fexcess-precision
before -ffloat-store, moving some background discussion to the
former from the latter. Recommend using -fexcess-precision=standard
instead of -ffloat-store.
---
The issue is specifically about a missing word, but I spotted other
copy-editing issues like misplaced hyphens in nearby text. I also
thought that the -Wimplicit example was anachronistic because it's a
hard error in modern C dialects rather than a warning, and replaced it
with something users are
On 4/6/25 03:00, Florian Weimer wrote:
* Sandra Loosemore:
@@ -13698,6 +13699,17 @@ Forward-declaring an incomplete enum type without an
explicit
underlying type is supported as an extension in all GNU C dialects,
but is not supported at all in GNU C++.
+@node Boolean Type
gcc/ChangeLog
PR middle-end/78874
* doc/invoke.texi (Warning Options): Fix description of
-Wno-aggressive-loop-optimizations to reflect that this turns
off the warning, and the default is for it to be enabled.
---
gcc/doc/invoke.texi | 5 +++--
1 file changed, 3 ins
I keep forgetting to do this :-(
gcc/c-family/ChangeLog
* c.opt.urls: Regenerate.
gcc/d/ChangeLog
* lang.opt.urls: Regenerate.
---
gcc/c-family/c.opt.urls | 3 +++
gcc/d/lang.opt.urls | 3 +++
2 files changed, 6 insertions(+)
diff --git a/gcc/c-family/c.opt.urls b/gcc/c
Per the issue, there were a couple places in the manual where
-Wno-psabi was mentioned, but the option itself was not documented.
gcc/c-family/ChangeLog
PR c/81831
* c.opt (Wpsabi): Remove "Undocumented" modifier and add a
documentation string.
gcc/ChangeLog
PR c/8
gcc/c-family/ChangeLog
* c.opt.urls: Regenerate.
gcc/d/ChangeLog
* lang.opt.urls: Regenerate.
gcc/m2/ChangeLog
* lang.opt.urls: Regenerate.
---
gcc/c-family/c.opt.urls | 4 ++--
gcc/d/lang.opt.urls | 2 +-
gcc/m2/lang.opt.urls| 2 +-
3 files changed, 4 insertions(
gcc/ChangeLog
PR driver/58973
* common.opt (Werror, Werror=): Use less awkward wording in
description.
(pedantic-errors): Likewise.
* doc/invoke.texi (Warning Options): Likewise for -Werror and
-Werror= here.
Co-Authored-By: GUO Yixuan
---
gcc/comm
On 3/13/25 20:39, Sandra Loosemore wrote:
This series of patches attempts to bring some organization to the
current random order of topics within the "C Extensions" chapter of
the manual. [snip]
I've now pushed these patches.
-Sandra
This patch addresses a number of issues with the documentation of
- None of the things in this section had @cindex entries [PR114957].
- The document formatting didn't match that of other #pragma
documentation sections.
- The effect of #pragma pack(0) wasn't documented [PR78008].
- There's a lo
gcc/ChangeLog
PR middle-end/112589
* common.opt (-fcf-protection): Add documentation string.
* doc/invoke.texi (Option Summary): Add entry for -fcf-protection
without argument.
(Instrumentation Options): Tidy the -fcf-protection entry and
and add docu
This issue was specifically about a confusing mention of the "second
and third arguments to the memcpy function" when only the second one
is a pointer affected by the attribute, but reading through the entire
discussion I found other things confusing as well; e.g. in some cases
it wasn't clear whet
Looking over the recently-committed change to the musttail attribute
documentation, it appears the comment in the last example was a paste-o,
as it does not agree with either what the similar example in the
-Wmaybe-musttail-local-addr documentation says, or the actual behavior
observed when running
Per the issue, the discussion of these two attributes needed to be
better integrated. I also did some editing for style and readability,
and clarified that almost all targets support this feature (it is
enabled by default unless the back end disables it), not just "some".
Co-Authored_by: Jonathan
gcc/ChangeLog
PR c/118118
* doc/extend.texi (Boolean Type): New section.
---
gcc/doc/extend.texi | 12
1 file changed, 12 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 76fb210060d..d2bf6048be7 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc
As noted in PR 118965, the initial interop implementation overlooked
the requirement in the OpenMP spec that at least one of the "target"
and "targetsync" modifiers is required in both the interop construct
init clause and the declare variant append_args clause.
Adding the check was fairly straigh
This is a C23/C++11 feature that is supported as an extension with
earlier -std= options too, but was never previously documented. It
interacts with the already-documented forward enum definition extension,
so I have merged discussion of the two extensions into the same section.
gcc/ChangeLog
On 3/26/25 14:50, Sandra Loosemore wrote:
Here's another batch of patches to address PR42270, a complaint about the
poor organization of the documentation for GNU extensions. My last set of
patches for this was focused on grouping everything but the attributes and
builtins documentation
On 3/30/25 06:48, Martin Uecker wrote:
Here is a small documentation patch.
Martin
Doc: -Wzero-as-null-pointer-constant is also available for C [PR119173]
The warning -Wzero-as-null-pointer-constant is now not only supported
in C++ but also in C. Change the documentatio
On 3/27/25 10:11, Paul-Antoine Arras wrote:
I updated the patch (see attachment) with that in mind. Let me know what
you think.
I know that very long
"BT_FN_VOID_INT_INT_PTRCONSTPTRPTR_CONSTPTR_PTRCONSTSTRING..."
identifier follows the conventions used elsewhere, but it's not very
readable,
I ran into this while backporting my declare variant/dispatch/interop
patch f016ee89955ab4da5fe7ef89368e9437bb5ffb13 to the og14 development
branch. In C dialects prior to C23 (the default on mainline),
functions declared "float f()" and "float g(void)" aren't considered
equivalent for the purpose
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
The "Other Builtins" section had become a catch-all for all sorts of
things with very little organization or attempt to differentiate between
important informatio
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
This installment adds a container section to hold documentation for
both the _atomic and _sync builtins, reordering them so that the new
_atomic interface is pres
I noticed that the "New/Delete Builtins" section failed to explicitly
name or describe the arguments of the builtin functions it purported
to document, outside of using them in an example. I've fixed that
and cleaned up the whole section.
gcc/ChangeLog
* doc/extend.texi (New/Delete Builti
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
Note that this patch does not address the restructuring/rewrite
suggested by PR88472 or PR102397, beyond adding a very short
introduction to th
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Numeric Builtins): Move Integer Overflow Builtins
section here, as a subsection.
---
gcc/
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
Following the last round of patches, there's a leftover section
"Target Format Checks" that didn't fit into any category. It seems best
to merge this material in
This is part of an incremental effort to make the documentation for
GCC extensions better organized by grouping/rearranging sections by
topic.
I was originally intending to consolidate all the sections documenting
builtins as subsections of a new container section within the C
extensions chapter,
tch of these patches, I'll hold off on
committing these for a few days in case anybody has any complaints or
suggestions. (E.g., should the attributes documentation be split into
a separate chapter as well, instead of being pushed down?)
-Sandra
Sandra Loosemore (7):
Doc: Remove separ
On 3/25/25 10:59, Tobias Burnus wrote:
Updated patch:
+Available properties for an HIP interop object:
+
+@multitable @columnfractions .20 .35 .20 .20
+@headitem Property @tab C data type @tab API routine @tab
value (if constant)
+@item @code{fr_id} @tab @code{om
On 3/25/25 09:25, Paul-Antoine Arras wrote:
On 24/03/2025 21:17, Sandra Loosemore wrote:
[snip]
I think you also need to update BUILT_IN_GOMP_INTEROP in omp-
builtins.def; at least, that is the source of the decl used for the
implicit creation/destruction of interop objects in "de
ortran testcase, too.
I've also fixed the documentation to reflect that append_args is now
fully supported. New version of the patch attached; is this one OK to
commit?
-SandraFrom b1291a3088375538d187e1965b4eb8a8274fb9e8 Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Tue, 2
On 3/25/25 05:12, Tobias Burnus wrote:
On August 24, 2024 Tobias Burnus wrote:
[...] it documents the code added at "[patch][rfc] libgomp: Add OpenMP
interop support to nvptx + gcn plugin",
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661207.html
Quite some time has passed and those
On 3/24/25 08:20, Paul-Antoine Arras wrote:
On 21/03/2025 20:17, Sandra Loosemore wrote:
Does the attached patch reflect what you have in mind?
diff --git libgomp/libgomp_g.h libgomp/libgomp_g.h
index 8993ec610fb..274f4937680 100644
--- libgomp/libgomp_g.h
+++ libgomp/libgomp_g.h
@@ -359,9
This patch adds support for the case where #pragma omp declare variant
with append_args is used inside a #pragma omp dispatch interop that
specifies fewer interop args than required by the variant; new interop
objects are implicitly created and then destroyed around the call to the
variant, using t
On 3/21/25 11:35, Paul-Antoine Arras wrote:
Thanks Sandra and Jakub for your comments.
Here is attached an updated version of the patch:
* Removed special case for n==1, now use an array even when only one
interop object is passed.
* Updated scan dumps; added C/C++ disjunction where needed.
*
On 3/18/25 08:36, Paul-Antoine Arras wrote:
This patch partially enables use of the OpenMP interop construct by adding
middle end support, mostly in the omplower pass, and in the target-independent
part of the libgomp runtime. It follows up on previous patches for C, C++ and
Fortran front ends su
On 3/15/25 19:24, Gerald Pfeifer wrote:
On Thu, 13 Mar 2025, Jose E. Marchesi wrote:
This patch adds a link to the Algol 68 front-end development list to
lists.html. OK?
Sure.
+ https://gcc.gnu.org/ml/algol68/";>algol68 is
+ the discussion and development list for the Algol 68 language fr
The -ansi option has essentially been superseded by the more general
-std= option, and all the additional information about its effects is
already covered elsewhere in the manual. I also cleaned up some
confusing text about alternate keywords that I noticed while
confirming this.
gcc/ChangeLog
o not appear in the table of contents. Does anybody have strong
feelings about this?
I'm also open to arguments if you think I mis-categorized some things,
don't like the new section ordering, etc. I'll hold off on committing this
until next week in case anybody wants to comment o
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Additional Numeric Types): New section.
(__int128): Make it a subsection of the above.
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
gcc/ChangeLog
PR other/42270
* extend.texi (Aggregate Types): New section.
(Variable Length): Make it a subsection of the above.
(
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
gcc/ChangeLog
PR other/42270
* extend.texi (Nonlocal Gotos): Group with other built-ins sections.
(Constructing Calls): Likewise.
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
gcc/ChangeLog
PR other/42270
* extend.texi (Syntax Extensions): New section.
(Statement Exprs): Make it a subsection of the above.
Support for dynamic selectors in "declare variant" was developed in
parallel with support for the adjust_args/append_args clauses and the
dispatch construct; they collided in a bad way. This patch fixes the
"sorry" for calls that need both by removing the adjust_args/append_args
code from gimplify
On 3/10/25 05:53, Christophe Lyon wrote:
Hi!
On Fri, 7 Mar 2025 at 23:57, Sandra Loosemore wrote:
gcc/ChangeLog
PR sanitizer/56682
* doc/invoke.texi (Instrumentation Options): Document that -g
is useful with -fsanitize=thread and -fsanitize=address.
Also
This patch is the C equivalent of commit r15-6512-gcf94ba812ca496 for C++,
to improve the location information for individual items in an OpenMP
variable list.
gcc/c/ChangeLog
PR c/118579
* c-parser.cc (c_parser_omp_variable_list): Capture location
information when KIND is
pe we will not have many more OpenMP patches or bug fixes in GCC 15
that touch non-OpenMP code. :-(
-SandraFrom 4c0786e5dc467b5e3e4c18c0e39c8155d9c8760e Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Sun, 9 Mar 2025 01:50:19 +
Subject: [PATCH] OpenMP: Integrate dynamic selectors
While working on an adjacent documentation fix, I noticed that the
documentation for the gnu++11 "asm constexpr" feature was very
confusing, in some cases being attached to parts of the asm syntax
that are not otherwise required to be string literals, and missing from
other parts of the syntax that
gcc/ChangeLog
PR c/67301
* doc/extend.texi (Extended Asm): Clarify that the square brackets
around the asmSymbolicName of operands are a required part of
the syntax.
---
gcc/doc/extend.texi | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
d
gcc/ChangeLog
PR sanitizer/56682
* doc/invoke.texi (Instrumentation Options): Document that -g
is useful with -fsanitize=thread and -fsanitize=address.
Also mention -fno-omit-frame-pointer per the asan wiki.
---
gcc/doc/invoke.texi | 9 -
1 file changed, 8 i
gcc/ChangeLog
PR target/116708
* doc/invoke.texi (x86 Options): Clarify how -msse4 and -mno-sse4
interact with other SSE options.
---
gcc/doc/invoke.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d9558022073..c6
On 3/7/25 02:21, Jakub Jelinek wrote:
Hi!
This attempts to clarify Complex literal suffixes in the documentation.
Thanks for helping straighten this out!
--- gcc/doc/extend.texi.jj 2025-03-05 06:39:50.263296970 +0100
+++ gcc/doc/extend.texi 2025-03-07 10:00:25.816829046 +0100
@@ -990,19
This option can warn about things other than string and memory functions.
Say so explicitly, and give an example. I also did some copy-editing
of the text and added some paragraph breaks.
gcc/ChangeLog
PR c/113515
* doc/invoke.texi (Warning Options): Improve -Wstringop-overflow
Support for dynamic selectors in "declare variant" was developed in
parallel with support for the adjust_args/append_args clauses and the
dispatch construct; they collided in a bad way. This patch fixes the
"sorry" for calls that need both by removing the adjust_args/append_args
code from gimplify
up and
formatting problems in there as well. :-(
-Sandra
From 3cfe5832d049c55cacc5f73431a4a14e97b2659f Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Sun, 2 Mar 2025 01:43:26 +
Subject: [PATCH] Fortran: Small fixes in intrinsic.texi.
gcc/fortran/ChangeLog
* intrinsic.texi: Fix
nopsis
in the library function documentation with line breaks in random
places, places where using a table for formatting would greatly
improve readability (e.g. _gfortran_set_options), etc. But those are
separate from the issue addressed by this patch series and would need
to be addressed individually by hand.
There's no actual problem with the code here, just a false-positive
warning emitted by some older GCC versions.
gcc/cp/ChangeLog
* parser.cc (cp_finish_omp_declare_variant): Initialize
append_args_last.
---
gcc/cp/parser.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
---
htdocs/gcc-15/changes.html | 7 +++
1 file changed, 7 insertions(+)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index f4ad9569..853fad03 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -66,6 +66,13 @@ a work-in-progress.
New Languages
It appears that bin/preprocess-html.py introduces HTML errors when an
... element contains a nested hyperlink. My recent gcc-15 release
note changes passed validation when checked via file upload, but not after
commit via file link. It seems the easiest fix is just to remove the
offending elemen
---
htdocs/gcc-15/changes.html | 80 --
1 file changed, 50 insertions(+), 30 deletions(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index e273693a..d7919379 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -
For some time I've been seeing this Texinfo warning in my builds:
.../gcc/doc/install.texi:2295: warning: `.' or `,' must follow @xref, not f
Fixed thusly.
gcc/ChangeLog
* doc/install.texi: Add missing comma after @xref to fix warning.
---
gcc/doc/install.texi | 2 +-
1 file changed, 1
I spotted some typos in the GCC manual. Since often these are a sign
that the text was inserted without being proofread, I looked at the
context and fixed some grammar/punctuation/wording issues as well.
gcc/ChangeLog
* doc/extend.texi: Fix a bunch of typos and other writing bugs.
The "Interfacing to GCC Output" chapter used to be part of the
user-facing GCC documentation but ended up in the GCC internals manual
when the two documents were separated in 2001. It hasn't been updated
in any substantive way since then, and is now very bit-rotten. (PCC is
no longer the "standar
This patch implements C++ support for the "begin declare variant"
construct. The OpenMP specification is hazy on interaction of this
feature with C++ language features. Variant functions in classes are
supported but must be defined as members in the class definition,
using an unqualified name for
The OpenMP "begin declare variant" directive has slightly different
requirements for context selectors than regular "declare variant", so
something more than a bool is required to tell the error-checking routine
what to check.
gcc/ChangeLog
* omp-general.cc (omp_check_context_selector): Ch
This patch adds functions for variant name mangling and context selector
merging that are shared by the C and C++ front ends.
The OpenMP specification says that name mangling is supposed to encode
the context selector for the variant, but also provides for no way to
reference these functions direc
gcc/ChangeLog
* omp-general.cc (omp_context_selector_props_compare): Handle
arbitrary expressions in the "user" and "device_num" selectors.
(omp_context_selector_set_compare): Detect mismatch when one
selector specifies a score and the other doesn't.
---
gcc/omp-gen
gcc/c/ChangeLog
* c-decl.cc (current_omp_declare_variant_attribute): Define.
* c-lang.h (struct c_omp_declare_variant_attr): Declare.
(current_omp_declare_variant_attribute): Declare.
* c-parser.cc (c_parser_skip_to_pragma_omp_end_declare_variant): New.
(c_pa
The "begin declare variant" has different rules for determining
whether a context selector cannot match for purposes of code elision
than we normally use; it excludes the case of a constant false
"condition" selector for the "user" set.
gcc/ChangeLog
* omp-general.cc (omp_context_selector_
(e.g. PR118530 and PR118791) causing some
bogus errors that are xfailed in the corresponding test cases.
-Sandra
Sandra Loosemore (7):
OpenMP: Bug fixes for comparing context selectors
OpenMP: Pass a 3-way flag to omp_check_context_selector instead of a
bool.
OpenMP: Support functions for neste
gcc/testsuite/ChangeLog
* c-c++-common/gomp/delim-declare-variant-1.c: New.
* c-c++-common/gomp/delim-declare-variant-2.c: New.
* c-c++-common/gomp/delim-declare-variant-3.c: New.
* c-c++-common/gomp/delim-declare-variant-4.c: New.
* c-c++-common/gomp/delim-d
On 2/10/25 08:50, Tobias Burnus wrote:
Update the GCN install documentation for added ISAs, especially
as no longer all supported ISA are enabled by default. And for
the (ROCm wise: upcoming) generic support.
OK for mainline?
I have no comments on the technical content, but
@@ -3991,14
CTIVE (but the latter
only if the error was not already diagnosed in BEGIN/END METADIRECTIVE).
-SandraFrom 5753f459444fa61a93d23325cd59467dc1838eef Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Sat, 8 Feb 2025 17:44:55 +
Subject: [PATCH] [PATCH] OpenMP: Improve Fortran metadire
The Fortran front end was giving an ICE instead of a user-friendly
diagnostic when variants of a metadirective variant had different
statement associations. The particular test case reported in the issue
also involved invalid placement of the "omp end metadirective" which
was not being diagnosed e
gcc/fortran/ChangeLog
* openmp.cc (resolve_omp_atomic): Fix typo in error message.
gcc/testsuite/ChangeLog
* gfortran.dg/gomp/atomic-26.f90: Correct expected output after
fixing typo in error message.
---
gcc/fortran/openmp.cc| 2 +-
gcc/testsuite/g
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
1 - 100 of 1152 matches
Mail list logo
