On 9/6/25 08:18, Sam James wrote:
Sam James writes:
GNU Binutils now supports linking LTO and non-LTO objects into a single
mixed object file as of 2.44. Update the text to reflect this and fix
some minor grammar issues while at it.
gcc/ChangeLog:
PR ipa/116410
* doc/invoke.t
On 8/31/25 03:56, Jonathan Wakely wrote:
On Sun, 31 Aug 2025 at 10:48 +0100, Jonathan Wakely wrote:
Grr, we also have:
unavailable
unused
used
retain
uninitialized
I can kinda understand unused, used, and retain being grouped together
(although cross-references are a thing) but they should not a
On 8/31/25 03:57, Gerald Pfeifer wrote:
On Sun, 31 Aug 2025, Jonathan Wakely wrote:
gcc/ChangeLog:
* doc/extend.texi (Common Variable Attributes): Put counted_by
in alphabetical order.
---
https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Common-Variable-Attributes.html
currently h
On 8/30/25 09:03, Gerald Pfeifer wrote:
At first I was surprised to see this in one of Sandra's patches, then I
realized it already was there before
commit 35e0f112a487b38d4d3e8eec101a9e0b33a1016b
Author: Sandra Loosemore
Date: Wed Mar 26 04:16:24 2025 +
Doc: Bre
On 8/29/25 02:31, Tobias Burnus wrote:
Hi Sandra, hi Andrew, hello world,
Sandra Loosemore wrote:
The GCC user manual lists all the *-generic options for -march as
"Experimental". Is that still the case? If not, I'll consider a
patch to remove "Experimental" as t
On 8/28/25 06:17, Tobias Burnus wrote:
This kind of came up because now objdump is required during the GCC
build (for ./configure) to set the required HAVE_..., solving PR119367.
While LLVM's assembler and linker are required to handle AMD GPUs,
all others just need to be found and can be the LL
On 8/26/25 08:47, Tobias Burnus wrote:
Hi Sandra,
Sandra Loosemore wrote:
On 8/26/25 05:26, Jakub Jelinek wrote:
I wouldn't emit sorry for targets where we already implement it
"correctly",
i.e. at least all targets which have NULL
targetm.simd_clone.compute_vecsize_and_si
On 8/26/25 05:26, Jakub Jelinek wrote:
On Mon, Aug 25, 2025 at 08:24:18PM -0600, Sandra Loosemore wrote:
On 8/25/25 00:13, Jakub Jelinek wrote:
Yes, GCC doesn't have it implemented fully, but that doesn't mean it should
be ripped off, the implementation should be simply finished.
uld update the PR, BTW. There also
needs to be some actual specification of the implementation-defined
functionality that could serve as the basis for user-facing documentation.
-Sandra
From aa3ffbaf19236a54ac6c0ac54e84787b81180ac0 Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Mon, 25 A
On 8/25/25 09:29, Jakub Jelinek wrote:
On Mon, Aug 25, 2025 at 09:13:58AM -0600, Sandra Loosemore wrote:
How? Declare variant substitution presently happens primarily during
gimplification which is way before any vectorization happens. And fixing
the various bugs esp in the C++ front end with
On 8/25/25 00:13, Jakub Jelinek wrote:
On Sun, Aug 24, 2025 at 08:16:32PM -0600, Sandra Loosemore wrote:
As noted in PR middle-end/121630, GCC seems to think that the "simd"
construct selector on "declare variant" implies that the variant
function accepts vectorized argumen
As noted in the issue, the C++ front end has deeper problems: it's
supposed to do the name lookup of the variant at the call site but is
instead doing it when parsing the "declare variant" construct, before
registering the decl for the base function. The C++ part of the
patch is a band-aid to catc
As noted in PR middle-end/121630, GCC seems to think that the "simd"
construct selector on "declare variant" implies that the variant
function accepts vectorized arguments, although this is not anywhere
in the OpenMP specification. Additionally, it does not actually
vectorize the calls when doing
This patch fixes a number of problems with parser error checking of
"declare variant", especially in the C front end.
The new C testcase unprototyped-variant.c added by this patch used to
ICE when gimplifying the call site, at least in part because the
variant was being recorded even after it was
I
opened a new issue PR121630 for this. Getting rid of the unneeded
conditional introduced whitespace changes so the code changes for
this look a lot hairier than they actually are.
Part 3 is also new, at least partially addressing another missing-diagnostic
issue PR118839 that I spotted while se
On 8/11/25 11:03, Tobias Burnus wrote:
[snip]
As you are adding comments, I think you also need to add one for
the 'not construct={simd}'.
That those are skipped is part of commit r10-3744-g94e7f906ca5c73,
i.e. pretty old.
I bet is has something to do with the modifications done via
c_omp_decl
won't be finished
until tomorrow. Assuming no problems there, OK to commit?
-SandraFrom 3b0ea4a2768d21c22deadb2f0e7ad5e617f59849 Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Sun, 10 Aug 2025 02:31:29 +
Subject: [PATCH] OpenMP: Improve front-end error-checking for "declare
var
On 6/9/25 23:56, Jan Beulich wrote:
On 06.06.2025 17:28, Sandra Loosemore wrote:
On 6/6/25 00:44, Jan Beulich wrote:
As per documentation, even 4.7 ought to suffice. At least 4.13 objects
to there being nothing ahead of the first comma in @xref{}.
---
The text inserted it merely a guess; I&#
On 6/6/25 00:44, Jan Beulich wrote:
As per documentation, even 4.7 ought to suffice. At least 4.13 objects
to there being nothing ahead of the first comma in @xref{}.
---
The text inserted it merely a guess; I'm open to better suggestions.
Noticed with gcc15, so may want backporting.
--- a/gcc/
On 6/4/25 08:15, Tobias Burnus wrote:
This came up when looking at some context selectors that use
'target_device',
but is largely unrelated to it. (target_device has its own special casing).
Namely, it makes omp_get_initial_device and omp_get_num_devices PURE,
which attributes don't permit for
My previous patch that added a CLEANUP_POINT_EXPR around the device_num
selector expression in the C++ front end broke the testcase
c-c++-common/gomp/metadirective-target-device-2.c on offload targets.
It confused the code in omp_device_num_check that tries to bypass error
checking and do early res
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
1 - 100 of 1190 matches
Mail list logo
