On 6/2/25 12:15, Tobias Burnus wrote:
Not really new - but as the topic came up elsewhere (OpenMP issue 4455),
I had a second thought about this and I think it make sense to add a note.
GCC uses the OpenMP 6.0 version.
The problem is that 'int'/'int*' became 'omp_interop_rc_t ret_code'
and 'omp
On 5/29/25 22:19, Tobias Burnus wrote:
Sandra Loosemore wrote:
Like the attached V2 patch?
LGTM.
However, I think in metadirective-condition-template.C the
"scan-tree-dump" should now be changed to "scan-tree-dump-times", given
that there are several tests.
Yup, goo
On 5/30/25 16:36, Tobias Burnus wrote:
Attached patch adds omp_target_memset and omp_target_memset_async
permitting to set (potentially large) data on the device to a
certain value - in particular to '\0'.
It uses 'memset' on the host (and for shared memory, e.g. via
requires unified_shared_memo
On 5/29/25 02:51, Tobias Burnus wrote:
@Jason – The idea is make semantics.cc's maybe_convert_cond callable
from parser.cc + pt.cc, i.e. to make it a non-static function.
Any reasons not do so?
Sandra Loosemore wrote:
[…] By using the existing front-end
hooks for the implicit conversi
The new testcase included in this patch used to ICE in gcc after
diagnosing the first error, and in g++ it only diagnosed the error in
the first metadirective, ignoring the second one. The solution is to
make error recovery in the C front end more like that in the C++ front
end, and remove the cod
here, which is
rejected without this patch (and triggers the ICE fixed by part 2).
OK for trunk, at least?
Sandra Loosemore (3):
OpenMP: Fix ICE in metadirective recovery after error [PR120180]
OpenMP: Fix ICE and other issues in C/C++ metadirective error
recovery.
OpenMP: Handle more
It's not clear whether a metadirective in a loop nest is supposed to
be valid, but GCC certainly shouldn't be ICE'ing after diagnosing it
as an error.
gcc/c/ChangeLog
PR c/120180
* c-parser.cc (c_parser_omp_metadirective): Only consume the
token if it is the expected ')'.
Tobias had noted that the C front end was not treating C23 constexprs
as constant in the user/condition selector property, which led to
missed opportunities to resolve metadirectives at parse time.
Additionally neither C nor C++ was permitting the expression to have
pointer or floating-point type -
* git.html: Note that devel/omp/gcc-15 exists, and that the
corresponding gcc-14 branch is now stale.
---
htdocs/git.html | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/htdocs/git.html b/htdocs/git.html
index 8edaa254..0b55a970 100644
--- a/htdocs
On 5/13/25 02:22, Tobias Burnus wrote:
[snip]
How about the attached patch? With it, running
./contrib/gcc-changelog/git_update_version.py \
--suffix '.omp' -c \
--exclude-branch=origin/releases/gcc-15 \
--last-commit=0b76b58a5875d519f95a5af661fb64e42a42ed8e
works where --last-c
On 5/13/25 02:22, Tobias Burnus wrote:
Hi Sandra, hello world,
Sandra Loosemore wrote:
I have created the devel/omp/gcc-15 (aka "OG15") branch, ...
For previous branches we'd been using ChangeLog.omp files paralleling
the normal ChangeLog files, that were updated manuall
evelopment branch in use
at a time, so next year at this time we would be wanting to replace
devel/omp/gcc-15 with devel/omp/gcc-16 in the list, not have have both
branches in the list.
-Sandra
From 187d823aa916b558e7f2935022619593eb66c005 Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Da
Hi all,
The first two pieces of this patch series
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675464.html
were approved and committed for GCC 15, but the remaining 5 parts are
still awaiting review. I was hoping that I could get these in early in
stage 1, or at least be told earl
Tobias asked me to push the attached patch on his behalf. I verified
that the testcase still does pass on mainline. :-)
-Sandra
From 08ce1b9f6707e00089c4d77d2bb82963d531bb1d Mon Sep 17 00:00:00 2001
From: Tobias Burnus
Date: Thu, 1 May 2025 15:39:42 +
Subject: [COMMITTED, OBVIOUS] OpenMP
edit where it is due, this is mostly Tobias's work; he wrote
the testcases and some patch fragments, and I just made it all work.
-Sandra
From 0cd1f6905336404f5af3c2ed4a7577e657500260 Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Sat, 26 Apr 2025 02:22:39 +
Subject: [PATCH] Op
On 4/27/25 15:57, Owen Avery wrote:
This patch should make it easier to selectively disable
-Wvirtual-move-assign errors by adding an attribute
for move assignment operators which marks them as handling
duplicate calls.
I'm only qualified to comment on the documentation part of the patch.
dif
On 4/17/25 14:16, Jonathan Wakely wrote:
On 11/03/25 17:39 +, Jonathan Wakely wrote:
Add anchors for the hardbool and uninitialized attributes and then link
directly to them.
gcc/ChangeLog:
* doc/extend.texi (Common Variable Attributes): Add @anchor to
hardbool attribute.
(Comm
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
1 - 100 of 1169 matches
Mail list logo
