[gcc r15-205] OpenMP: Fix for ICE in tree-nested.cc.
https://gcc.gnu.org/g:80c03ac8041340b29325f86ed58ea8bd40a55b99 commit r15-205-g80c03ac8041340b29325f86ed58ea8bd40a55b99 Author: Sandra Loosemore Date: Mon Apr 22 18:24:25 2024 + OpenMP: Fix for ICE in tree-nested.cc. Use gimple_omp_target_clauses() instead of gimple_omp_taskreg_clauses() when stmt is GIMPLE_OMP_TARGET, to avoid an as_a<> ICE. The code immediately following this is already conditionalized in the same way. gcc/ChangeLog * tree-nested.cc (convert_tramp_reference_stmt): Use the correct accessor for GIMPLE_OMP_TARGET clauses. Diff: --- gcc/tree-nested.cc | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/gcc/tree-nested.cc b/gcc/tree-nested.cc index 4e5f3be7676..fc0495d6443 100644 --- a/gcc/tree-nested.cc +++ b/gcc/tree-nested.cc @@ -2906,9 +2906,11 @@ convert_tramp_reference_stmt (gimple_stmt_iterator *gsi, bool *handled_ops_p, continue; decl = i ? get_chain_decl (info) : info->frame_decl; /* Don't add CHAIN.* or FRAME.* twice. */ - for (c = gimple_omp_taskreg_clauses (stmt); -c; -c = OMP_CLAUSE_CHAIN (c)) + if (gimple_code (stmt) == GIMPLE_OMP_TARGET) + c = gimple_omp_target_clauses (stmt); + else + c = gimple_omp_taskreg_clauses (stmt); + for (; c; c = OMP_CLAUSE_CHAIN (c)) if ((OMP_CLAUSE_CODE (c) == OMP_CLAUSE_FIRSTPRIVATE || OMP_CLAUSE_CODE (c) == OMP_CLAUSE_SHARED) && OMP_CLAUSE_DECL (c) == decl)
[gcc r15-1613] Fix PR c/115587, uninitialized variable in c_parser_omp_loop_nest
https://gcc.gnu.org/g:21f1073d388af8af207183b0ed592e1cc47d20ab
commit r15-1613-g21f1073d388af8af207183b0ed592e1cc47d20ab
Author: Sandra Loosemore
Date: Tue Jun 25 13:54:43 2024 +
Fix PR c/115587, uninitialized variable in c_parser_omp_loop_nest
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 didn't have this problem, but I've made similar
changes there to keep the code in sync.
gcc/c/ChangeLog:
PR c/115587
* c-parser.cc (c_parser_omp_loop_nest): Move initializations to
point of declaration.
gcc/cp/ChangeLog:
PR c/115587
* parser.cc (cp_parser_omp_loop_nest): Move initializations to
point of declaration.
Diff:
---
gcc/c/c-parser.cc | 4 +---
gcc/cp/parser.cc | 8 ++--
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index e83e9c683f7..33643ec910a 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -22430,7 +22430,7 @@ static tree c_parser_omp_unroll (location_t, c_parser
*, bool *);
static tree
c_parser_omp_loop_nest (c_parser *parser, bool *if_p)
{
- tree decl, cond, incr, init;
+ tree decl = NULL_TREE, cond = NULL_TREE, incr = NULL_TREE, init = NULL_TREE;
tree body = NULL_TREE;
matching_parens parens;
bool moreloops;
@@ -22619,7 +22619,6 @@ c_parser_omp_loop_nest (c_parser *parser, bool *if_p)
}
/* Parse the loop condition. */
- cond = NULL_TREE;
if (c_parser_next_token_is_not (parser, CPP_SEMICOLON))
{
location_t cond_loc = c_parser_peek_token (parser)->location;
@@ -22652,7 +22651,6 @@ c_parser_omp_loop_nest (c_parser *parser, bool *if_p)
c_parser_skip_until_found (parser, CPP_SEMICOLON, "expected %<;%>");
/* Parse the increment expression. */
- incr = NULL_TREE;
if (c_parser_next_token_is_not (parser, CPP_CLOSE_PAREN))
{
location_t incr_loc = c_parser_peek_token (parser)->location;
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index e7409b856f1..e5f16fe963d 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -45153,8 +45153,8 @@ static tree cp_parser_omp_tile (cp_parser *, cp_token
*, bool *);
static tree
cp_parser_omp_loop_nest (cp_parser *parser, bool *if_p)
{
- tree decl, cond, incr, init;
- tree orig_init, real_decl, orig_decl;
+ tree decl = NULL_TREE, cond = NULL_TREE, incr = NULL_TREE, init = NULL_TREE;
+ tree orig_init = NULL_TREE, real_decl = NULL_TREE, orig_decl = NULL_TREE;
tree init_block, body_block;
tree init_placeholder, body_placeholder;
tree init_scope;
@@ -45324,8 +45324,6 @@ cp_parser_omp_loop_nest (cp_parser *parser, bool *if_p)
if (!parens.require_open (parser))
return NULL;
- init = orig_init = decl = real_decl = orig_decl = NULL_TREE;
-
init_placeholder = build_stmt (input_location, EXPR_STMT,
integer_zero_node);
vec_safe_push (omp_for_parse_state->init_placeholderv, init_placeholder);
@@ -45501,12 +45499,10 @@ cp_parser_omp_loop_nest (cp_parser *parser, bool
*if_p)
}
}
- cond = NULL;
if (cp_lexer_next_token_is_not (parser->lexer, CPP_SEMICOLON))
cond = cp_parser_omp_for_cond (parser, decl, omp_for_parse_state->code);
cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON);
- incr = NULL;
if (cp_lexer_next_token_is_not (parser->lexer, CPP_CLOSE_PAREN))
{
/* If decl is an iterator, preserve the operator on decl
[gcc r14-10346] Fix PR c/115587, uninitialized variable in c_parser_omp_loop_nest
https://gcc.gnu.org/g:b383719aebe45bbe8cc3944e515ed7caa30e8744
commit r14-10346-gb383719aebe45bbe8cc3944e515ed7caa30e8744
Author: Sandra Loosemore
Date: Tue Jun 25 13:54:43 2024 +
Fix PR c/115587, uninitialized variable in c_parser_omp_loop_nest
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 didn't have this problem, but I've made similar
changes there to keep the code in sync.
gcc/c/ChangeLog:
PR c/115587
* c-parser.cc (c_parser_omp_loop_nest): Move initializations to
point of declaration.
gcc/cp/ChangeLog:
PR c/115587
* parser.cc (cp_parser_omp_loop_nest): Move initializations to
point of declaration.
(cherry picked from commit 21f1073d388af8af207183b0ed592e1cc47d20ab)
Diff:
---
gcc/c/c-parser.cc | 4 +---
gcc/cp/parser.cc | 8 ++--
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 00f8bf4376e..5fcfff7134a 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -22240,7 +22240,7 @@ c_parser_omp_scan_loop_body (c_parser *parser, bool
open_brace_parsed)
static tree
c_parser_omp_loop_nest (c_parser *parser, bool *if_p)
{
- tree decl, cond, incr, init;
+ tree decl = NULL_TREE, cond = NULL_TREE, incr = NULL_TREE, init = NULL_TREE;
tree body = NULL_TREE;
matching_parens parens;
bool moreloops;
@@ -22330,7 +22330,6 @@ c_parser_omp_loop_nest (c_parser *parser, bool *if_p)
}
/* Parse the loop condition. */
- cond = NULL_TREE;
if (c_parser_next_token_is_not (parser, CPP_SEMICOLON))
{
location_t cond_loc = c_parser_peek_token (parser)->location;
@@ -22363,7 +22362,6 @@ c_parser_omp_loop_nest (c_parser *parser, bool *if_p)
c_parser_skip_until_found (parser, CPP_SEMICOLON, "expected %<;%>");
/* Parse the increment expression. */
- incr = NULL_TREE;
if (c_parser_next_token_is_not (parser, CPP_CLOSE_PAREN))
{
location_t incr_loc = c_parser_peek_token (parser)->location;
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 6b786ed8266..7e81c1010c4 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -44756,8 +44756,8 @@ cp_parser_omp_scan_loop_body (cp_parser *parser)
static tree
cp_parser_omp_loop_nest (cp_parser *parser, bool *if_p)
{
- tree decl, cond, incr, init;
- tree orig_init, real_decl, orig_decl;
+ tree decl = NULL_TREE, cond = NULL_TREE, incr = NULL_TREE, init = NULL_TREE;
+ tree orig_init = NULL_TREE, real_decl = NULL_TREE, orig_decl = NULL_TREE;
tree init_block, body_block;
tree init_placeholder, body_placeholder;
tree init_scope;
@@ -44793,8 +44793,6 @@ cp_parser_omp_loop_nest (cp_parser *parser, bool *if_p)
if (!parens.require_open (parser))
return NULL;
- init = orig_init = decl = real_decl = orig_decl = NULL_TREE;
-
init_placeholder = build_stmt (input_location, EXPR_STMT,
integer_zero_node);
vec_safe_push (omp_for_parse_state->init_placeholderv, init_placeholder);
@@ -44970,12 +44968,10 @@ cp_parser_omp_loop_nest (cp_parser *parser, bool
*if_p)
}
}
- cond = NULL;
if (cp_lexer_next_token_is_not (parser->lexer, CPP_SEMICOLON))
cond = cp_parser_omp_for_cond (parser, decl, omp_for_parse_state->code);
cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON);
- incr = NULL;
if (cp_lexer_next_token_is_not (parser->lexer, CPP_CLOSE_PAREN))
{
/* If decl is an iterator, preserve the operator on decl
[gcc r14-10031] Add nios2*-*-* to the list of obsolete targets
https://gcc.gnu.org/g:e498ba92355881a91f271860f9de359d913e5a68
commit r14-10031-ge498ba92355881a91f271860f9de359d913e5a68
Author: Sandra Loosemore
Date: Mon Apr 8 14:36:08 2024 +
Add nios2*-*-* to the list of obsolete targets
This patch marks the nios2*-*-* targets obsolete in GCC 14. Intel has
EOL'ed this architecture and the maintainers no longer have access to
hardware for testing. While the port is still in reasonably good
shape at this time, no further testing or updates are planned.
gcc/
* config.gcc: Add nios2*-*-* to the list of obsoleted targets.
contrib/
* config-list.mk (LIST): --enable-obsolete for nios2*-*-*.
Diff:
---
contrib/config-list.mk | 3 ++-
gcc/config.gcc | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index 16df66f0fc6..f282cd95c8d 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -78,7 +78,8 @@ LIST = \
moxie-uclinux moxie-rtems \
msp430-elf msp430-elfbare \
nds32le-elf nds32be-elf \
- nios2-elf nios2-linux-gnu nios2-rtems \
+ nios2-elfOPT-enable-obsolete nios2-linux-gnuOPT-enable-obsolete \
+ nios2-rtemsOPT-enable-obsolete \
nvptx-none \
or1k-elf or1k-linux-uclibc or1k-linux-musl or1k-rtems \
pdp11-aout \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5df3c52f8e9..029ad1f1f08 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -274,6 +274,7 @@ esac
case ${target}${target_min} in
*-*-solaris2.11.[0-3]* \
| ia64*-*-* \
+ | nios2*-*-*\
)
if test "x$enable_obsolete" != xyes; then
echo "*** Configuration ${target}${target_min} is obsolete." >&2
[gcc r15-3847] OpenMP: Fix testsuite failure on x86 with -m32
https://gcc.gnu.org/g:6935bddd8f90dde6009a1b8dea9745788ceeefb1
commit r15-3847-g6935bddd8f90dde6009a1b8dea9745788ceeefb1
Author: Sandra Loosemore
Date: Wed Sep 25 02:59:53 2024 +
OpenMP: Fix testsuite failure on x86 with -m32
The testcase decare-variant-duplicates.c added in commit
96246bff0bcd9e5cdec9e6cf811ee3db4997f6d4 failed on 32-bit x86
because on that target "i386" is defined as a preprocessor macro
and cannot be used as an identifier. Fixed by rewriting that test
not to do that.
gcc/testsuite/ChangeLog
* c-c++-common/gomp/declare-variant-duplicates.c: Avoid using
"i386" as an identifier.
Diff:
---
gcc/testsuite/c-c++-common/gomp/declare-variant-duplicates.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/c-c++-common/gomp/declare-variant-duplicates.c
b/gcc/testsuite/c-c++-common/gomp/declare-variant-duplicates.c
index 47d34fc52e2f..9f319c724492 100644
--- a/gcc/testsuite/c-c++-common/gomp/declare-variant-duplicates.c
+++ b/gcc/testsuite/c-c++-common/gomp/declare-variant-duplicates.c
@@ -8,6 +8,6 @@ extern int f4 (int);
#pragma omp declare variant (f1) match (device={kind(cpu,gpu,"cpu")}) /* {
dg-error "trait-property .cpu. specified more than once" } */
#pragma omp declare variant (f2) match (device={isa(sse4,"avx",avx)}) /* {
dg-error "trait-property .avx. specified more than once" } */
-#pragma omp declare variant (f3) match
(device={arch(x86_64,i386,aarch64,"i386")}) /* { dg-error "trait-property
.i386. specified more than once" } */
+#pragma omp declare variant (f3) match
(device={arch(x86_64,"i386",aarch64,"x86_64")}) /* { dg-error "trait-property
.x86_64. specified more than once" } */
#pragma omp declare variant (f4) match
(implementation={vendor(llvm,gnu,"arm",gnu)}) /* { dg-error "trait-property
.gnu. specified more than once" } */
int f (int);
[gcc r15-3834] OpenMP: Check additional restrictions on context selector properties
https://gcc.gnu.org/g:96246bff0bcd9e5cdec9e6cf811ee3db4997f6d4
commit r15-3834-g96246bff0bcd9e5cdec9e6cf811ee3db4997f6d4
Author: Sandra Loosemore
Date: Fri Sep 6 20:58:13 2024 +
OpenMP: Check additional restrictions on context selector properties
TR13 (pre-6.0) of the OpenMP spec says:
"Each trait-property may only be specified once in a trait selector
other than those in the construct selector set."
and
"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."
These restrictions (with slightly different wording) date back to
OpenMP 5.1, but were not in 5.0 which was the basis for GCC's
implementation.
This patch adds a diagnostic, adds new testcases, and fixes some older
testcases that include now-invalid selectors.
gcc/ChangeLog
* omp-general.cc (omp_check_context_selector): Reject other
properties in the same selector set with kind(any). Also reject
duplicate name-list properties.
gcc/testsuite/ChangeLog
* c-c++-common/gomp/declare-variant-10.c: Fix broken tests.
* c-c++-common/gomp/declare-variant-3.c: Likewise.
* c-c++-common/gomp/declare-variant-9.c: Likewise.
* c-c++-common/gomp/declare-variant-any.c: New.
* c-c++-common/gomp/declare-variant-duplicates.c: New.
* gfortran.dg/gomp/declare-variant-10.f90: Fix broken tests.
* gfortran.dg/gomp/declare-variant-3.f90: Likewise.
* gfortran.dg/gomp/declare-variant-9.f90: Likewise.
* gfortran.dg/gomp/declare-variant-any.f90: New.
* gfortran.dg/gomp/declare-variant-duplicates.f90: New.
Diff:
---
gcc/omp-general.cc | 64 +-
.../c-c++-common/gomp/declare-variant-10.c | 4 +-
.../c-c++-common/gomp/declare-variant-3.c | 10 +---
.../c-c++-common/gomp/declare-variant-9.c | 4 +-
.../c-c++-common/gomp/declare-variant-any.c| 17 ++
.../c-c++-common/gomp/declare-variant-duplicates.c | 13 +
.../gfortran.dg/gomp/declare-variant-10.f90| 4 +-
.../gfortran.dg/gomp/declare-variant-3.f90 | 12 +---
.../gfortran.dg/gomp/declare-variant-9.f90 | 2 +-
.../gfortran.dg/gomp/declare-variant-any.f90 | 40 ++
.../gomp/declare-variant-duplicates.f90| 30 ++
11 files changed, 176 insertions(+), 24 deletions(-)
diff --git a/gcc/omp-general.cc b/gcc/omp-general.cc
index c93bf129e4d7..9713e684e830 100644
--- a/gcc/omp-general.cc
+++ b/gcc/omp-general.cc
@@ -1293,6 +1293,8 @@ omp_check_context_selector (location_t loc, tree ctx)
for (tree tss = ctx; tss; tss = TREE_CHAIN (tss))
{
enum omp_tss_code tss_code = OMP_TSS_CODE (tss);
+ bool saw_any_prop = false;
+ bool saw_other_prop = false;
/* We can parse this, but not handle it yet. */
if (tss_code == OMP_TRAIT_SET_TARGET_DEVICE)
@@ -1329,9 +1331,61 @@ omp_check_context_selector (location_t loc, tree ctx)
else
ts_seen[ts_code] = true;
+ /* 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. */
+ if (ts_code == OMP_TRAIT_DEVICE_KIND)
+ for (tree p = OMP_TS_PROPERTIES (ts); p; p = TREE_CHAIN (p))
+ {
+ const char *prop = omp_context_name_list_prop (p);
+ if (!prop)
+ continue;
+ else if (strcmp (prop, "any") == 0)
+ saw_any_prop = true;
+ else
+ saw_other_prop = true;
+ }
+ /* It seems slightly suspicious that the spec's language covers
+the device_num selector too, but
+ target_device={device_num(whatever),kind(any)}
+is probably not terribly useful anyway. */
+ else if (ts_code == OMP_TRAIT_DEVICE_ARCH
+ || ts_code == OMP_TRAIT_DEVICE_ISA
+ || ts_code == OMP_TRAIT_DEVICE_NUM)
+ saw_other_prop = true;
+
+ /* Each trait-property can only be specified once in a trait-selector
+other than the construct selector set. FIXME: only handles
+name-list properties, not clause-list properties, since the
+"requires" selector is not implemented yet (PR 113067). */
+ if (tss_code != OMP_TRAIT_SET_CONSTRUCT)
+ for (tree p1 = OMP_TS_PROPERTIES (ts); p1; p1 = TREE_CHAIN (p1))
+ {
+ if (OMP_TP_NAME (p1) != OMP_TP_NAMELIST_NODE)
+ break;
+ const char *n1 = omp_context_name_list_prop (p1);
+
[gcc r15-6481] Fortran: Grammar/markup fixes in intrinsics documentation
https://gcc.gnu.org/g:2c5761025a96e78921ef17d83fc8e7a11b2d1115
commit r15-6481-g2c5761025a96e78921ef17d83fc8e7a11b2d1115
Author: Sandra Loosemore
Date: Fri Dec 27 20:45:14 2024 +
Fortran: Grammar/markup fixes in intrinsics documentation
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.
Diff:
---
gcc/fortran/intrinsic.texi | 100 ++---
1 file changed, 50 insertions(+), 50 deletions(-)
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index d11d37761d92..b47180126caa 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -348,10 +348,10 @@ another kind, which have more precision. On typical
target architectures
supported by @command{gfortran}, this kind type parameter is @code{KIND=8}.
Hence, @code{REAL(KIND=8)} and @code{DOUBLE PRECISION} are equivalent.
In the description of generic intrinsic procedures, the kind type parameter
-will be specified by @code{KIND=*}, and in the description of specific
-names for an intrinsic procedure the kind type parameter will be explicitly
+is specified by @code{KIND=*}, and in the description of specific
+names for an intrinsic procedure the kind type parameter is explicitly
given (e.g., @code{REAL(KIND=4)} or @code{REAL(KIND=8)}). Finally, for
-brevity the optional @code{KIND=} syntax will be omitted.
+brevity the optional @code{KIND=} syntax is omitted.
Many of the intrinsic procedures take one or more optional arguments.
This document follows the convention used in the Fortran 95 standard,
@@ -380,8 +380,8 @@ the applicable standard for each intrinsic procedure is
noted.
@table @asis
@item @emph{Description}:
@code{ABORT} causes immediate termination of the program. On operating
-systems that support a core dump, @code{ABORT} will produce a core dump.
-It will also print a backtrace, unless @code{-fno-backtrace} is given.
+systems that support a core dump, @code{ABORT} produces a core dump.
+It also prints a backtrace, unless @code{-fno-backtrace} is given.
@item @emph{Standard}:
GNU extension
@@ -759,7 +759,7 @@ Inverse function: @*
@table @asis
@item @emph{Description}:
-@code{ADJUSTL(STRING)} will left adjust a string by removing leading spaces.
+@code{ADJUSTL(STRING)} left adjusts a string by removing leading spaces.
Spaces are inserted at the end of the string as needed.
@item @emph{Standard}:
@@ -805,7 +805,7 @@ end program test_adjustl
@table @asis
@item @emph{Description}:
-@code{ADJUSTR(STRING)} will right adjust a string by removing trailing spaces.
+@code{ADJUSTR(STRING)} right adjusts a string by removing trailing spaces.
Spaces are inserted at the start of the string as needed.
@item @emph{Standard}:
@@ -929,7 +929,7 @@ expression indicating the kind parameter of the result.
@item @emph{Return value}:
The return value is of type @code{REAL} with the kind type parameter of the
argument if the optional @var{KIND} is absent; otherwise, the kind
-type parameter will be given by @var{KIND}. If the magnitude of
+type parameter is given by @var{KIND}. If the magnitude of
@var{X} is less than one, @code{AINT(X)} returns zero. If the
magnitude is equal to or greater than one then it returns the largest
whole number that does not exceed its magnitude. The sign is the same
@@ -967,7 +967,7 @@ end program test_aint
@code{ALARM(SECONDS, HANDLER [, STATUS])} causes external subroutine
@var{HANDLER}
to be executed after a delay of @var{SECONDS} by using @code{alarm(2)} to
set up a signal and @code{signal(2)} to catch it. If @var{STATUS} is
-supplied, it will be returned with the number of seconds remaining until
+supplied, it is returned with the number of seconds remaining until
any previously scheduled alarm was due to be delivered, or zero if there
was no previously scheduled alarm.
@@ -1002,7 +1002,7 @@ program test_alarm
call sleep(10)
end program test_alarm
@end smallexample
-This will cause the external routine @var{handler_print} to be called
+This causes the external routine @var{handler_print} to be called
after 3 seconds.
@end table
@@ -1211,7 +1211,7 @@ expression indicating the kind parameter of the result.
@item @emph{Return value}:
The return value is of type real with the kind type parameter of the
argument if the optional @var{KIND} is absent; otherwise, the kind
-type parameter will be given by @var{KIND}. If @var{A} is greater than
+type parameter is given by @var{KIND}. If @var{A} is greater than
zero, @code{ANINT(A)} returns @code{AINT(X+0.5)}. If @var{A} is
less than or equal to zero then it returns @code{AINT(X-0.5)}.
@@ -1577,7 +1577,7 @@ if @var{Y} is present, @var{X} shall be REAL.
@item @emph{Return value}:
The r
[gcc r15-6483] Fortran: Fix Texinfo warnings building the manual.
https://gcc.gnu.org/g:f8cd181e2d1d5541681ea7e3e92c8da46b048979 commit r15-6483-gf8cd181e2d1d5541681ea7e3e92c8da46b048979 Author: Sandra Loosemore Date: Sat Dec 28 16:29:44 2024 + Fortran: Fix Texinfo warnings building the manual. gcc/fortran/ChangeLog * gfortran.texi (Function ABI Documentation): Make menu ordering consistent with subsection ordering. Diff: --- 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 eb17aff7e381..4509f080ba45 100644 --- a/gcc/fortran/gfortran.texi +++ b/gcc/fortran/gfortran.texi @@ -4197,9 +4197,9 @@ future implementation of teams. It is about to change without further notice. * _gfortran_caf_send:: Sending data from a local image to a remote image * _gfortran_caf_get:: Getting data from a remote image * _gfortran_caf_sendget:: Sending data between remote images -* _gfortran_caf_get_by_ct:: Getting data from a remote image using a remote side accessor * _gfortran_caf_send_by_ref:: Sending data from a local image to a remote image using enhanced references * _gfortran_caf_get_by_ref:: Getting data from a remote image using enhanced references +* _gfortran_caf_get_by_ct:: Getting data from a remote image using a remote side accessor * _gfortran_caf_sendget_by_ref:: Sending data between remote images using enhanced references * _gfortran_caf_lock:: Locking a lock variable * _gfortran_caf_unlock:: Unlocking a lock variable
[gcc r15-7292] OpenMP: Update documentation of metadirective implementation status.
https://gcc.gnu.org/g:4e6fd85ba53385cc4968969d75639e0f5d8c9f07
commit r15-7292-g4e6fd85ba53385cc4968969d75639e0f5d8c9f07
Author: Sandra Loosemore
Date: Thu Jan 30 16:45:27 2025 +
OpenMP: Update documentation of metadirective implementation status.
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.
(OpenMP 5.2): Mark otherwise clause as supported, note that
default is also still accepted.
Diff:
---
libgomp/libgomp.texi | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index ec0e06d27ecd..d1cf9be47ca5 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -192,9 +192,8 @@ The OpenMP 4.5 specification is fully supported.
@item Array shaping @tab N @tab
@item Array sections with non-unit strides in C and C++ @tab N @tab
@item Iterators @tab Y @tab
-@item @code{metadirective} directive @tab N @tab
-@item @code{declare variant} directive
- @tab P @tab @emph{simd} traits not handled correctly
+@item @code{metadirective} directive @tab Y @tab
+@item @code{declare variant} directive @tab Y @tab
@item @var{target-offload-var} ICV and @code{OMP_TARGET_OFFLOAD}
env variable @tab Y @tab
@item Nested-parallel changes to @var{max-active-levels-var} ICV @tab Y @tab
@@ -289,8 +288,8 @@ The OpenMP 4.5 specification is fully supported.
@headitem Description @tab Status @tab Comments
@item OpenMP directive as C++ attribute specifiers @tab Y @tab
@item @code{omp_all_memory} reserved locator @tab Y @tab
-@item @emph{target_device trait} in OpenMP Context @tab N @tab
-@item @code{target_device} selector set in context selectors @tab N @tab
+@item @emph{target_device trait} in OpenMP Context @tab Y
+@item @code{target_device} selector set in context selectors @tab Y @tab
@item C/C++'s @code{declare variant} directive: elision support of
preprocessed code @tab N @tab
@item @code{declare variant}: new clauses @code{adjust_args} and
@@ -367,6 +366,13 @@ to address of matching mapped list item per 5.1, Sect.
2.21.7.2 @tab N @tab
@item @code{device_type(nohost)}/@code{device_type(host)} for variables @tab N
@tab
@item @code{present} modifier to the @code{map}, @code{to} and @code{from}
clauses @tab Y @tab
+@item Changed interaction between @code{declare target} and OpenMP context
+ @tab Y @tab
+@item Dynamic selector support in @code{metadirective} @tab Y @tab
+@item Dynamic selector support in @code{declare variant} @tab P
+ @tab Fortran rejects non-constant expressions in dynamic selectors;
+ C/C++ reject expressions using argument variables.
+ (@uref{https://gcc.gnu.org/PR113904,PR113904})
@end multitable
@@ -414,8 +420,10 @@ to address of matching mapped list item per 5.1, Sect.
2.21.7.2 @tab N @tab
@item Deprecation of traits array following the allocator_handle expression in
@code{uses_allocators} @tab N @tab
@item New @code{otherwise} clause as alias for @code{default} on metadirectives
- @tab N @tab
-@item Deprecation of @code{default} clause on metadirectives @tab N @tab
+ @tab Y @tab
+@item Deprecation of @code{default} clause on metadirectives @tab N
+ @tab Both @code{otherwise} and @code{default} are accepted
+ without diagnostics.
@item Deprecation of delimited form of @code{declare target} @tab N @tab
@item Reproducible semantics changed for @code{order(concurrent)} @tab N @tab
@item @code{allocate} and @code{firstprivate} clauses on @code{scope}
[gcc r15-7291] OpenMP: Fortran support for metadirectives and dynamic selectors
https://gcc.gnu.org/g:8fbccdb3425e7fc9194d3f02e4a53f3e85cd1a4e commit r15-7291-g8fbccdb3425e7fc9194d3f02e4a53f3e85cd1a4e Author: Sandra Loosemore Date: Thu Jan 30 17:03:06 2025 + OpenMP: Fortran support for metadirectives and dynamic selectors gcc/fortran/ChangeLog PR middle-end/112779 PR middle-end/113904 * decl.cc (gfc_match_end): Handle COMP_OMP_BEGIN_METADIRECTIVE and COMP_OMP_METADIRECTIVE. * dump-parse-tree.cc (show_omp_node): Handle EXEC_OMP_METADIRECTIVE. (show_code_node): Likewise. * gfortran.h (enum gfc_statement): Add ST_OMP_METADIRECTIVE, ST_OMP_BEGIN_METADIRECTIVE, and ST_OMP_END_METADIRECTIVE. (struct gfc_omp_clauses): Rename target_first_st_is_teams to target_first_st_is_teams_or_meta. (struct gfc_omp_variant): New. (gfc_get_omp_variant): New. (struct gfc_st_label): Add omp_region field. (enum gfc_exec_op): Add EXEC_OMP_METADIRECTIVE. (struct gfc_code): Add omp_variants fields. (gfc_free_omp_variants): Declare. (match_omp_directive): Declare. (is_omp_declarative_stmt): Declare. * io.cc (format_asterisk): Adjust initializer. * match.h (gfc_match_omp_begin_metadirective): Declare. (gfc_match_omp_metadirective): Declare. * openmp.cc (gfc_omp_directives): Uncomment metadirective. (gfc_match_omp_eos): Adjust to match context selectors. (gfc_free_omp_variants): New. (gfc_match_omp_clauses): Remove context_selector parameter and adjust to use gfc_match_omp_eos instead. (match_omp): Adjust call to gfc_match_omp_clauses. (gfc_match_omp_context_selector): Add metadirective_p parameter and adjust error-checking. Adjust matching of simd clauses. (gfc_match_omp_context_selector_specification): Adjust parameters so it can be used for metadirective as well as declare variant. (match_omp_metadirective): New. (gfc_match_omp_begin_metadirective): New. (gfc_match_omp_metadirective): New. (resolve_omp_metadirective): New. (resolve_omp_target): Handle metadirectives. (gfc_resolve_omp_directive): Handle EXEC_OMP_METADIRECTIVE. * parse.cc (gfc_matching_omp_context_selector): New. (gfc_in_omp_metadirective_body): New. (gfc_omp_region_count): New. (decode_omp_directive): Handle ST_OMP_BEGIN_METADIRECTIVE and ST_OMP_METADIRECTIVE. (match_omp_directive): New. (case_omp_structured_block): Define. (case_omp_do): Define. (gfc_ascii_statement): Handle ST_OMP_BEGIN_METADIRECTIVE, ST_OMP_END_METADIRECTIVE, and ST_OMP_METADIRECTIVE. (accept_statement): Handle ST_OMP_METADIRECTIVE and ST_OMP_BEGIN_METADIRECTIVE. (gfc_omp_end_stmt): New, split from... (parse_omp_do): ...here, and... (parse_omp_structured_block): ...here. Handle metadirectives, plus "allocate", "atomic", and "dispatch" which were missing. (parse_omp_oacc_atomic): Handle "end metadirective". (parse_openmp_allocate_block): Likewise. (parse_omp_dispatch): Likewise. (parse_omp_metadirective_body): New. (parse_executable): Handle metadirective. Use new case macros defined above. (gfc_parse_file): Initialize metadirective state. (is_omp_declarative_stmt): New. * parse.h (enum gfc_compile_state): Add COMP_OMP_METADIRECTIVE and COMP_OMP_BEGIN_METADIRECTIVE. (gfc_omp_end_stmt): Declare. (gfc_matching_omp_context_selector): Declare. (gfc_in_omp_metadirective_body): Declare. (gfc_omp_metadirective_region_count): Declare. * resolve.cc (gfc_resolve_code): Handle EXEC_OMP_METADIRECTIVE. * st.cc (gfc_free_statement): Likewise. * symbol.cc (compare_st_labels): Handle labels within a metadirective body. (gfc_get_st_label): Likewise. * trans-decl.cc (gfc_get_label_decl): Encode the metadirective region in the label_name. * trans-openmp.cc (gfc_trans_omp_directive): Handle EXEC_OMP_METADIRECTIVE. (gfc_trans_omp_set_selector): New, split/adapted from code (gfc_trans_omp_declare_variant): ...here. (gfc_trans_omp_metadirective): New. * trans-stmt.h (gfc_trans_omp_metadirective): Declare. * trans.cc (trans_code): Handle EXEC_OMP_METADIRECTIVE. gcc/testsuite/ChangeLog PR middle-end/112779 PR middle-end/113904 * gfortran.dg/gomp/metadirective-1.f90: New.
[gcc/devel/omp/gcc-14] OpenMP: Add flag for code elision to omp_context_selector_matches.
https://gcc.gnu.org/g:d17095149a6b935e91dbf5f6ac9c6df8532c8b4e
commit d17095149a6b935e91dbf5f6ac9c6df8532c8b4e
Author: Sandra Loosemore
Date: Sun Feb 9 21:32:35 2025 +
OpenMP: Add flag for code elision to omp_context_selector_matches.
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_matches): Add an optional
bool argument for the code elision case.
* omp-general.h (omp_context_selector_matches): Likewise.
Diff:
---
gcc/omp-general.cc | 28
gcc/omp-general.h | 2 +-
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/gcc/omp-general.cc b/gcc/omp-general.cc
index 249916ac7e32..82a585f932f0 100644
--- a/gcc/omp-general.cc
+++ b/gcc/omp-general.cc
@@ -1717,13 +1717,19 @@ omp_construct_traits_match (tree selector_traits, tree
context_traits,
CONSTRUCT_CONTEXT is known to be complete and not missing constructs
filled in later during compilation.
+ If DECLARE_VARIANT_ELISION_P is true, the function implements the test
+ for elision of preprocessed code in "begin declare variant" constructs,
+ and returns 0 only for failure to match traits in the device and
+ implementation sets.
+
Dynamic properties (which are evaluated at run-time) should always
return 1. */
int
omp_context_selector_matches (tree ctx,
tree construct_context,
- bool complete_p)
+ bool complete_p,
+ bool declare_variant_elision_p)
{
int ret = 1;
bool maybe_offloaded = omp_maybe_offloaded (construct_context);
@@ -1735,9 +1741,12 @@ omp_context_selector_matches (tree ctx,
/* Immediately reject the match if there are any ignored
selectors present. */
- for (tree ts = selectors; ts; ts = TREE_CHAIN (ts))
- if (OMP_TS_CODE (ts) == OMP_TRAIT_INVALID)
- return 0;
+ if (!declare_variant_elision_p
+ || set == OMP_TRAIT_SET_DEVICE
+ || set == OMP_TRAIT_SET_IMPLEMENTATION)
+ for (tree ts = selectors; ts; ts = TREE_CHAIN (ts))
+ if (OMP_TS_CODE (ts) == OMP_TRAIT_INVALID)
+ return 0;
if (set == OMP_TRAIT_SET_CONSTRUCT)
{
@@ -2066,6 +2075,13 @@ omp_context_selector_matches (tree ctx,
break;
case OMP_TRAIT_USER_CONDITION:
gcc_assert (set == OMP_TRAIT_SET_USER);
+ /* The spec does not include the "user" set in the things that
+can trigger code elision in "begin declare variant". */
+ if (declare_variant_elision_p)
+ {
+ ret = -1;
+ break;
+ }
for (tree p = OMP_TS_PROPERTIES (ts); p; p = TREE_CHAIN (p))
if (OMP_TP_NAME (p) == NULL_TREE)
{
@@ -2081,6 +2097,10 @@ omp_context_selector_matches (tree ctx,
ret = -1;
}
break;
+ case OMP_TRAIT_INVALID:
+ /* This is only for the declare_variant_elision_p case. */
+ ret = -1;
+ break;
default:
break;
}
diff --git a/gcc/omp-general.h b/gcc/omp-general.h
index 8cf9f8aaad2f..47918b5c69ca 100644
--- a/gcc/omp-general.h
+++ b/gcc/omp-general.h
@@ -213,7 +213,7 @@ extern bool omp_check_for_duplicate_variant (location_t loc,
tree base_decl, tree ctx);
extern void omp_mark_declare_variant (location_t loc, tree variant,
tree construct);
-extern int omp_context_selector_matches (tree, tree, bool);
+extern int omp_context_selector_matches (tree, tree, bool, bool = false);
extern tree omp_merge_context_selectors (location_t, tree, tree,
enum omp_ctx_directive);
extern tree omp_get_context_selector (tree, enum omp_tss_code,
[gcc/devel/omp/gcc-14] OpenMP: C front end support for "begin declare variant"
https://gcc.gnu.org/g:f715700e7e999d52bb9944776e678c69ad63fb92
commit f715700e7e999d52bb9944776e678c69ad63fb92
Author: Sandra Loosemore
Date: Sun Feb 9 21:32:36 2025 +
OpenMP: C front end support for "begin declare variant"
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_parser_translation_unit): Check for "omp begin declare variant"
with no matching "end".
(c_parser_declaration_or_fndef): Handle functions in "omp begin
declare variant" block.
(c_finish_omp_declare_variant): Merge context selectors with
surrounding "omp begin declare variant".
(JOIN_STR): Define.
(omp_start_variant_function): New.
(omp_finish_variant_function): New.
(c_parser_omp_begin): Handle "omp begin declare variant".
(c_parser_omp_end): Likewise.
Co-Authored-By: Julian Brown
Diff:
---
gcc/c/c-decl.cc | 3 +
gcc/c/c-lang.h| 8 ++
gcc/c/c-parser.cc | 342 --
3 files changed, 317 insertions(+), 36 deletions(-)
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 97e0bd755745..03822c47fbc8 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -162,6 +162,9 @@ vec
*current_omp_declare_target_attribute;
#pragma omp begin assumes ... #pragma omp end assumes regions
we are in. */
vec *current_omp_begin_assumes;
+
+/* Vector of "omp begin/end declare variant" blocks we are in. */
+vec *current_omp_declare_variant_attribute;
/* Each c_binding structure describes one binding of an identifier to
a decl. All the decls in a scope - irrespective of namespace - are
diff --git a/gcc/c/c-lang.h b/gcc/c/c-lang.h
index e51264495fe3..1ca04e1b1064 100644
--- a/gcc/c/c-lang.h
+++ b/gcc/c/c-lang.h
@@ -70,6 +70,11 @@ struct GTY(()) c_omp_begin_assumes_data {
bool attr_syntax;
};
+struct GTY(()) c_omp_declare_variant_attr {
+ bool attr_syntax;
+ tree selector;
+};
+
/* If non-empty, implicit "omp declare target" attribute is added into the
attribute lists. */
extern GTY(()) vec
@@ -78,5 +83,8 @@ extern GTY(()) vec
#pragma omp end assumes (and how many times when nested). */
extern GTY(()) vec
*current_omp_begin_assumes;
+/* And similarly for #pragma omp begin/end declare variant. */
+extern GTY(()) vec
+ *current_omp_declare_variant_attribute;
#endif /* ! GCC_C_LANG_H */
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 4ae1cd500ff3..1ba0f2485e98 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -1441,6 +1441,55 @@ c_parser_skip_to_pragma_eol (c_parser *parser, bool
error_if_not_eol = true)
parser->error = false;
}
+/* Skip tokens up to and including "#pragma omp end declare variant".
+ Properly handle nested "#pragma omp begin declare variant" pragmas. */
+static void
+c_parser_skip_to_pragma_omp_end_declare_variant (c_parser *parser)
+{
+ for (int depth = 0; depth >= 0; )
+{
+ c_token *token = c_parser_peek_token (parser);
+
+ switch (token->type)
+ {
+ case CPP_PRAGMA_EOL:
+ if (!parser->in_pragma)
+ break;
+ /* FALLTHRU */
+ case CPP_EOF:
+ /* If we've run out of tokens, stop. */
+ return;
+
+ case CPP_PRAGMA:
+ if ((token->pragma_kind == PRAGMA_OMP_BEGIN
+ || token->pragma_kind == PRAGMA_OMP_END)
+ && c_parser_peek_nth_token (parser, 2)->type == CPP_NAME
+ && c_parser_peek_nth_token (parser, 3)->type == CPP_NAME)
+ {
+ tree id1 = c_parser_peek_nth_token (parser, 2)->value;
+ tree id2 = c_parser_peek_nth_token (parser, 3)->value;
+ if (strcmp (IDENTIFIER_POINTER (id1), "declare") == 0
+ && strcmp (IDENTIFIER_POINTER (id2), "variant") == 0)
+ {
+ if (token->pragma_kind == PRAGMA_OMP_BEGIN)
+ depth++;
+ else
+ depth--;
+ }
+ }
+ c_parser_consume_pragma (parser);
+ c_parser_skip_to_pragma_eol (parser, false);
+ continue;
+
+ default:
+ break;
+ }
+
+ /* Consume the token. */
+ c_parser_consume_token (parser);
+}
+}
+
/* Skip tokens until we have consumed an entire block, or until we
have consumed a non-nested ';'. */
@@ -1949,6 +1998,13 @@ c_parser_translation_unit (c_parser *parser)
"#pragma omp end declare target");
vec_safe_truncate (current_omp_declare_target_attribute, 0);
}
+ if (vec_safe_length (current_omp_declare_variant_attribute))
+{
+ if (!errorcount)
+ error ("% without corresponding "
+
[gcc/devel/omp/gcc-14] OpenMP: Pass a 3-way flag to omp_check_context_selector instead of a bool.
https://gcc.gnu.org/g:3b7d4cce6bb46e7cdbdd079b25884c7ba4ca09b8
commit 3b7d4cce6bb46e7cdbdd079b25884c7ba4ca09b8
Author: Sandra Loosemore
Date: Sun Feb 9 21:32:35 2025 +
OpenMP: Pass a 3-way flag to omp_check_context_selector instead of a bool.
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): Change
metadirective_p argument to a 3-way flag. Add extra check for
OMP_CTX_BEGIN_DECLARE_VARIANT.
* omp-general.h (enum omp_ctx_directive): New.
(omp_check_context_selector): Adjust declaration.
gcc/c/ChangeLog
* c-parser.cc (c_finish_omp_declare_variant): Update call to
omp_check_context_selector.
(c_parser_omp_metadirective): Likewise.
gcc/cp/ChangeLog
* parser.cc (cp_finish_omp_declare_variant): Update call to
omp_check_context_selector.
(cp_parser_omp_metadirective): Likewise.
gcc/fortran/ChangeLog
* trans-openmp.cc (gfc_trans_omp_declare_variant): Update call to
omp_check_context_selector.
(gfc_trans_omp_metadirective): Likewise.
Diff:
---
gcc/c/c-parser.cc | 6 --
gcc/cp/parser.cc| 6 --
gcc/fortran/trans-openmp.cc | 5 +++--
gcc/omp-general.cc | 19 ---
gcc/omp-general.h | 6 +-
5 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 1d17ec7802d9..4ae1cd500ff3 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -26702,7 +26702,8 @@ c_finish_omp_declare_variant (c_parser *parser, tree
fndecl, tree parms)
ctx = c_parser_omp_context_selector_specification (parser, parms);
if (ctx == error_mark_node)
goto fail;
- ctx = omp_check_context_selector (match_loc, ctx, false);
+ ctx = omp_check_context_selector (match_loc, ctx,
+ OMP_CTX_DECLARE_VARIANT);
if (ctx != error_mark_node && variant != error_mark_node)
{
if (TREE_CODE (variant) != FUNCTION_DECL)
@@ -28956,7 +28957,8 @@ c_parser_omp_metadirective (c_parser *parser, bool
*if_p)
NULL_TREE);
if (ctx == error_mark_node)
goto error;
- ctx = omp_check_context_selector (match_loc, ctx, true);
+ ctx = omp_check_context_selector (match_loc, ctx,
+ OMP_CTX_METADIRECTIVE);
if (ctx == error_mark_node)
goto error;
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 5d28c8986516..36a093a1b0d1 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -50439,7 +50439,8 @@ cp_finish_omp_declare_variant (cp_parser *parser,
cp_token *pragma_tok,
ctx = cp_parser_omp_context_selector_specification (parser, true);
if (ctx == error_mark_node)
goto fail;
- ctx = omp_check_context_selector (match_loc, ctx, false);
+ ctx = omp_check_context_selector (match_loc, ctx,
+ OMP_CTX_DECLARE_VARIANT);
if (ctx != error_mark_node && variant != error_mark_node)
{
tree match_loc_node
@@ -51419,7 +51420,8 @@ cp_parser_omp_metadirective (cp_parser *parser,
cp_token *pragma_tok,
ctx = cp_parser_omp_context_selector_specification (parser, false);
if (ctx == error_mark_node)
goto fail;
- ctx = omp_check_context_selector (match_loc, ctx, true);
+ ctx = omp_check_context_selector (match_loc, ctx,
+ OMP_CTX_METADIRECTIVE);
if (ctx == error_mark_node)
goto fail;
diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index f4a338078ebd..e79794d1859e 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -11320,7 +11320,8 @@ gfc_trans_omp_declare_variant (gfc_namespace *ns)
continue;
}
set_selectors = omp_check_context_selector
- (gfc_get_location (&odv->where), set_selectors, false);
+ (gfc_get_location (&odv->where), set_selectors,
+OMP_CTX_DECLARE_VARIANT);
if (set_selectors != error_mark_node)
{
if (!variant_proc_sym->attr.implicit_type
@@ -11736,7 +11737,7 @@ gfc_trans_omp_metadirective (gfc_code *code)
tree ctx = gfc_trans_omp_set_selector (variant->selectors,
variant->where);
ctx = omp_check_context_selector (gfc_get_location (&variant->where),
- ctx, true);
+
[gcc/devel/omp/gcc-14] OpenMP: C/C++ common testcases for "omp begin declare variant"
https://gcc.gnu.org/g:6fce0314a9a14ec3928110baca58d3aa364e6068
commit 6fce0314a9a14ec3928110baca58d3aa364e6068
Author: Sandra Loosemore
Date: Sun Feb 9 21:32:36 2025 +
OpenMP: C/C++ common testcases for "omp begin declare variant"
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-declare-variant-5.c: New.
* c-c++-common/gomp/delim-declare-variant-6.c: New.
* c-c++-common/gomp/delim-declare-variant-7.c: New.
libgomp/ChangeLog
* testsuite/libgomp.c-c++-common/delim-declare-variant-1.c: New.
Diff:
---
.../c-c++-common/gomp/delim-declare-variant-1.c| 55 +
.../c-c++-common/gomp/delim-declare-variant-2.c| 66
.../c-c++-common/gomp/delim-declare-variant-3.c| 50 +++
.../c-c++-common/gomp/delim-declare-variant-4.c| 31 ++
.../c-c++-common/gomp/delim-declare-variant-5.c| 26
.../c-c++-common/gomp/delim-declare-variant-6.c| 71 ++
.../c-c++-common/gomp/delim-declare-variant-7.c| 27
.../libgomp.c-c++-common/delim-declare-variant-1.c | 45 ++
8 files changed, 371 insertions(+)
diff --git a/gcc/testsuite/c-c++-common/gomp/delim-declare-variant-1.c
b/gcc/testsuite/c-c++-common/gomp/delim-declare-variant-1.c
new file mode 100644
index ..28cac0d65503
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/gomp/delim-declare-variant-1.c
@@ -0,0 +1,55 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-fdump-tree-gimple" } */
+
+/* Check basic functionality for the delimited form of "declare variant"
+ - no error re duplicate definitions
+ - variants are registered and correctly resolved at call site. */
+
+int foo (int a)
+{
+ return a;
+}
+
+int bar (int x)
+{
+ return x;
+}
+
+#pragma omp begin declare variant match (construct={target})
+int foo (int a)
+{
+ return a + 1;
+}
+
+int bar (int x)
+{
+ return x * 2;
+}
+#pragma omp end declare variant
+
+/* Because of the high score value, this variant for "bar" should always be
+ selected even when the one above also matches. */
+#pragma omp begin declare variant match
(implementation={vendor(score(1):"gnu")})
+int bar (int x)
+{
+ return x * 4;
+}
+#pragma omp end declare variant
+
+int main (void)
+{
+ if (foo (42) != 42) __builtin_abort ();
+ if (bar (3) != 12) __builtin_abort ();
+#pragma omp target
+ {
+if (foo (42) != 43) __builtin_abort ();
+if (bar (3) != 12) __builtin_abort ();
+ }
+}
+
+/* { dg-final { scan-tree-dump-times "omp declare variant base
\\(foo.ompvariant." 1 "gimple" } } */
+/* { dg-final { scan-tree-dump-times "omp declare variant base
\\(bar.ompvariant." 2 "gimple" } } */
+/* { dg-final { scan-tree-dump-times "foo \\(42\\)" 1 "gimple" } } */
+/* { dg-final { scan-tree-dump-times "foo\\.ompvariant. \\(42\\)" 1 "gimple" }
} */
+/* { dg-final { scan-tree-dump-times "bar \\(3\\)" 0 "gimple" } } */
+/* { dg-final { scan-tree-dump-times "bar\\.ompvariant. \\(3\\)" 2 "gimple" }
} */
diff --git a/gcc/testsuite/c-c++-common/gomp/delim-declare-variant-2.c
b/gcc/testsuite/c-c++-common/gomp/delim-declare-variant-2.c
new file mode 100644
index ..03bfe2746268
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/gomp/delim-declare-variant-2.c
@@ -0,0 +1,66 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-foffload=disable -fdump-tree-original" } */
+
+/* Check for elision of preprocessed code in a begin/end declare variant
+ construct when it can be determined at parse time that the selector
+ can never match. */
+
+int foobar (int x, int y)
+{
+ return x * y;
+}
+
+int baz (int x)
+{
+ return x;
+}
+
+#pragma omp begin declare variant match (implementation={vendor("acme")}) /* {
dg-warning "unknown property" } */
+int foobar (int x, int y)
+{
+ random junk that would ordinarily cause a parse error;
+ return x + y;
+}
+#pragma omp end declare variant
+
+#pragma omp begin declare variant match (device={kind(fpga)})
+int foobar (int x, int y)
+{
+ random junk that would ordinarily cause a parse error;
+ return x + y;
+}
+#pragma omp end declare variant
+
+/* Per the OpenMP specification, elision only happens when the implementation
+ or device selectors cannot match; the user/condition selector doesn't
+ matter for this. */
+#pragma omp begin declare variant match (user={condition (0)})
+int foobar (int x, int y)
+{
+ return x + y;
+}
+#pragma omp end declare variant
+
+/* Check that we're finding the right "omp end declare variant" when
+ constructs are nested. */
+#pragma omp begin declare variant match (implementation={vendor("acme")}) /*
{ dg-warning "unknown property" } */
+ #pragma omp begin declare variant match
[gcc/devel/omp/gcc-14] OpenMP: C++ front end support for "begin declare variant"
https://gcc.gnu.org/g:42a526c07c35358800a1b6b0a558762569631cd2
commit 42a526c07c35358800a1b6b0a558762569631cd2
Author: Sandra Loosemore
Date: Sun Feb 9 21:32:35 2025 +
OpenMP: C++ front end support for "begin declare variant"
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 base function which also must be
present in that class. Similarly variant functions in a namespace can
only be defined in that namespace using an unqualified name for a base
function already declared in that namespace. Variants for template
functions or inside template classes seem to (mostly) work.
gcc/cp/ChangeLog
* cp-tree.h (struct cp_omp_declare_variant_attr): New.
(struct saved_scope): Add omp_declare_variant_attribute field.
* decl.cc (omp_declare_variant_finalize_one): Add logic to inject
"this" parameter for method calls.
* parser.cc (cp_parser_skip_to_pragma_omp_end_declare_variant): New.
(omp_start_variant_function): New.
(omp_finish_variant_function): New.
(cp_parser_init_declarator): Handle variant functions.
(cp_parser_class_specifier): Handle deferred lookup of base
functions
when the entire class has been seen.
(cp_parser_member_declaration): Handle variant functions.
(cp_finish_omp_declare_variant): Merge context selectors if in
a "begin declare variant" block.
(cp_parser_omp_begin): Match "omp begin declare variant". Adjust
error messages.
(cp_parser_omp_end): Match "omp end declare variant".
* parser.h (struct cp_parser): Add omp_unregistered_variants field.
* semantics.cc (finish_translation_unit): Detect unmatched
"omp begin declare variant".
gcc/testsuite/ChangeLog
* g++.dg/gomp/delim-declare-variant-1.C: New.
* g++.dg/gomp/delim-declare-variant-2.C: New.
* g++.dg/gomp/delim-declare-variant-3.C: New.
* g++.dg/gomp/delim-declare-variant-4.C: New.
* g++.dg/gomp/delim-declare-variant-5.C: New.
* g++.dg/gomp/delim-declare-variant-6.C: New.
* g++.dg/gomp/delim-declare-variant-7.C: New.
* g++.dg/gomp/delim-declare-variant-40.C: New.
* g++.dg/gomp/delim-declare-variant-41.C: New.
* g++.dg/gomp/delim-declare-variant-50.C: New.
* g++.dg/gomp/delim-declare-variant-51.C: New.
* g++.dg/gomp/delim-declare-variant-52.C: New.
* g++.dg/gomp/delim-declare-variant-70.C: New.
* g++.dg/gomp/delim-declare-variant-71.C: New.
libgomp/
* testsuite/libgomp.c++/delim-declare-variant-1.C: New.
* testsuite/libgomp.c++/delim-declare-variant-2.C: New.
* libgomp/testsuite/libgomp.c++/delim-declare-variant-7.C: New.
Co-Authored-By: Julian Brown
Co-Authored-By: waffl3x
Diff:
---
gcc/cp/cp-tree.h | 6 +
gcc/cp/decl.cc | 15 +
gcc/cp/parser.cc | 544 +++--
gcc/cp/parser.h| 5 +
gcc/cp/semantics.cc| 7 +
.../g++.dg/gomp/delim-declare-variant-1.C | 39 ++
.../g++.dg/gomp/delim-declare-variant-2.C | 53 ++
.../g++.dg/gomp/delim-declare-variant-3.C | 37 ++
.../g++.dg/gomp/delim-declare-variant-4.C | 57 +++
.../g++.dg/gomp/delim-declare-variant-40.C | 51 ++
.../g++.dg/gomp/delim-declare-variant-41.C | 31 ++
.../g++.dg/gomp/delim-declare-variant-5.C | 53 ++
.../g++.dg/gomp/delim-declare-variant-50.C | 99
.../g++.dg/gomp/delim-declare-variant-51.C | 181 +++
.../g++.dg/gomp/delim-declare-variant-52.C | 24 +
.../g++.dg/gomp/delim-declare-variant-6.C | 72 +++
.../g++.dg/gomp/delim-declare-variant-7.C | 57 +++
.../g++.dg/gomp/delim-declare-variant-70.C | 206
.../g++.dg/gomp/delim-declare-variant-71.C | 157 ++
.../libgomp.c++/delim-declare-variant-1.C | 29 ++
.../libgomp.c++/delim-declare-variant-2.C | 37 ++
.../libgomp.c++/delim-declare-variant-7.C | 39 ++
22 files changed, 1766 insertions(+), 33 deletions(-)
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 64fc33e0479f..51130be4fe2d 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1865,6 +1865,11 @@ struct GTY(()) cp_omp_begin_assumes_data {
bool attr_syntax;
};
+struct GTY(()) cp_omp_declare_variant_attr {
+ bool attr_syntax;
+
[gcc/devel/omp/gcc-14] OpenMP: Bug fixes for comparing context selectors
https://gcc.gnu.org/g:6369b4937b74ae1e0b351d6531ff25db95f9300c
commit 6369b4937b74ae1e0b351d6531ff25db95f9300c
Author: Sandra Loosemore
Date: Sun Feb 9 21:32:34 2025 +
OpenMP: Bug fixes for comparing context selectors
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.
Diff:
---
gcc/omp-general.cc | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/gcc/omp-general.cc b/gcc/omp-general.cc
index 4713aca1c657..7f9e3eb6bbb4 100644
--- a/gcc/omp-general.cc
+++ b/gcc/omp-general.cc
@@ -2186,8 +2186,26 @@ omp_context_selector_props_compare (enum omp_tss_code
set,
if (set == OMP_TRAIT_SET_USER
&& sel == OMP_TRAIT_USER_CONDITION)
{
- if (integer_zerop (OMP_TP_VALUE (p1))
- != integer_zerop (OMP_TP_VALUE (p2)))
+ /* Recognize constants that have equal truth values,
+otherwise assume all expressions are unique. */
+ tree v1 = OMP_TP_VALUE (p1);
+ tree v2 = OMP_TP_VALUE (p2);
+ if (TREE_CODE (v1) != INTEGER_CST
+ || TREE_CODE (v2) != INTEGER_CST
+ || integer_zerop (v1) != integer_zerop (v2))
+ return 2;
+ break;
+ }
+ if (set == OMP_TRAIT_SET_TARGET_DEVICE
+ && sel == OMP_TRAIT_DEVICE_NUM)
+ {
+ /* Recognize constants that have equal values,
+otherwise assume all expressions are unique. */
+ tree v1 = OMP_TP_VALUE (p1);
+ tree v2 = OMP_TP_VALUE (p2);
+ if (TREE_CODE (v1) != INTEGER_CST
+ || TREE_CODE (v2) != INTEGER_CST
+ || tree_int_cst_compare (v1, v2) != 0)
return 2;
break;
}
@@ -2305,7 +2323,9 @@ omp_context_selector_set_compare (enum omp_tss_code set,
tree ctx1, tree ctx2)
{
tree score1 = OMP_TS_SCORE (ts1);
tree score2 = OMP_TS_SCORE (ts2);
- if (score1 && score2 && !simple_cst_equal (score1, score2))
+ if ((score1 && score2 && !simple_cst_equal (score1, score2))
+ || (score1 && !score2)
+ || (!score1 && score2))
return 2;
int r = omp_context_selector_props_compare (set, OMP_TS_CODE (ts1),
[gcc/devel/omp/gcc-14] OpenMP: Support functions for nested "begin declare variant"
https://gcc.gnu.org/g:76914b6cd6fa19265beec99ba20fa9073b5d20b7
commit 76914b6cd6fa19265beec99ba20fa9073b5d20b7
Author: Sandra Loosemore
Date: Sun Feb 9 21:32:35 2025 +
OpenMP: Support functions for nested "begin declare variant"
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 directly by name or from a different
compilation unit. It also gives no guidance on how dynamic selectors
might be encoded across compilation units.
The GCC implementation of this feature instead treats variant
functions as if they have no linkage and uses a simple counter to
generate names.
gcc/ChangeLog
* omp-general.cc (omp_mangle_variant_name): New.
(omp_check_for_duplicate_variant): New.
(omp_copy_trait_set): New.
(omp_trait_selectors_equivalent): New.
(omp_combine_trait_sets): New.
(omp_merge_context_selectors): New.
* omp-general.h (omp_mangle_variant_name): Declare.
(omp_check_for_duplicate_variant): Declare.
(omp_merge_context_selectors): Declare.
Diff:
---
gcc/omp-general.cc | 195 +
gcc/omp-general.h | 5 ++
2 files changed, 200 insertions(+)
diff --git a/gcc/omp-general.cc b/gcc/omp-general.cc
index 21b3143c0c61..249916ac7e32 100644
--- a/gcc/omp-general.cc
+++ b/gcc/omp-general.cc
@@ -1483,6 +1483,66 @@ omp_check_context_selector (location_t loc, tree ctx,
return ctx;
}
+/* Produce a mangled version of BASE_ID for the name of the variant
+ function with context selector CTX. SEP is a separator string.
+ The return value is an IDENTIFIER_NODE.
+
+ Per the OpenMP spec, "the symbol names of two definitions of a function are
+ considered to be equal if and only if their effective context selectors are
+ equivalent". However, if we did have two such definitions, we'd get an ODR
+ violation. We already take steps in the front ends to make variant
+ functions internal to the compilation unit, since there is no (portable) way
+ to reference them directly by name or declare them as extern in another
+ compilation unit. So, we can diagnose the would-be ODR violations by
+ checking that there is not already a variant for the same function with an
+ equivalent context selector, and otherwise just use a simple counter to name
+ the variant functions instead of any complicated scheme to encode the
+ context selector in the name. */
+
+tree
+omp_mangle_variant_name (tree base_id, tree ctx ATTRIBUTE_UNUSED,
+const char *sep)
+{
+ const char *base_name = IDENTIFIER_POINTER (base_id);
+
+ /* Now do the actual mangling. */
+ static int variant_counter;
+ /* The numeric suffix and terminating byte ought to need way less than
+ 32 bytes extra, that's just a magic number. */
+ size_t buflen = (strlen (base_name) + strlen (sep) + strlen ("ompvariant")
+ + 32);
+ char *buffer = (char *) alloca (buflen);
+ snprintf (buffer, buflen, "%s%sompvariant%d", base_name, sep,
+ ++variant_counter);
+ return get_identifier (buffer);
+}
+
+/* Forward declaration. */
+static int omp_context_selector_compare (tree ctx1, tree ctx2);
+
+/* Diagnose an error if there is already a variant with CTX registered
+ for BASE_DECL. Returns true if OK, false otherwise. */
+bool
+omp_check_for_duplicate_variant (location_t loc, tree base_decl, tree ctx)
+{
+ for (tree attr = DECL_ATTRIBUTES (base_decl); attr; attr = TREE_CHAIN (attr))
+{
+ attr = lookup_attribute ("omp declare variant base", attr);
+ if (attr == NULL_TREE)
+ break;
+
+ tree selector = TREE_VALUE (TREE_VALUE (attr));
+ if (omp_context_selector_compare (ctx, selector) == 0)
+ {
+ error_at (loc,
+ "Multiple definitions of variants with the same "
+ "context selector violate the one-definition rule");
+ return false;
+ }
+}
+ return true;
+}
+
/* Forward declarations. */
static int omp_context_selector_set_compare (enum omp_tss_code, tree, tree);
static int omp_construct_simd_compare (tree, tree, bool);
@@ -4568,3 +4628,138 @@ omp_maybe_apply_loop_xforms (tree *expr_p, tree
for_clauses)
break;
}
}
+
+/* The next group of functions support merging of context selectors for
+ nested "begin declare variant" directives. The spec says:
+
+ ...the effective context selectors of the outer directive are
+ appended to the context selector of the inner directive to form the
+ effective context selector of the inner directive. If a
+ trait-set-selector is present on both directives, the trait-selector
[gcc r15-7477] OpenMP: Bug fixes for comparing context selectors
https://gcc.gnu.org/g:84854ce5b84c86aed23016de5ca05372bc7fa7cf
commit r15-7477-g84854ce5b84c86aed23016de5ca05372bc7fa7cf
Author: Sandra Loosemore
Date: Sun Feb 9 21:34:34 2025 +
OpenMP: Bug fixes for comparing context selectors
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.
Diff:
---
gcc/omp-general.cc | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/gcc/omp-general.cc b/gcc/omp-general.cc
index 2ce79bfc9d83..0d6f02ece31e 100644
--- a/gcc/omp-general.cc
+++ b/gcc/omp-general.cc
@@ -2350,8 +2350,26 @@ omp_context_selector_props_compare (enum omp_tss_code
set,
if (set == OMP_TRAIT_SET_USER
&& sel == OMP_TRAIT_USER_CONDITION)
{
- if (integer_zerop (OMP_TP_VALUE (p1))
- != integer_zerop (OMP_TP_VALUE (p2)))
+ /* Recognize constants that have equal truth values,
+otherwise assume all expressions are unique. */
+ tree v1 = OMP_TP_VALUE (p1);
+ tree v2 = OMP_TP_VALUE (p2);
+ if (TREE_CODE (v1) != INTEGER_CST
+ || TREE_CODE (v2) != INTEGER_CST
+ || integer_zerop (v1) != integer_zerop (v2))
+ return 2;
+ break;
+ }
+ if (set == OMP_TRAIT_SET_TARGET_DEVICE
+ && sel == OMP_TRAIT_DEVICE_NUM)
+ {
+ /* Recognize constants that have equal values,
+otherwise assume all expressions are unique. */
+ tree v1 = OMP_TP_VALUE (p1);
+ tree v2 = OMP_TP_VALUE (p2);
+ if (TREE_CODE (v1) != INTEGER_CST
+ || TREE_CODE (v2) != INTEGER_CST
+ || tree_int_cst_compare (v1, v2) != 0)
return 2;
break;
}
@@ -2469,7 +2487,9 @@ omp_context_selector_set_compare (enum omp_tss_code set,
tree ctx1, tree ctx2)
{
tree score1 = OMP_TS_SCORE (ts1);
tree score2 = OMP_TS_SCORE (ts2);
- if (score1 && score2 && !simple_cst_equal (score1, score2))
+ if ((score1 && score2 && !simple_cst_equal (score1, score2))
+ || (score1 && !score2)
+ || (!score1 && score2))
return 2;
int r = omp_context_selector_props_compare (set, OMP_TS_CODE (ts1),
[gcc r15-7478] OpenMP: Pass a 3-way flag to omp_check_context_selector instead of a bool.
https://gcc.gnu.org/g:9a2116f91150cf872e7d4a66036a81ecd2526b48
commit r15-7478-g9a2116f91150cf872e7d4a66036a81ecd2526b48
Author: Sandra Loosemore
Date: Sun Feb 9 21:34:35 2025 +
OpenMP: Pass a 3-way flag to omp_check_context_selector instead of a bool.
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): Change
metadirective_p argument to a 3-way flag. Add extra check for
OMP_CTX_BEGIN_DECLARE_VARIANT.
* omp-general.h (enum omp_ctx_directive): New.
(omp_check_context_selector): Adjust declaration.
gcc/c/ChangeLog
* c-parser.cc (c_finish_omp_declare_variant): Update call to
omp_check_context_selector.
(c_parser_omp_metadirective): Likewise.
gcc/cp/ChangeLog
* parser.cc (cp_finish_omp_declare_variant): Update call to
omp_check_context_selector.
(cp_parser_omp_metadirective): Likewise.
gcc/fortran/ChangeLog
* trans-openmp.cc (gfc_trans_omp_declare_variant): Update call to
omp_check_context_selector.
(gfc_trans_omp_metadirective): Likewise.
Diff:
---
gcc/c/c-parser.cc | 6 --
gcc/cp/parser.cc| 6 --
gcc/fortran/trans-openmp.cc | 5 +++--
gcc/omp-general.cc | 18 +++---
gcc/omp-general.h | 6 +-
5 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 106a5b48093d..62c6bc031d69 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -26982,7 +26982,8 @@ c_finish_omp_declare_variant (c_parser *parser, tree
fndecl, tree parms)
ctx = c_parser_omp_context_selector_specification (parser, parms);
if (ctx == error_mark_node)
goto fail;
- ctx = omp_check_context_selector (match_loc, ctx, false);
+ ctx = omp_check_context_selector (match_loc, ctx,
+ OMP_CTX_DECLARE_VARIANT);
if (ctx != error_mark_node && variant != error_mark_node)
{
if (TREE_CODE (variant) != FUNCTION_DECL)
@@ -29099,7 +29100,8 @@ c_parser_omp_metadirective (c_parser *parser, bool
*if_p)
NULL_TREE);
if (ctx == error_mark_node)
goto error;
- ctx = omp_check_context_selector (match_loc, ctx, true);
+ ctx = omp_check_context_selector (match_loc, ctx,
+ OMP_CTX_METADIRECTIVE);
if (ctx == error_mark_node)
goto error;
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index bd43f885ebe3..9d0970b4d834 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -50437,7 +50437,8 @@ cp_finish_omp_declare_variant (cp_parser *parser,
cp_token *pragma_tok,
ctx = cp_parser_omp_context_selector_specification (parser, true);
if (ctx == error_mark_node)
goto fail;
- ctx = omp_check_context_selector (match_loc, ctx, false);
+ ctx = omp_check_context_selector (match_loc, ctx,
+ OMP_CTX_DECLARE_VARIANT);
if (ctx != error_mark_node && variant != error_mark_node)
{
tree match_loc_node
@@ -51424,7 +51425,8 @@ cp_parser_omp_metadirective (cp_parser *parser,
cp_token *pragma_tok,
ctx = cp_parser_omp_context_selector_specification (parser, false);
if (ctx == error_mark_node)
goto fail;
- ctx = omp_check_context_selector (match_loc, ctx, true);
+ ctx = omp_check_context_selector (match_loc, ctx,
+ OMP_CTX_METADIRECTIVE);
if (ctx == error_mark_node)
goto fail;
diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index e9103cd3bac3..580d5837bd5f 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -8776,7 +8776,8 @@ gfc_trans_omp_declare_variant (gfc_namespace *ns)
continue;
}
set_selectors = omp_check_context_selector
- (gfc_get_location (&odv->where), set_selectors, false);
+ (gfc_get_location (&odv->where), set_selectors,
+OMP_CTX_DECLARE_VARIANT);
if (set_selectors != error_mark_node)
{
if (!variant_proc_sym->attr.implicit_type
@@ -9082,7 +9083,7 @@ gfc_trans_omp_metadirective (gfc_code *code)
tree ctx = gfc_trans_omp_set_selector (variant->selectors,
variant->where);
ctx = omp_check_context_selector (gfc_get_location (&variant->where),
- ctx, true);
+
[gcc r15-6128] Fix misplaced x86 -mstack-protector-guard-symbol documentation [PR117150]
https://gcc.gnu.org/g:fa878dc8c45fa30aeeaafbe8ab2ff2bae3fbb572
commit r15-6128-gfa878dc8c45fa30aeeaafbe8ab2ff2bae3fbb572
Author: Sandra Loosemore
Date: Thu Dec 12 04:20:37 2024 +
Fix misplaced x86 -mstack-protector-guard-symbol documentation [PR117150]
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 -mstack-protector-guard-symbol from here...
(x86 Options): ...to here.
Diff:
---
gcc/doc/invoke.texi | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3cb9a50b6909..b85084459b12 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -32376,11 +32376,9 @@ The @option{-mno-compat-align-parm} option is the
default.
@opindex mstack-protector-guard
@opindex mstack-protector-guard-reg
@opindex mstack-protector-guard-offset
-@opindex mstack-protector-guard-symbol
@item -mstack-protector-guard=@var{guard}
@itemx -mstack-protector-guard-reg=@var{reg}
@itemx -mstack-protector-guard-offset=@var{offset}
-@itemx -mstack-protector-guard-symbol=@var{symbol}
Generate stack protection code using canary at @var{guard}. Supported
locations are @samp{global} for global canary or @samp{tls} for per-thread
canary in the TLS block (the default with GNU libc version 2.4 or later).
@@ -32390,8 +32388,7 @@ With the latter choice the options
@option{-mstack-protector-guard-offset=@var{offset}} furthermore specify
which register to use as base register for reading the canary, and from what
offset from that base register. The default for those is as specified in the
-relevant ABI. @option{-mstack-protector-guard-symbol=@var{symbol}} overrides
-the offset with a symbol reference to a canary in the TLS block.
+relevant ABI.
@opindex mpcrel
@opindex mno-pcrel
@@ -36216,9 +36213,11 @@ Split 32-byte AVX unaligned load and store.
@opindex mstack-protector-guard
@opindex mstack-protector-guard-reg
@opindex mstack-protector-guard-offset
+@opindex mstack-protector-guard-symbol
@item -mstack-protector-guard=@var{guard}
@itemx -mstack-protector-guard-reg=@var{reg}
@itemx -mstack-protector-guard-offset=@var{offset}
+@itemx -mstack-protector-guard-symbol=@var{symbol}
Generate stack protection code using canary at @var{guard}. Supported
locations are @samp{global} for global canary or @samp{tls} for per-thread
canary in the TLS block (the default). This option has effect only when
@@ -36231,6 +36230,9 @@ which segment register (@code{%fs} or @code{%gs}) to
use as base register
for reading the canary, and from what offset from that base register.
The default for those is as specified in the relevant ABI.
+@option{-mstack-protector-guard-symbol=@var{symbol}} overrides
+the offset with a symbol reference to a canary in the TLS block.
+
@opindex mgeneral-regs-only
@item -mgeneral-regs-only
Generate code that uses only the general-purpose registers. This
[gcc r15-6316] Documentation: Fix paste-o in recent OpenMP/OpenACC patch
https://gcc.gnu.org/g:b34fbab529e64dbeb6db70263e35373c200f899a
commit r15-6316-gb34fbab529e64dbeb6db70263e35373c200f899a
Author: Sandra Loosemore
Date: Wed Dec 18 03:51:54 2024 +
Documentation: Fix paste-o in recent OpenMP/OpenACC patch
gcc/ChangeLog
* doc/extend.texi (OpenACC): Fix paste-o.
Diff:
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 54465ddc23a1..f045159963ed 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -29403,7 +29403,7 @@ GCC strives to be compatible with the
@uref{https://www.openacc.org/, OpenACC Application Programming
Interface v2.6}.
-To enable the processing of OpenACC directives @samp{#pragma omp}
+To enable the processing of OpenACC directives @samp{#pragma acc}
in C and C++, GCC needs to be invoked with the @option{-fopenacc} option.
This option also arranges for automatic linking of the OpenACC runtime
library.
[gcc r15-6310] Documentation: Make OpenMP/OpenACC docs easier to find [PR26154]
https://gcc.gnu.org/g:ef458b3fa75537cb2d16f4ce61bc52642ddefd8a commit r15-6310-gef458b3fa75537cb2d16f4ce61bc52642ddefd8a Author: Sandra Loosemore Date: Tue Dec 17 15:19:36 2024 + Documentation: Make OpenMP/OpenACC docs easier to find [PR26154] 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-edited/adapted that text for similar sections in the GCC manual, as well as breaking out the OpenMP and OpenACC options into their own section (they apply to all of C, C++, and Fortran). I also updated the information about what versions of OpenMP and OpenACC are supported and removed some redundant text from the Fortran manual to prevent it from getting out of sync on future updates, and inserted some cross-references to the new sections elsewhere. gcc/c-family/ChangeLog PR c/26154 * c.opt.urls: Regenerated. gcc/ChangeLog PR c/26154 * common.opt.urls: Regenerated. * doc/extend.texi (C Extensions): Adjust menu for new sections. (Attribute Syntax): Mention OpenMP directives. (Pragmas): Mention OpenMP and OpenACC directives. (OpenMP): New section. (OpenACC): New section. * doc/invoke.texi (Invoking GCC): Adjust menu for new section. (Option Summary): Move OpenMP and OpenACC options to their own category. (C Dialect Options): Move documentation for -foffload, -fopenacc, -fopenacc-dim, -fopenmp, -fopenmd-simd, and -fopenmp-target-simd-clone to... (OpenMP and OpenACC Options): ...this new section. Light copy-editing of the option descriptions. gcc/fortran/ChangeLog: PR c/26154 * gfortran.texi (Standards): Remove redundant info about OpenMP/OpenACC standard support. (OpenMP): Copy-editing and update version info. (OpenACC): Likewise. * lang.opt.urls: Regenerated. Diff: --- gcc/c-family/c.opt.urls | 8 +- gcc/common.opt.urls | 8 +- gcc/doc/extend.texi | 61 gcc/doc/invoke.texi | 240 -- gcc/fortran/gfortran.texi | 52 +- gcc/fortran/lang.opt.urls | 8 +- 6 files changed, 227 insertions(+), 150 deletions(-) diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls index 6c08b0ae052f..421cc08e2c72 100644 --- a/gcc/c-family/c.opt.urls +++ b/gcc/c-family/c.opt.urls @@ -1256,16 +1256,16 @@ fobjc-nilcheck UrlSuffix(gcc/Objective-C-and-Objective-C_002b_002b-Dialect-Options.html#index-fobjc-nilcheck) fopenacc -UrlSuffix(gcc/C-Dialect-Options.html#index-fopenacc) LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-fopenacc) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-fopenacc) LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-fopenacc) fopenacc-dim= -UrlSuffix(gcc/C-Dialect-Options.html#index-fopenacc-dim) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-fopenacc-dim) fopenmp -UrlSuffix(gcc/C-Dialect-Options.html#index-fopenmp) LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-fopenmp) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-fopenmp) LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-fopenmp) fopenmp-simd -UrlSuffix(gcc/C-Dialect-Options.html#index-fopenmp-simd) LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-fopenmp-simd) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-fopenmp-simd) LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-fopenmp-simd) foperator-names UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-fno-operator-names) diff --git a/gcc/common.opt.urls b/gcc/common.opt.urls index 577e00d7a276..79c322bed2b6 100644 --- a/gcc/common.opt.urls +++ b/gcc/common.opt.urls @@ -1005,19 +1005,19 @@ fnon-call-exceptions UrlSuffix(gcc/Code-Gen-Options.html#index-fnon-call-exceptions) foffload= -UrlSuffix(gcc/C-Dialect-Options.html#index-foffload) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-foffload) foffload-options= -UrlSuffix(gcc/C-Dialect-Options.html#index-foffload-options) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-foffload-options) fomit-frame-pointer UrlSuffix(gcc/Optimize-Options.html#index-fomit-frame-pointer) fopenmp-target-simd-clone -UrlSuffix(gcc/C-Dialect-Options.html#index-fopenmp-target-simd-clone) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-fopenmp-target-simd-clone) fopenmp-target-simd-clone= -UrlSuffix(gcc/C-Dialect-Options.html#index-fopenmp-target-simd-clone) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-fopenm
[gcc r15-6180] Clean up documentation of -Wsuggest-attribute= [PR115532]
https://gcc.gnu.org/g:c768cd07f8d96175e66c25f541d3d58569cf6397
commit r15-6180-gc768cd07f8d96175e66c25f541d3d58569cf6397
Author: Sandra Loosemore
Date: Thu Dec 12 19:56:04 2024 +
Clean up documentation of -Wsuggest-attribute= [PR115532]
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 c/115532
* common.opt.urls: Regenerated.
* doc/invoke.texi (Option Summary): Don't try to list all the
-Wsuggest-attribute= variants inline here.
(Warning Options): Likewise. Add @opindex for
Wsuggest-attribute=returns_nonnull and its no- form. Remove
@itemx for no- form.
Co-Authored-By: Peter Eisentraut
Diff:
---
gcc/c-family/c.opt.urls | 3 ---
gcc/common.opt.urls | 6 ++
gcc/doc/invoke.texi | 12 +++-
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls
index 8fbe3bd26989..6c08b0ae052f 100644
--- a/gcc/c-family/c.opt.urls
+++ b/gcc/c-family/c.opt.urls
@@ -864,9 +864,6 @@ UrlSuffix(gcc/Warning-Options.html#index-Wno-system-headers)
Wtemplates
UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Wno-templates)
-Wtautological-compare
-UrlSuffix(gcc/Warning-Options.html#index-Wno-tautological-compare)
-
Wtemplate-body
UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Wno-template-body)
diff --git a/gcc/common.opt.urls b/gcc/common.opt.urls
index 773c021dd942..577e00d7a276 100644
--- a/gcc/common.opt.urls
+++ b/gcc/common.opt.urls
@@ -223,6 +223,9 @@
UrlSuffix(gcc/Warning-Options.html#index-Wno-suggest-attribute_003dnoreturn)
Wsuggest-attribute=malloc
UrlSuffix(gcc/Warning-Options.html#index-Wno-suggest-attribute_003dmalloc)
+Wsuggest-attribute=returns_nonnull
+UrlSuffix(gcc/Warning-Options.html#index-Wno-suggest-attribute_003dreturns_005fnonnull)
+
Wsuggest-final-types
UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Wno-suggest-final-types)
@@ -235,6 +238,9 @@
UrlSuffix(gcc/Warning-Options.html#index-Wno-switch-unreachable)
Wsystem-headers
UrlSuffix(gcc/Warning-Options.html#index-Wno-system-headers)
+Wtautological-compare
+UrlSuffix(gcc/Warning-Options.html#index-Wno-tautological-compare)
+
Wtrampolines
UrlSuffix(gcc/Warning-Options.html#index-Wno-trampolines)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b85084459b12..67a3c8fd91e0 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -416,7 +416,7 @@ Objective-C and Objective-C++ Dialects}.
-Wstring-compare
-Wno-stringop-overflow -Wno-stringop-overread
-Wno-stringop-truncation -Wstrict-flex-arrays
--Wsuggest-attribute=@r{[}pure@r{|}const@r{|}noreturn@r{|}format@r{|}malloc@r{]}
+-Wsuggest-attribute=@var{attribute-name}
-Wswitch -Wno-switch-bool -Wswitch-default -Wswitch-enum
-Wno-switch-outside-range -Wno-switch-unreachable -Wsync-nand
-Wsystem-headers -Wtautological-compare -Wtrailing-whitespace
@@ -8354,9 +8354,9 @@ even without optimization.
@opindex Wsuggest-attribute=
@opindex Wno-suggest-attribute=
-@item
-Wsuggest-attribute=@r{[}pure@r{|}const@r{|}noreturn@r{|}format@r{|}cold@r{|}malloc@r{]}returns_nonnull@r{|}
+@item -Wsuggest-attribute=@var{attribute-name}
Warn for cases where adding an attribute may be beneficial. The
-attributes currently supported are listed below.
+@var{attribute-name}s currently supported are listed below.
@table @gcctabopt
@opindex Wsuggest-attribute=pure
@@ -8369,16 +8369,18 @@ attributes currently supported are listed below.
@opindex Wno-missing-noreturn
@opindex Wsuggest-attribute=malloc
@opindex Wno-suggest-attribute=malloc
+@opindex Wsuggest-attribute=returns_nonnull
+@opindex Wno-suggest-attribute=returns_nonnull
@item -Wsuggest-attribute=pure
@itemx -Wsuggest-attribute=const
@itemx -Wsuggest-attribute=noreturn
@itemx -Wmissing-noreturn
@itemx -Wsuggest-attribute=malloc
@itemx -Wsuggest-attribute=returns_nonnull
-@itemx -Wno-suggest-attribute=returns_nonnull
Warn about functions that might be candidates for attributes
-@code{pure}, @code{const}, @code{noreturn}, @code{malloc} or
@code{returns_nonnull}. The compiler
+@code{pure}, @code{const}, @code{noreturn}, @code{malloc} or
+@code{returns_nonnull}. The compiler
only warns for functions visible in other compilation units or (in the case of
@code{pure} and @code{const}) if it cannot prove that the function returns
normally. A function returns normally if it doesn't contain an infinite loop or
[gcc r15-6181] Regenerate attr-urls.def.
https://gcc.gnu.org/g:4e1d200bb50feff11ffec086539fb77394056ff1
commit r15-6181-g4e1d200bb50feff11ffec086539fb77394056ff1
Author: Sandra Loosemore
Date: Thu Dec 12 20:12:42 2024 +
Regenerate attr-urls.def.
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.
Diff:
---
gcc/attr-urls.def | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/gcc/attr-urls.def b/gcc/attr-urls.def
index f2ebd7b82a5e..e8417cff43c3 100644
--- a/gcc/attr-urls.def
+++ b/gcc/attr-urls.def
@@ -75,6 +75,7 @@ const attr_url_entry function_attrs[] = {
{ "hotpatch",
"gcc/S_002f390-Function-Attributes.html#index-hotpatch-function-attribute_002c-S_002f390",
"S/390", 8},
{ "ifunc",
"gcc/Common-Function-Attributes.html#index-ifunc-function-attribute", "", 5},
{ "indirect_branch",
"gcc/x86-Function-Attributes.html#index-indirect_005fbranch-function-attribute_002c-x86",
"x86", 15},
+ { "indirect_return",
"gcc/AArch64-Function-Attributes.html#index-indirect_005freturn-function-attribute_002c-AArch64",
"AArch64", 15},
{ "indirect_return",
"gcc/x86-Function-Attributes.html#index-indirect_005freturn-function-attribute_002c-x86",
"x86", 15},
{ "interrupt",
"gcc/ARC-Function-Attributes.html#index-interrupt-function-attribute_002c-ARC",
"ARC", 9},
{ "interrupt",
"gcc/ARM-Function-Attributes.html#index-interrupt-function-attribute_002c-ARM",
"ARM", 9},
@@ -171,6 +172,7 @@ const attr_url_entry function_attrs[] = {
{ "nomicromips",
"gcc/MIPS-Function-Attributes.html#index-nomicromips-function-attribute", "",
11},
{ "nomips16",
"gcc/MIPS-Function-Attributes.html#index-nomips16-function-attribute_002c-MIPS",
"MIPS", 8},
{ "nonnull",
"gcc/Common-Function-Attributes.html#index-nonnull-function-attribute", "", 7},
+ { "nonnull_if_nonzero",
"gcc/Common-Function-Attributes.html#index-nonnull_005fif_005fnonzero-function-attribute",
"", 18},
{ "noplt",
"gcc/Common-Function-Attributes.html#index-noplt-function-attribute", "", 5},
{ "noreturn",
"gcc/Common-Function-Attributes.html#index-noreturn-function-attribute", "", 8},
{ "nosave_low_regs",
"gcc/SH-Function-Attributes.html#index-nosave_005flow_005fregs-function-attribute_002c-SH",
"SH", 15},
@@ -221,10 +223,9 @@ const attr_url_entry function_attrs[] = {
{ "tainted_args",
"gcc/Common-Function-Attributes.html#index-tainted_005fargs-function-attribute",
"", 12},
{ "target",
"gcc/ARM-Function-Attributes.html#index-target-function-attribute-1", "", 6},
{ "target",
"gcc/Common-Function-Attributes.html#index-target-function-attribute", "", 6},
- { "target",
"gcc/Nios-II-Function-Attributes.html#index-target-function-attribute-2", "",
6},
- { "target",
"gcc/PowerPC-Function-Attributes.html#index-target-function-attribute-3", "",
6},
- { "target",
"gcc/S_002f390-Function-Attributes.html#index-target-function-attribute-4", "",
6},
- { "target",
"gcc/x86-Function-Attributes.html#index-target-function-attribute-5", "", 6},
+ { "target",
"gcc/PowerPC-Function-Attributes.html#index-target-function-attribute-2", "",
6},
+ { "target",
"gcc/S_002f390-Function-Attributes.html#index-target-function-attribute-3", "",
6},
+ { "target",
"gcc/x86-Function-Attributes.html#index-target-function-attribute-4", "", 6},
{ "target_clones",
"gcc/Common-Function-Attributes.html#index-target_005fclones-function-attribute",
"", 13},
{ "thiscall",
"gcc/x86-Function-Attributes.html#index-thiscall-function-attribute_002c-x86-32",
"x86-32", 8},
{ "tls-dialect=",
"gcc/AArch64-Function-Attributes.html#index-tls-dialect_003d-function-attribute_002c-AArch64",
"AArch64", 12},
[gcc r15-6187] Fix -fstrict-flex-arrays documentation, again [PR111659]
https://gcc.gnu.org/g:d136fa00f0d5faff8397edcd7e4ebb3445ab21b0
commit r15-6187-gd136fa00f0d5faff8397edcd7e4ebb3445ab21b0
Author: Sandra Loosemore
Date: Fri Dec 13 00:26:29 2024 +
Fix -fstrict-flex-arrays documentation, again [PR111659]
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 the strict_flex_array attribute levels.
* doc/invoke.texi (C Dialect Options): Swap documented behavior for
levels 0 and 3. Copy the description for the other levels from the
attribute instead of indirecting to it.
Diff:
---
gcc/doc/extend.texi | 4 ++--
gcc/doc/invoke.texi | 20 +---
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 12fe7bc33455..ebd970155f78 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -8328,11 +8328,11 @@ only when the trailing array is declared as a flexible
array member per C99
standard onwards (@samp{[]}), it is treated as a flexible array member.
There are two more levels in between 0 and 3, which are provided to
-support older codes that use GCC zero-length array extension
+support older code that uses the GCC zero-length array extension
(@samp{[0]}) or one-element array as flexible array members
(@samp{[1]}). When @var{level} is 1, the trailing array is treated as
a flexible array member when it is declared as either @samp{[]},
-@samp{[0]}, or @samp{[1]}; When @var{level} is 2, the trailing array
+@samp{[0]}, or @samp{[1]}. When @var{level} is 2, the trailing array
is treated as a flexible array member when it is declared as either
@samp{[]}, or @samp{[0]}.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 67a3c8fd91e0..0fdf85015857 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2980,16 +2980,22 @@ member for the purpose of accessing the elements of
such an array. The value
of @var{level} controls the level of strictness.
@option{-fstrict-flex-arrays} is equivalent to
-@option{-fstrict-flex-arrays=3}, which is the strictest; all
-trailing arrays of structures are treated as flexible array members.
+@option{-fstrict-flex-arrays=3}, which is the strictest;
+a trailing array is treated as a flexible array member only when
+it is declared as a flexible array member per C99 standard onwards.
The negative form @option{-fno-strict-flex-arrays} is equivalent to
@option{-fstrict-flex-arrays=0}, which is the least strict. In this
-case a trailing array is treated as a flexible array member only when
-it is declared as a flexible array member per C99 standard onwards.
-
-The possible values of @var{level} are the same as for the
-@code{strict_flex_array} attribute (@pxref{Variable Attributes}).
+case all trailing arrays of structures are treated as flexible array members.
+
+There are two more levels in between 0 and 3, which are provided to
+support older code that uses the GCC zero-length array extension
+(@samp{[0]}) or one-element array as flexible array members
+(@samp{[1]}). When @var{level} is 1, the trailing array is treated as
+a flexible array member when it is declared as either @samp{[]},
+@samp{[0]}, or @samp{[1]}. When @var{level} is 2, the trailing array
+is treated as a flexible array member when it is declared as either
+@samp{[]}, or @samp{[0]}.
You can control this behavior for a specific trailing array field of a
structure by using the variable attribute @code{strict_flex_array} attribute
[gcc r15-6402] Fortran: Use the present tense for the manual.
https://gcc.gnu.org/g:703924bf60903f3b3893f526d17aa0592b5cc923
commit r15-6402-g703924bf60903f3b3893f526d17aa0592b5cc923
Author: Sandra Loosemore
Date: Fri Dec 20 05:08:15 2024 +
Fortran: Use the present tense for the manual.
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 compile time).
This set of edits is largely mechanical substitution of phrasing
involving "will". I also fixed a few more markup problems noted while
editing nearby text and fixed a few instances of awkward wording.
gcc/fortran/ChangeLog
* gfortran.texi: Use the present tense throughout; fix some
markup issues and awkward wording.
* invoke.texi: Likewise.
Diff:
---
gcc/fortran/gfortran.texi | 141 +++--
gcc/fortran/invoke.texi | 143 --
2 files changed, 147 insertions(+), 137 deletions(-)
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 77c5e5235f9a..5b27a6dbe300 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -634,7 +634,7 @@ The default value is 0.
This environment variable controls whether all I/O is unbuffered. If
the first letter is @samp{y}, @samp{Y} or @samp{1}, all I/O is
-unbuffered. This will slow down small sequential reads and writes. If
+unbuffered. This slows down small sequential reads and writes. If
the first letter is @samp{n}, @samp{N} or @samp{0}, I/O is buffered.
This is the default.
@@ -644,7 +644,7 @@ This is the default.
The environment variable named @env{GFORTRAN_UNBUFFERED_PRECONNECTED} controls
whether I/O on a preconnected unit (i.e.@: STDOUT or STDERR) is unbuffered. If
the first letter is @samp{y}, @samp{Y} or @samp{1}, I/O is unbuffered. This
-will slow down small sequential reads and writes. If the first letter
+slows down small sequential reads and writes. If the first letter
is @samp{n}, @samp{N} or @samp{0}, I/O is buffered. This is the default.
@node GFORTRAN_SHOW_LOCUS
@@ -674,6 +674,7 @@ be sure to quote spaces, as in
@smallexample
$ GFORTRAN_LIST_SEPARATOR=' , ' ./a.out
@end smallexample
+@noindent
when @command{a.out} is the compiled Fortran program that you want to run.
Default is a single space.
@@ -753,7 +754,7 @@ setting a default data representation for the whole
program. The
@code{CONVERT} specifier overrides the @option{-fconvert} compile options.
Note that the values specified via the @env{GFORTRAN_CONVERT_UNIT}
-environment variable will override the @code{CONVERT} specifier in the
+environment variable override the @code{CONVERT} specifier in the
@code{OPEN} statement. This is to give control over data formats to
users who do not have the source code of their program available.
@@ -889,7 +890,7 @@ See also @ref{Argument passing conventions} and
@ref{Interoperability with C}.
The Fortran standard does not require the compiler to evaluate all parts of an
expression, if they do not contribute to the final result. For logical
expressions with @code{.AND.} or @code{.OR.} operators, in particular, GNU
-Fortran will optimize out function calls (even to impure functions) if the
+Fortran optimizes out function calls (even to impure functions) if the
result of the expression can be established without them. However, since not
all compilers do that, and such an optimization can potentially modify the
program flow and subsequent results, GNU Fortran throws warnings for such
@@ -1018,17 +1019,17 @@ where file metadata is written to the directory lazily.
This means
that, for instance, the @code{dir} command can show a stale size for a
file. One can force a directory metadata update by closing the unit,
or by calling @code{_commit} on the file descriptor. Note, though,
-that @code{_commit} will force all dirty data to stable storage, which
+that @code{_commit} forces all dirty data to stable storage, which
is often a very slow operation.
The Network File System (NFS) implements a relaxed consistency model
called open-to-close consistency. Closing a file forces dirty data and
metadata to be flushed to the server, and opening a file forces the
client to contact the server in order to revalidate cached
-data. @code{fsync} will also force a flush of dirty data and metadata
+data. @code{fsync} also forces a flush of dirty data and metadata
to the server. Similar to @code{open} and @code{close}, acquiring and
-releasing @code{fcntl} file locks, if the server supports them, will
-also force cache validation and flushing dirty data and metadata.
+releasing @code{fcntl} file locks, if the server supports them,
+also forces cache validation and flushing dirty data and m
[gcc r15-6401] Fortran: Fixes for markup, typos, and indexing in manual
https://gcc.gnu.org/g:41ef672247c28f4a30d60e8ce691a6b284e61e59
commit r15-6401-g41ef672247c28f4a30d60e8ce691a6b284e61e59
Author: Sandra Loosemore
Date: Thu Dec 19 23:49:57 2024 +
Fortran: Fixes for markup, typos, and indexing in manual
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 typos and missing @cindex entries.
There shouldn't be any semantic changes to the documentation in this patch.
gcc/fortran/ChangeLog
* gfortran.texi: Fix markup, typos, and indexing throughout the
file.
* invoke.texi: Likewise.
Diff:
---
gcc/fortran/gfortran.texi | 236 ++
gcc/fortran/invoke.texi | 92 ++
2 files changed, 183 insertions(+), 145 deletions(-)
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 8aedf46680d2..77c5e5235f9a 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -237,7 +237,7 @@ The GNU Fortran compiler is the successor to @command{g77},
the
Fortran 77 front end included in GCC prior to version 4 (released in
2005). While it is backward-compatible with most @command{g77}
extensions and command-line options, @command{gfortran} is a completely new
-implemention designed to support more modern dialects of Fortran.
+implementation designed to support more modern dialects of Fortran.
GNU Fortran implements the Fortran 77, 90 and 95 standards
completely, most of the Fortran 2003 and 2008 standards, and some
features from the 2018 standard. It also implements several extensions
@@ -752,9 +752,9 @@ data representation for unformatted files. @xref{Runtime
Options}, for
setting a default data representation for the whole program. The
@code{CONVERT} specifier overrides the @option{-fconvert} compile options.
-@emph{Note that the values specified via the GFORTRAN_CONVERT_UNIT
-environment variable will override the CONVERT specifier in the
-open statement}. This is to give control over data formats to
+Note that the values specified via the @env{GFORTRAN_CONVERT_UNIT}
+environment variable will override the @code{CONVERT} specifier in the
+@code{OPEN} statement. This is to give control over data formats to
users who do not have the source code of their program available.
@node GFORTRAN_ERROR_BACKTRACE
@@ -818,7 +818,7 @@ might in some way or another become visible to the
programmer.
@node KIND Type Parameters
-@section KIND Type Parameters
+@section @code{KIND} Type Parameters
@cindex kind
The @code{KIND} type parameters supported by GNU Fortran for the primitive
@@ -866,7 +866,7 @@ the kind parameters of the @ref{ISO_C_BINDING} module
should be used.
@node Internal representation of LOGICAL variables
-@section Internal representation of LOGICAL variables
+@section Internal representation of @code{LOGICAL} variables
@cindex logical, variable representation
The Fortran standard does not specify how variables of @code{LOGICAL}
@@ -897,7 +897,7 @@ situations with the @option{-Wfunction-elimination} flag.
@node MAX and MIN intrinsics with REAL NaN arguments
-@section MAX and MIN intrinsics with REAL NaN arguments
+@section @code{MAX} and @code{MIN} intrinsics with @code{REAL} NaN arguments
@cindex MAX, MIN, NaN
The Fortran standard does not specify what the result of the
@@ -970,7 +970,7 @@ Fortran programmer can use the intrinsic @code{FNUM} to
retrieve the
low level file descriptor corresponding to an open Fortran unit. Then,
using e.g. the @code{ISO_C_BINDING} feature, one can call the
underlying system call to flush dirty data to stable storage, such as
-@code{fsync} on POSIX, @code{_commit} on MingW, or @code{fcntl(fd,
+@code{fsync} on POSIX, @code{_commit} on MinGW, or @code{fcntl(fd,
F_FULLSYNC, 0)} on macOS. The following example shows how to call
fsync:
@@ -1032,7 +1032,7 @@ also force cache validation and flushing dirty data and
metadata.
@node Files opened without an explicit ACTION= specifier
-@section Files opened without an explicit ACTION= specifier
+@section Files opened without an explicit @code{ACTION=} specifier
@cindex open, action
The Fortran standard says that if an @code{OPEN} statement is executed
@@ -1056,7 +1056,7 @@ symbolic links, on systems that support them.
@itemize
-@item Results of INQUIRE statements of the ``inquire by file'' form will
+@item Results of @code{INQUIRE} statements of the ``inquire by file'' form
relate to the target of the symbolic link. For example,
@code{INQUIRE(FILE="foo",EXIST=ex)} will set @var{ex} to @var{.true.} if
@var{foo} is a symbolic link pointing to an existing file, and @var{.false.}
@@ -1088,11 +1088,11 @@ Each subrecord consists of a leading
[gcc r15-6403] Fortran: Fix hyphenation errors in the manual
https://gcc.gnu.org/g:1ec38e26e2be462c0fb645718714f61fc86a497d
commit r15-6403-g1ec38e26e2be462c0fb645718714f61fc86a497d
Author: Sandra Loosemore
Date: Fri Dec 20 16:27:14 2024 +
Fortran: Fix hyphenation errors in the manual
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.
gcc/fortran/ChangeLog
* gfortran.texi: Get rid of some unnecessary hyphens throughout
the file.
* invoke.texi: Likewise.
Diff:
---
gcc/fortran/gfortran.texi | 58 +++
gcc/fortran/invoke.texi | 24 ++--
2 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 5b27a6dbe300..2838702b64b3 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -163,7 +163,7 @@ the GNU Fortran compiler. You can find in this manual how
to invoke
@ifset DEVELOPMENT
@emph{Warning:} This document, and the compiler it describes, are still
-under development. While efforts are made to keep it up-to-date, it might
+under development. While efforts are made to keep it up to date, it might
not accurately reflect the status of the most recent GNU Fortran compiler.
@end ifset
@@ -1163,7 +1163,7 @@ sytems, such as Linux, it is necessary to specify
@option{-pthread},
Integer overflow is prohibited by the Fortran standard. The behavior
of gfortran on integer overflow is undefined by default. Traditional
code, like linear congruential pseudo-random number generators in old
-programs that rely on specific, non-standard behavior may generate
+programs that rely on specific, nonstandard behavior may generate
unexpected results. The @option{-fsanitize=undefined} option can be
used to detect such code at runtime.
@@ -1606,12 +1606,12 @@ and @code{CHARACTER}.
@cindex conversion, to character
Allowing character literals to be used in a similar way to Hollerith constants
-is a non-standard extension. This feature is enabled using
+is a nonstandard extension. This feature is enabled using
-fdec-char-conversions and only applies to character literals of @code{kind=1}.
Character literals can be used in @code{DATA} statements and assignments with
numeric (@code{INTEGER}, @code{REAL}, or @code{COMPLEX}) or @code{LOGICAL}
-variables. Like Hollerith constants they are copied byte-wise fashion. The
+variables. Like Hollerith constants they are copied bytewise fashion. The
constant is padded with spaces or truncated to fit the size of the
variable in which it is stored.
@@ -1629,7 +1629,7 @@ Examples:
@subsection Cray pointers
@cindex pointer, Cray
-Cray pointers are part of a non-standard extension that provides a
+Cray pointers are part of a nonstandard extension that provides a
C-like pointer in Fortran. This is accomplished through a pair of
variables: an integer ``pointer'' that holds a memory address, and a
``pointee'' that is used to dereference the pointer.
@@ -2126,7 +2126,7 @@ the initializer list.
@cindex @code{MAP}
Unions are an old vendor extension which were commonly used with the
-non-standard @ref{STRUCTURE and RECORD} extensions. Use of @code{UNION} and
+nonstandard @ref{STRUCTURE and RECORD} extensions. Use of @code{UNION} and
@code{MAP} is automatically enabled with @option{-fdec-structure}.
A @code{UNION} declaration occurs within a structure; within the definition of
@@ -2667,7 +2667,7 @@ c
Some Fortran compilers, including @command{g77}, let the user declare
complex functions with the syntax @code{COMPLEX FUNCTION name*16()}, as
-well as @code{COMPLEX*16 FUNCTION name()}. Both are non-standard, legacy
+well as @code{COMPLEX*16 FUNCTION name()}. Both are nonstandard legacy
extensions. @command{gfortran} accepts the latter form, which is more
common, but not the former.
@@ -3838,7 +3838,7 @@ dollar sign (@code{$}) is additionally permitted with the
option
@option{-fdollar-ok}, but not as first character and only if the
target system supports it.
-By default, the procedure name is the lower-cased Fortran name with an
+By default, the procedure name is the lowercased Fortran name with an
appended underscore (@code{_}); using @option{-fno-underscoring} no
underscore is appended while @code{-fsecond-underscore} appends two
underscores. Depending on the target system and the calling convention,
@@ -3848,12 +3848,12 @@ number is appended. For the changing the calling
convention, see
@pxref{GNU Fortran Compiler Directives}.
For common blocks, the same convention is used, i.e. by default an
-underscore is appended to the lower-cased Fortran name. Blank commons
+underscore is appended to the lowercased Fortran name. Blank c
[gcc r15-6400] Fortran: Clean up -funderscoring and -fsecond-underscore docs [PR51820]
https://gcc.gnu.org/g:53ddfbaede0db07843529f41b50133a815a1d90a
commit r15-6400-g53ddfbaede0db07843529f41b50133a815a1d90a
Author: Sandra Loosemore
Date: Thu Dec 19 00:43:11 2024 +
Fortran: Clean up -funderscoring and -fsecond-underscore docs [PR51820]
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
PR fortran/109216
* invoke.texi (Code Gen Options): Further cleanups of the discussion
of what -funderscoring and -fsecond-underscore do.
Diff:
---
gcc/fortran/invoke.texi | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index ff4040732d85..f88a9b8252f7 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1664,6 +1664,8 @@ source file by appending underscores to them.
With @option{-funderscoring} in effect, GNU Fortran appends one
underscore to external names. This is done to ensure
compatibility with code produced by many UNIX Fortran compilers.
+Note this does not apply to names declared with C binding, or within
+a module.
@emph{Caution}: The default behavior of GNU Fortran is
incompatible with @command{f2c} and @command{g77}, please use the
@@ -1678,12 +1680,12 @@ and so on).
For example, with @option{-funderscoring}, and assuming that @code{j()} and
@code{max_count()} are external functions while @code{my_var} and
-@code{lvar} are local variables, a statement like
+@code{lvar} are local variables, a Fortran statement like
@smallexample
I = J() + MAX_COUNT (MY_VAR, LVAR)
@end smallexample
@noindent
-is implemented as something akin to:
+is implemented as something akin to the C code:
@smallexample
i = j_() + max_count_(&my_var, &lvar);
@end smallexample
@@ -1715,11 +1717,10 @@ could make finding unresolved-reference bugs quite
difficult in some
cases---they might occur at program run time, and show up only as
buggy behavior at run time.
-In future versions of GNU Fortran we hope to improve naming and linking
-issues so that debugging always involves using the names as they appear
-in the source, even if the names as seen by the linker are mangled to
-prevent accidental linking between procedures with incompatible
-interfaces.
+@xref{Naming and argument-passing conventions}, for more information.
+Also note that declaring symbols as @code{bind(C)} is a more robust way to
+interface with code written in other languages or compiled with different
+Fortran compilers than the command-line options documented in this section.
@opindex fsecond-underscore
@cindex underscore
@@ -1731,21 +1732,19 @@ interfaces.
@cindex libf2c calling convention
@item -fsecond-underscore
By default, GNU Fortran appends an underscore to external
-names. If this option is used GNU Fortran appends two
-underscores to names with underscores and one underscore to external names
-with no underscores. GNU Fortran also appends two underscores to
-internal names with underscores to avoid naming collisions with external
-names.
+names. If this option is used, GNU Fortran appends two
+underscores to names with underscores and one underscore to names
+with no underscores.
-This option has no effect if @option{-fno-underscoring} is
-in effect. It is implied by the @option{-ff2c} option.
-
-Otherwise, with this option, an external name such as @code{MAX_COUNT}
+For example, an external name such as @code{MAX_COUNT}
is implemented as a reference to the link-time external symbol
@code{max_count__}, instead of @code{max_count_}. This is required
for compatibility with @command{g77} and @command{f2c}, and is implied
by use of the @option{-ff2c} option.
+This option has no effect if @option{-fno-underscoring} is
+in effect. It is implied by the @option{-ff2c} option.
+
@opindex fcoarray
@cindex coarrays
@item -fcoarray=@var{}
[gcc r15-7217] OpenMP: Fix typo in atomic directive error message
https://gcc.gnu.org/g:50fb72d62ccf89a89a09f885014d990770c727d7
commit r15-7217-g50fb72d62ccf89a89a09f885014d990770c727d7
Author: Sandra Loosemore
Date: Sun Jan 26 16:02:54 2025 +
OpenMP: Fix typo in atomic directive error message
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.
Diff:
---
gcc/fortran/openmp.cc| 2 +-
gcc/testsuite/gfortran.dg/gomp/atomic-26.f90 | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index be78aa1ab275..7875341b2cfa 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -10410,7 +10410,7 @@ resolve_omp_atomic (gfc_code *code)
gfc_intrinsic_op alt_op = INTRINSIC_NONE;
if (atomic_code->ext.omp_clauses->fail != OMP_MEMORDER_UNSET)
- gfc_error ("!$OMP ATOMIC UPDATE at %L with FAIL clause requiries either"
+ gfc_error ("!$OMP ATOMIC UPDATE at %L with FAIL clause requires either"
" the COMPARE clause or using the intrinsic MIN/MAX "
"procedure", &atomic_code->loc);
switch (op)
diff --git a/gcc/testsuite/gfortran.dg/gomp/atomic-26.f90
b/gcc/testsuite/gfortran.dg/gomp/atomic-26.f90
index 6448bd9b8bb3..3d88cd72d8dc 100644
--- a/gcc/testsuite/gfortran.dg/gomp/atomic-26.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/atomic-26.f90
@@ -38,11 +38,11 @@ real function bar (y, e, f)
v = d
!$omp atomic fail(relaxed), write! { dg-error "FAIL clause is
incompatible with READ or WRITE" }
d = v
- !$omp atomic fail(relaxed) update! { dg-error "FAIL clause requiries
either the COMPARE clause or using the intrinsic MIN/MAX procedure" }
+ !$omp atomic fail(relaxed) update! { dg-error "FAIL clause requires
either the COMPARE clause or using the intrinsic MIN/MAX procedure" }
d = d + 3.0
- !$omp atomic fail(relaxed) ! { dg-error "FAIL clause requiries either the
COMPARE clause or using the intrinsic MIN/MAX procedure" }
+ !$omp atomic fail(relaxed) ! { dg-error "FAIL clause requires either the
COMPARE clause or using the intrinsic MIN/MAX procedure" }
d = d + 3.0
- !$omp atomic capture fail(relaxed) ! { dg-error "FAIL clause requiries
either the COMPARE clause or using the intrinsic MIN/MAX procedure" }
+ !$omp atomic capture fail(relaxed) ! { dg-error "FAIL clause requires
either the COMPARE clause or using the intrinsic MIN/MAX procedure" }
v = d; d = d + 3.0
!$omp atomic read weak ! { dg-error "WEAK clause requires
COMPARE clause" }
v = d
[gcc r15-6896] OpenMP: Remove dead code from declare variant reimplementation
https://gcc.gnu.org/g:d27db3031848dd20ec274ab04f50163069b840fe commit r15-6896-gd27db3031848dd20ec274ab04f50163069b840fe Author: Sandra Loosemore Date: Thu Dec 26 18:15:57 2024 + OpenMP: Remove dead code from declare variant reimplementation 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_declare_variant_alt. Likewise struct omp_declare_variant_entry, struct omp_declare_variant_base_entry, and the hash tables used to store these structures are no longer needed, since the information needed for late resolution is now stored in the gomp_variant_construct nodes. In addition, some obsolete code that was temporarily ifdef'ed out instead of delted in order to produce a more readable patch for the previous installment of this series is now removed entirely. There are no functional changes in this patch, just removing dead code. gcc/ChangeLog * cgraph.cc (symbol_table::create_edge): Don't set calls_declare_variant_alt in the caller. * cgraph.h (struct cgraph_node): Remove declare_variant_alt and calls_declare_variant_alt flags. * cgraphclones.cc (cgraph_node::create_clone): Don't copy calls_declare_variant_alt bit. * gimplify.cc: Remove previously #ifdef-ed out code. * ipa-free-lang-data.cc (free_lang_data_in_decl): Adjust code referencing declare_variant_alt bit. * ipa.cc (symbol_table::remove_unreachable_nodes): Likewise. * lto-cgraph.cc (lto_output_node): Remove references to deleted bits. (output_refs): Adjust code referencing declare_variant_alt bit. (input_overwrite_node): Remove references to deleted bits. (input_refs): Adjust code referencing declare_variant_alt bit. * lto-streamer-out.cc (lto_output): Likewise. * lto-streamer.h (omp_lto_output_declare_variant_alt): Delete. (omp_lto_input_declare_variant_alt): Delete. * omp-expand.cc (expand_omp_target): Use has_omp_variant_constructs bit to trigger pass_omp_device_lower instead of calls_declare_variant_alt. * omp-general.cc (struct omp_declare_variant_entry): Delete. (struct omp_declare_variant_base_entry): Delete. (struct omp_declare_variant_hasher): Delete. (omp_declare_variant_hasher::hash): Delete. (omp_declare_variant_hasher::equal): Delete. (omp_declare_variants): Delete. (omp_declare_variant_alt_hasher): Delete. (omp_declare_variant_alt_hasher::hash): Delete. (omp_declare_variant_alt_hasher::equal): Delete. (omp_declare_variant_alt): Delete. (omp_lto_output_declare_variant_alt): Delete. (omp_lto_input_declare_variant_alt): Delete. (includes): Delete unnecessary include of gt-omp-general.h. * omp-offload.cc (execute_omp_device_lower): Remove references to deleted bit. (pass_omp_device_lower::gate): Likewise. * omp-simd-clone.cc (simd_clone_create): Likewise. * passes.cc (ipa_write_summaries): Likeise. * symtab.cc (symtab_node::get_partitioning_class): Likewise. * tree-inline.cc (expand_call_inline): Likewise. (tree_function_versioning): Likewise. gcc/lto/ChangeLog * lto-partition.cc (lto_balanced_map): Adjust code referencing deleted declare_variant_alt bit. Diff: --- gcc/cgraph.cc |2 - gcc/cgraph.h | 11 +- gcc/cgraphclones.cc |1 - gcc/gimplify.cc | 149 -- gcc/ipa-free-lang-data.cc |2 +- gcc/ipa.cc|3 - gcc/lto-cgraph.cc | 10 - gcc/lto-streamer-out.cc |3 +- gcc/lto-streamer.h|6 - gcc/lto/lto-partition.cc |5 +- gcc/omp-expand.cc |2 +- gcc/omp-general.cc| 1097 - gcc/omp-offload.cc|8 +- gcc/omp-simd-clone.cc |2 - gcc/passes.cc |3 +- gcc/symtab.cc |2 +- gcc/tree-inline.cc|4 - 17 files changed, 10 insertions(+), 1300 deletions(-) diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc index 48370f5f415e..83a9b59ef302 100644 --- a/gcc/cgraph.cc +++ b/gcc/cgraph.cc @@ -932,8 +932,6 @@ symbol_table::create_edge (cgraph_node *caller, cgraph_node *callee, caller->decl); else edge->in_polymorphic_cdtor = caller->thunk; - if (callee) -caller->calls_declare_variant_alt |= callee->declare_variant_alt;
[gcc r15-6895] OpenMP: Re-work and extend context selector resolution
https://gcc.gnu.org/g:1294b819e1207c0ae76db29a75256f3fafd5f262
commit r15-6895-g1294b819e1207c0ae76db29a75256f3fafd5f262
Author: Sandra Loosemore
Date: Mon Jan 13 20:18:12 2025 +
OpenMP: Re-work and extend context selector resolution
This patch reimplements the middle-end support for "declare variant"
and extends the resolution mechanism to also handle metadirectives
(PR112779). It also adds partial support for dynamic selectors
(PR113904) and fixes a selector scoring bug reported as PR114596. I hope
this rewrite also improves the engineering aspect of the code, e.g. more
comments to explain what it is doing.
In most cases, variant constructs can be resolved either in the front
end or during gimplification; if the variant with the highest score
has a static selector, then only that one is emitted. In the case
where it has a dynamic selector, it is resolved into a (possibly nested)
if/then/else construct, testing the run-time predicate for each selector
sorted by decreasing order of score until a static selector is found.
In some cases, notably a variant construct in a "declare simd"
function which may or may not expand into a simd clone, it may not be
possible to score or sort the variants until later in compilation (the
ompdevlow pass). In this case the gimplifier emits a loop containing
a switch statement with the variants in arbitrary order and uses the
OMP_NEXT_VARIANT tree node as a placeholder to control which variant
is tested on each iteration of the loop. It looks something like:
switch_var = OMP_NEXT_VARIANT (0, state);
loop_label:
switch (switch_var)
{
case 1:
if (dynamic_selector_predicate_1)
{
alternative_1;
goto end_label;
}
else
{
switch_var = OMP_NEXT_VARIANT (1, state);
goto loop_label;
}
case 2:
...
}
end_label:
Note that when there are no dynamic selectors, the loop is unnecessary
and only the switch is emitted.
Finally, in the ompdevlow pass, the OMP_NEXT_VARIANT magic cookies are
resolved and replaced with constants. When compiling with -O we can
expect that the loop and switch will be discarded by subsequent
optimizations and replaced with direct jumps between the cases,
eventually arriving at code with similar control flow to the
early-resolution cases.
This approach is somewhat simpler than the one currently used for
handling declare variant in that all possible code paths are already
included in the output of the gimplifier, so it is not necessary to
maintain hidden references or data structures pointing to expansions of
not-yet-resolved variant constructs and special logic for passing them
through LTO (see PR lto/96680).
A possible disadvantage of this expansion strategy is that dead code
for unused variants in the switch can remain when compiling without
-O. If this turns out to be a critical problem (e.g., an unused case
includes calls to functions not available to the linker) perhaps some
further processing could be performed by default after ompdevlow to
simplify such constructs.
In order to make this patch more readable for review purposes, it
leaves the existing code for "declare variant" resolution (including
the above-mentioned LTO hack) in place, in some cases just ifdef-ing
out functions that won't compile due to changed interfaces for
dependencies. The next patch in the series will delete all the
now-unused code.
gcc/ChangeLog
PR middle-end/114596
PR middle-end/112779
PR middle-end/113904
* Makefile.in (GTFILES): Move omp-general.h earlier; required
because of moving score_wide_int declaration to that file.
* cgraph.h (struct cgraph_node): Add has_omp_variant_constructs
flag.
* cgraphclones.cc (cgraph_node::create_clone): Propagate
has_omp_variant_constructs flag.
* gimplify.cc (omp_resolved_variant_calls): New.
(expand_late_variant_directive): New.
(find_supercontext): New.
(gimplify_variant_call_expr): New.
(gimplify_call_expr): Adjust parameters to make fallback available.
Update processing for "declare variant" substitution.
(is_gimple_stmt): Add OMP_METADIRECTIVE.
(omp_construct_selector_matches): Ifdef out unused function.
(omp_get_construct_context): New.
(gimplify_omp_dispatch): Replace call to deleted function
omp_resolve_declare_variant with equivalent logic.
(expand_omp_metadirective): New.
(expand_late_variant_directive):
[gcc r15-6894] OpenMP: New tree nodes for metadirective and dynamic selector support.
https://gcc.gnu.org/g:210a090e33ec4b51248077b701d432d36ef43fb3
commit r15-6894-g210a090e33ec4b51248077b701d432d36ef43fb3
Author: Sandra Loosemore
Date: Thu Dec 26 18:15:56 2024 +
OpenMP: New tree nodes for metadirective and dynamic selector support.
This patch adds basic support for three new tree node types that will
be used in subsequent patches to support OpenMP metadirectives and
dynamic selectors.
OMP_METADIRECTIVE is the internal representation of parsed OpenMP
metadirective constructs. It's produced by the front ends and is expanded
during gimplification.
OMP_NEXT_VARIANT is used as a "magic cookie" for late resolution of
variant constructs that cannot be fully resolved during
gimplification, used to set the controlling variable of a switch
statement that branches to the next alternative once the candidate
list can be filtered and sorted. These nodes are expanded into
constants in the ompdevlow pass. In some gimple passes, they need to
be treated as constants.
OMP_TARGET_DEVICE_MATCHES is a similar "magic cookie" used to resolve
the target_device dynamic selector. It is wrapped in an OpenMP target
construct, and can be resolved to a constant in the ompdevlow pass.
gcc/ChangeLog:
* doc/generic.texi (OpenMP): Document OMP_METADIRECTIVE,
OMP_NEXT_VARIANT, and OMP_TARGET_DEVICE_MATCHES.
* fold-const.cc (operand_compare::hash_operand): Ignore
the new nodes.
* gimple-expr.cc (is_gimple_val): Allow OMP_NEXT_VARIANT
and OMP_TARGET_DEVICE_MATCHES.
* gimple.cc (get_gimple_rhs_num_ops): OMP_NEXT_VARIANT and
OMP_TARGET_DEVICE_MATCHES are both GIMPLE_SINGLE_RHS.
* tree-cfg.cc (tree_node_can_be_shared): Allow sharing of
OMP_NEXT_VARIANT.
* tree-inline.cc (remap_gimple_op_r): Ignore subtrees of
OMP_NEXT_VARIANT.
* tree-pretty-print.cc (dump_generic_node): Handle
OMP_METADIRECTIVE,
OMP_NEXT_VARIANT, and OMP_TARGET_DEVICE_MATCHES.
* tree-ssa-operands.cc (operands_scanner::get_expr_operands):
Ignore operands of OMP_NEXT_VARIANT and OMP_TARGET_DEVICE_MATCHES.
* tree.def (OMP_METADIRECTIVE): New.
(OMP_NEXT_VARIANT): New.
(OMP_TARGET_DEVICE_MATCHES): New.
* tree.h (OMP_METADIRECTIVE_VARIANTS): New.
(OMP_METADIRECTIVE_VARIANT_SELECTOR): New.
(OMP_METADIRECTIVE_VARIANT_DIRECTIVE): New.
(OMP_METADIRECTIVE_VARIANT_BODY): New.
(OMP_NEXT_VARIANT_INDEX): New.
(OMP_NEXT_VARIANT_STATE): New.
(OMP_TARGET_DEVICE_MATCHES_SELECTOR): New.
(OMP_TARGET_DEVICE_MATCHES_PROPERTIES): New.
Co-Authored-By: Kwok Cheung Yeung
Co-Authored-By: Sandra Loosemore
Diff:
---
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 | 7 +
gcc/tree-pretty-print.cc | 81
gcc/tree-ssa-operands.cc | 4 +++
gcc/tree.def | 34
gcc/tree.h | 22 +
10 files changed, 222 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/generic.texi b/gcc/doc/generic.texi
index 53f172c0c422..d4ac580a7a8b 100644
--- a/gcc/doc/generic.texi
+++ b/gcc/doc/generic.texi
@@ -2341,6 +2341,9 @@ edge. Rethrowing the exception is represented using
@code{RESX_EXPR}.
@tindex OMP_CONTINUE
@tindex OMP_ATOMIC
@tindex OMP_CLAUSE
+@tindex OMP_METADIRECTIVE
+@tindex OMP_NEXT_VARIANT
+@tindex OMP_TARGET_DEVICE_MATCHES
All the statements starting with @code{OMP_} represent directives and
clauses used by the OpenMP API @w{@uref{https://www.openmp.org}}.
@@ -2558,6 +2561,66 @@ same clause @code{C} need to be represented as multiple
@code{C} clauses
chained together. This facilitates adding new clauses during
compilation.
+@item OMP_METADIRECTIVE
+
+Represents @code{#pragma omp metadirective}. This node has one field,
+accessed by the @code{OMP_METADIRECTIVE_VARIANTS (@var{node})} macro.
+
+Metadirective variants are represented internally as @code{TREE_LIST} nodes
+but you should use the interface provided in @file{tree.h} to
+access their components.
+
+@code{OMP_METADIRECTIVE_VARIANT_SELECTOR (@var{variant})}
+is the selector associated with the variant; this is null for the
+@samp{otherwise}/@samp{default} alternative.
+
+@code{OMP_METADIRECTIVE_VARIANT_DIRECTIVE (@var{variant})} is the
+nested directive for the variant.
+
+@code{OMP_METADIRECTIVE_VARIANT_BODY (@var{variant})} represents
+statements following a nested standalone or utility directive.
+In other cases, this field is null and the body is part of the
+nested directive instead.
+
+Metadirectiv
[gcc r15-6511] Fortran: Fix typo in ATAN documentation.
https://gcc.gnu.org/g:9a2f716765f2b7c69973995ae15a71c97401b2af
commit r15-6511-g9a2f716765f2b7c69973995ae15a71c97401b2af
Author: Sandra Loosemore
Date: Fri Jan 3 04:02:44 2025 +
Fortran: Fix typo in ATAN documentation.
gcc/fortran/ChangeLog
* intrinsic.texi (ATAN): Add missing verb.
Diff:
---
gcc/fortran/intrinsic.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index bb6be0c387c8..7c7e4c9372bd 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -1577,7 +1577,7 @@ if @var{Y} is present, @var{X} shall be REAL.
@item @emph{Return value}:
The return value is of the same type and kind as @var{X}.
If @var{Y} is present, the result is identical to @code{ATAN2(Y,X)}.
-Otherwise, it the arctangent of @var{X}, where the real part of
+Otherwise, it is the arctangent of @var{X}, where the real part of
the result is in radians and lies in the range
@math{-\pi/2 \leq \Re \atan(x) \leq \pi/2}.
[gcc r15-6552] OpenMP: Robustify C front end handling of attribute-syntax pragmas
https://gcc.gnu.org/g:c97692d5403cce37a9882ab118a24dca7b202f6c
commit r15-6552-gc97692d5403cce37a9882ab118a24dca7b202f6c
Author: Sandra Loosemore
Date: Fri Jan 3 17:35:03 2025 +
OpenMP: Robustify C front end handling of attribute-syntax pragmas
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 support for metadirectives will change that,
since it also needs to buffer tokens for the metadirective
alternatives, and an attribute-syntax directive can appear inside a
metadirective.
This patch adds a more general save/restore mechanism attached to the
parser via a pointer to a new struct omp_attribute_pragma_state.
gcc/c/ChangeLog
* c-parser.cc (struct c_parser): Change in_omp_attribute_pragma
field to be of type struct omp_attribute_pragma_state.
(struct omp_attribute_pragma_state): New.
(c_parser_skip_until_found): Use the new way to restore state
on EOF.
(c_parser_skip_to_pragma_eol): Likewise.
(c_parser_handle_statement_omp_attributes): Create an
omp_attribute_pragma_state to hold the restore state. Do not
store state in tok.flags.
(omp_maybe_parse_omp_decl): Likewise.
Diff:
---
gcc/c/c-parser.cc | 46 --
1 file changed, 32 insertions(+), 14 deletions(-)
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index f72b0f0e39fd..c46aac5f0a2b 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -262,15 +262,25 @@ struct GTY(()) c_parser {
struct omp_for_parse_data * GTY((skip)) omp_for_parse_state;
/* If we're in the context of OpenMP directives written as C23
- attributes turned into pragma, vector of tokens created from that,
- otherwise NULL. */
- vec *in_omp_attribute_pragma;
+ attributes turned into pragma, the tokens field is temporarily
+ redirected. This holds data needed to restore state afterwards.
+ It's NULL otherwise. */
+ struct omp_attribute_pragma_state *in_omp_attribute_pragma;
/* Set for omp::decl attribute parsing to the decl to which it
appertains. */
tree in_omp_decl_attribute;
};
+/* Holds data needed to restore the token stream to its previous state
+ after parsing an OpenMP attribute-syntax pragma. */
+struct GTY(()) omp_attribute_pragma_state
+{
+ vec *token_vec;
+ c_token * GTY((skip)) save_tokens;
+ unsigned int save_tokens_avail;
+};
+
/* Return a pointer to the Nth token in PARSERs tokens_buf. */
c_token *
@@ -1312,8 +1322,9 @@ c_parser_skip_until_found (c_parser *parser,
c_token *token = c_parser_peek_token (parser);
if (token->type == CPP_EOF)
{
- parser->tokens = &parser->tokens_buf[0];
- parser->tokens_avail = token->flags;
+ parser->tokens = parser->in_omp_attribute_pragma->save_tokens;
+ parser->tokens_avail
+ = parser->in_omp_attribute_pragma->save_tokens_avail;
parser->in_omp_attribute_pragma = NULL;
}
}
@@ -1335,8 +1346,9 @@ c_parser_skip_until_found (c_parser *parser,
c_token *token = c_parser_peek_token (parser);
if (token->type == CPP_EOF)
{
- parser->tokens = &parser->tokens_buf[0];
- parser->tokens_avail = token->flags;
+ parser->tokens = parser->in_omp_attribute_pragma->save_tokens;
+ parser->tokens_avail
+ = parser->in_omp_attribute_pragma->save_tokens_avail;
parser->in_omp_attribute_pragma = NULL;
}
}
@@ -1429,8 +1441,9 @@ c_parser_skip_to_pragma_eol (c_parser *parser, bool
error_if_not_eol = true)
c_token *token = c_parser_peek_token (parser);
if (token->type == CPP_EOF)
{
- parser->tokens = &parser->tokens_buf[0];
- parser->tokens_avail = token->flags;
+ parser->tokens = parser->in_omp_attribute_pragma->save_tokens;
+ parser->tokens_avail
+ = parser->in_omp_attribute_pragma->save_tokens_avail;
parser->in_omp_attribute_pragma = NULL;
}
}
@@ -7184,7 +7197,6 @@ c_parser_handle_statement_omp_attributes (c_parser
*parser, tree &attrs,
return false;
unsigned int tokens_avail = parser->tokens_avail;
- gcc_assert (parser->tokens == &parser->tokens_buf[0]);
tokens++;
vec *toks = NULL;
@@ -7216,12 +7228,15 @@ c_parser_handle_statement_omp_attributes (c_parser
*parser, tree &attrs,
tok.type = CPP_EOF;
tok.keyword = RID_MAX;
tok.location = toks->last ().location;
- tok.flags = tokens_avail;
toks->quick_push (tok);
+ g
[gcc r15-6480] Documentation: Fix Machine-Dependent Options ordering
https://gcc.gnu.org/g:26226ace87f5b68219ffb74724f6ae3438d4d217
commit r15-6480-g26226ace87f5b68219ffb74724f6ae3438d4d217
Author: Sandra Loosemore
Date: Mon Dec 30 19:53:50 2024 +
Documentation: Fix Machine-Dependent Options ordering
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, which also caused Texinfo
diagnostics because the ordering in the menu (which was correctly
alphabetized) didn't match the node order.
I also added a reference to the appropriate section to each entry in
the Option Summary so that you can go directly to the detailed
description for that set of target options. I'm not real happy with
the formatting of the tables in that section but the experiments I
tried all looked worse. :-(
gcc/ChangeLog
* doc/invoke.texi (Option Summary): Put "M32C Options" and
"Cygwin and MinGW Options" in alphabetical order. Add
cross-references.
(Cygwin and MinGW Options): Likewise move the section to its
correct alphabetical location.
* config/lynx.opt.urls: Regenerated.
* config/mingw/cygming.opt.urls: Regenerated.
Diff:
---
gcc/config/lynx.opt.urls | 2 +-
gcc/config/mingw/cygming.opt.urls | 2 +-
gcc/doc/invoke.texi | 335 +++---
3 files changed, 170 insertions(+), 169 deletions(-)
diff --git a/gcc/config/lynx.opt.urls b/gcc/config/lynx.opt.urls
index b547138f7ffa..2b5f44eb6c45 100644
--- a/gcc/config/lynx.opt.urls
+++ b/gcc/config/lynx.opt.urls
@@ -1,5 +1,5 @@
; Autogenerated by regenerate-opt-urls.py from gcc/config/lynx.opt and
generated HTML
mthreads
-UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mthreads)
diff --git a/gcc/config/mingw/cygming.opt.urls
b/gcc/config/mingw/cygming.opt.urls
index af11c4997609..fd5502c246e0 100644
--- a/gcc/config/mingw/cygming.opt.urls
+++ b/gcc/config/mingw/cygming.opt.urls
@@ -10,7 +10,7 @@ mnop-fun-dllimport
UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mnop-fun-dllimport)
mthreads
-UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mthreads)
mwin32
UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mwin32)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 400d192795b0..1572348b1308 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -808,7 +808,7 @@ Objective-C and Objective-C++ Dialects}.
@c Try and put the significant identifier (CPU or system) first,
@c so users have a clue at guessing where the ones they want will be.
-@emph{AArch64 Options}
+@emph{AArch64 Options} (@ref{AArch64 Options})
@gccoptlist{-mabi=@var{name} -mbig-endian -mlittle-endian
-mgeneral-regs-only
-mcmodel=tiny -mcmodel=small -mcmodel=large
@@ -829,7 +829,7 @@ Objective-C and Objective-C++ Dialects}.
-mstack-protector-guard-offset=@var{offset} -mtrack-speculation
-moutline-atomics -mearly-ldp-fusion -mlate-ldp-fusion}
-@emph{Adapteva Epiphany Options}
+@emph{Adapteva Epiphany Options} (@ref{Adapteva Epiphany Options})
@gccoptlist{-mhalf-reg-file -mprefer-short-insn-regs
-mbranch-cost=@var{num} -mcmove -mnops=@var{num} -msoft-cmpsf
-msplit-lohi -mpost-inc -mpost-modify -mstack-offset=@var{num}
@@ -837,10 +837,10 @@ Objective-C and Objective-C++ Dialects}.
-mfp-mode=@var{mode} -mvect-double -max-vect-align=@var{num}
-msplit-vecmove-early -m1reg-@var{reg}}
-@emph{AMD GCN Options}
+@emph{AMD GCN Options} (@ref{AMD GCN Options})
@gccoptlist{-march=@var{gpu} -mtune=@var{gpu} -mstack-size=@var{bytes}}
-@emph{ARC Options}
+@emph{ARC Options} (@ref{ARC Options})
@gccoptlist{-mbarrel-shifter -mjli-always
-mcpu=@var{cpu} -mA6 -mARC600 -mA7 -mARC700
-mdpfp -mdpfp-compact -mdpfp-fast -mno-dpfp-lrsr
@@ -860,7 +860,7 @@ Objective-C and Objective-C++ Dialects}.
-munalign-prob-threshold=@var{probability} -mmpy-option=@var{multo}
-mdiv-rem -mcode-density -mll64 -mfpu=@var{fpu} -mrf16 -mbranch-index}
-@emph{ARM Options}
+@emph{ARM Options} (@ref{ARM Options})
@gccoptlist{-mapcs-frame -mno-apcs-frame
-mabi=@var{name}
-mapcs-stack-check -mno-apcs-stack-check
@@ -903,7 +903,7 @@ Objective-C and Objective-C++ Dialects}.
-mbranch-protection=@var{none}|@var{standard}|@var{pac-ret}[+@var{leaf}]
[+@var{bti}]|@var{bti}[+@var{pac-ret}[+@var{leaf}]]}
-@emph{AVR Options}
+@emph{AVR Options} (@ref{AVR Options})
@gccoptlist{-mmcu=@var{mcu} -mabsdata -maccumulate-args
-mbranch-cost=@var{cost} -mfuse-add=@var{level} -mfuse-move=@var{level}
-mcall-prologues -mgas-isr-prologues -mint8 -mflmap
@@ -914,7 +914,7 @@ Object
[gcc r15-6482] Fortran: Fix that/which usage in the manual.
https://gcc.gnu.org/g:d0542de068e79ee222394a45552577c07b1e6b1b
commit r15-6482-gd0542de068e79ee222394a45552577c07b1e6b1b
Author: Sandra Loosemore
Date: Sat Dec 28 03:51:50 2024 +
Fortran: Fix that/which usage in the manual.
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"; this patch fixes them. In some cases I have
substituted less convoluted wording instead.
gcc/fortran/ChangeLog
* gfortran.texi: Clean up that/which usage throughout the file.
* intrinsic.texi: Likewise.
* invoke.texi: Likewise.
Diff:
---
gcc/fortran/gfortran.texi | 66 +++---
gcc/fortran/intrinsic.texi | 32 +++---
gcc/fortran/invoke.texi| 38 +-
3 files changed, 68 insertions(+), 68 deletions(-)
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 47b89ea726c7..eb17aff7e381 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -705,7 +705,7 @@ the modes are the same as for the @code{CONVERT} specifier:
for unformatted files.
@item @code{BIG_ENDIAN} Use the big-endian format for unformatted files.
@end itemize
-For POWER systems which support @option{-mabi=ieeelongdouble},
+For POWER systems that support @option{-mabi=ieeelongdouble},
there are additional options, which can be combined with the
others with commas. Those are
@itemize @w{}
@@ -800,7 +800,7 @@ The default value is 131072.
@chapter Compiler Characteristics
This chapter describes certain characteristics of the GNU Fortran
-compiler, that are not specified by the Fortran standard, but which
+compiler that are not specified by the Fortran standard, but which
might in some way or another become visible to the programmer.
@menu
@@ -1140,7 +1140,7 @@ end program main
Asynchronous I/O is supported if the program is linked against the
POSIX thread library. If that is not the case, all I/O is performed
-as synchronous. On systems which do not support pthread condition
+as synchronous. On systems that do not support pthread condition
variables, such as AIX, I/O is also performed as synchronous.
On some systems, such as Darwin or Solaris, the POSIX thread library
@@ -1305,7 +1305,7 @@ are:
DATA i/1/, j/2/, x/3*0.,1./
@end smallexample
-Note that variables which are explicitly initialized in declarations
+Note that variables that are explicitly initialized in declarations
or in @code{DATA} statements automatically acquire the @code{SAVE}
attribute.
@@ -1776,7 +1776,7 @@ for unformatted files.
@item @code{CONVERT='BIG_ENDIAN'} Use the big-endian representation for
unformatted files.
@end itemize
-On POWER systems which support @option{-mabi=ieeelongdouble},
+On POWER systems that support @option{-mabi=ieeelongdouble},
there are additional options, which can be combined with the others
with commas. Those are
@itemize @w{}
@@ -2049,7 +2049,7 @@ rules and exceptions:
Otherwise they may contain no specifiers.
@item Structures may contain a special field with the name @code{%FILL}.
-This creates an anonymous component which cannot be accessed but occupies
+This creates an anonymous component that cannot be accessed but occupies
space just as if a component of the same type was declared in its place, useful
for alignment purposes. As an example, the following structure consists
of at least sixteen bytes:
@@ -2622,7 +2622,7 @@ c ... Code that sets A, B and C
@subsection Variable @code{FORMAT} expressions
@cindex @code{FORMAT}
-A variable @code{FORMAT} expression is format statement which includes
+A variable @code{FORMAT} expression is format statement that includes
angle brackets enclosing a Fortran expression: @code{FORMAT(I)}. GNU
Fortran does not support this legacy extension. The effect of variable
format expressions can be reproduced by using the more powerful (and
@@ -2719,7 +2719,7 @@ reading from the position marked previously.
@section Experimental features future Fortran versions
@cindex Future Fortran versions
-GNU Fortran supports some experimental features which have been
+GNU Fortran supports some experimental features that have been
proposed and accepted by the J3 standards committee. These
exist to give users a chance to try them out, and to provide
a reference implementation.
@@ -2784,7 +2784,7 @@ as index variables in @code{DO} loops and as array
indices.
Unsigned numbers can be read and written using list-directed,
formatted and unformatted I/O. For formatted I/O, the @samp{B},
@samp{I}, @samp{O} and @samp{Z} descriptors are valid. Negative
-values and values which would overflow are rejected with
+values and values that would overflow are r
[gcc r15-6961] OpenMP: Add C support for metadirectives and dynamic selectors.
https://gcc.gnu.org/g:4e20914d3306d8898ce586313a40fb92ef0b8964
commit r15-6961-g4e20914d3306d8898ce586313a40fb92ef0b8964
Author: Sandra Loosemore
Date: Tue Jan 14 23:27:53 2025 +
OpenMP: Add C support for metadirectives and dynamic selectors.
Additional shared C/C++ testcases are included in a subsequent patch in this
series.
gcc/c-family/ChangeLog
PR middle-end/112779
PR middle-end/113904
* c-common.h (enum c_omp_directive_kind): Add C_OMP_DIR_META.
(c_omp_expand_variant_construct): Declare.
* c-gimplify.cc: Include omp-general.h.
(genericize_omp_metadirective_stmt): New.
(c_genericize_control_stmt): Add case for OMP_METADIRECTIVE.
* c-omp.cc (c_omp_directives): Fix entries for metadirective.
(c_omp_expand_variant_construct_r): New.
(c_omp_expand_variant_construct): New.
* c-pragma.cc (omp_pragmas): Add metadirective.
* c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_METADIRECTIVE.
gcc/c/ChangeLog
PR middle-end/112779
PR middle-end/113904
* c-parser.cc (struct c_parser): Add omp_metadirective_state field.
(c_parser_skip_to_end_of_block_or_statement): Add metadirective_p
parameter and handle skipping over the parentheses in a "for"
statement.
(struct omp_metadirective_parse_data): New.
(mangle_metadirective_region_label): New.
(c_parser_label): Mangle label names in a metadirective body.
(c_parser_statement_after_labels): Likewise.
(c_parser_pragma): Handle PRAGMA_OMP_METADIRECTIVE.
(c_parser_omp_context_selector): Allow arbitrary expressions in
device_num and condition properties.
(c_parser_omp_assumption_clauses): Handle C_OMP_DIR_META.
(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
Diff:
---
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/c-family/c-pragma.h| 1 +
gcc/c/c-parser.cc | 489 -
.../c-c++-common/gomp/declare-variant-2.c | 6 +-
gcc/testsuite/gcc.dg/gomp/metadirective-1.c| 15 +
8 files changed, 585 insertions(+), 18 deletions(-)
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index efd942c482bd..94b1d2d2b496 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1413,7 +1413,8 @@ enum c_omp_directive_kind {
C_OMP_DIR_CONSTRUCT,
C_OMP_DIR_DECLARATIVE,
C_OMP_DIR_UTILITY,
- C_OMP_DIR_INFORMATIONAL
+ C_OMP_DIR_INFORMATIONAL,
+ C_OMP_DIR_META
};
struct c_omp_directive {
@@ -1427,6 +1428,7 @@ extern const struct c_omp_directive c_omp_directives[];
extern const struct c_omp_directive *c_omp_categorize_directive (const char *,
const char *,
const char *);
+extern tree c_omp_expand_variant_construct (vec &);
/* Return next tree in the chain for chain_next walking of tree nodes. */
inline tree
diff --git a/gcc/c-family/c-gimplify.cc b/gcc/c-family/c-gimplify.cc
index 89a1f5c1e80b..8f6b4335b176 100644
--- a/gcc/c-family/c-gimplify.cc
+++ b/gcc/c-family/c-gimplify.cc
@@ -43,6 +43,7 @@ along with GCC; see the file COPYING3. If not see
#include "context.h"
#include "tree-pass.h"
#include "internal-fn.h"
+#include "omp-general.h"
/* The gimplification pass converts the language-dependent trees
(ld-trees) emitted by the parser into language-independent trees
@@ -543,6 +544,27 @@ genericize_omp_for_stmt (tree *stmt_p, int *walk_subtrees,
void *data,
finish_bc_block (&OMP_FOR_BODY (stmt), bc_continue, clab);
}
+/* Genericize a OMP_METADIRECTIVE node *STMT_P. */
+
+static void
+genericize_omp_metadirective_stmt (tree *stmt_p, int *walk_subtrees,
+ void *data, walk_tree_fn func,
+ walk_tree_lh lh)
+{
+ tree stmt = *stmt_p;
+
+ for (tree variant = OMP_METADIRECTIVE_VARIANTS (stmt);
+ variant != NULL_TREE;
+ variant = TREE_CHAIN (variant))
+{
+ walk_tree_1 (&OMP_METADIRECTIVE_VARIANT_DIRECTIVE (variant),
+ func, data, NULL, lh);
+ walk_tree_1 (&OMP_METADIRECTIVE_VARIANT_BODY (variant),
+ func, data, NULL, lh);
+}
+
+ *wal
[gcc r15-6963] OpenMP: Shared metadirective/dynamic selector tests for C and C++
https://gcc.gnu.org/g:fdeceba59bee60040fd58203b6fe0239d789eade
commit r15-6963-gfdeceba59bee60040fd58203b6fe0239d789eade
Author: Sandra Loosemore
Date: Wed Jan 8 01:55:47 2025 +
OpenMP: Shared metadirective/dynamic selector tests for C and C++
gcc/testsuite/ChangeLog
* c-c++-common/gomp/adjust-args-6.c: New.
* c-c++-common/gomp/attrs-metadirective-1.c: New.
* c-c++-common/gomp/attrs-metadirective-2.c: New.
* c-c++-common/gomp/attrs-metadirective-3.c: New.
* c-c++-common/gomp/attrs-metadirective-4.c: New.
* c-c++-common/gomp/attrs-metadirective-5.c: New.
* c-c++-common/gomp/attrs-metadirective-6.c: New.
* c-c++-common/gomp/attrs-metadirective-7.c: New.
* c-c++-common/gomp/attrs-metadirective-8.c: New.
* c-c++-common/gomp/declare-variant-arg-exprs.c: New.
* c-c++-common/gomp/declare-variant-dynamic-1.c: New.
* c-c++-common/gomp/declare-variant-dynamic-2.c: New.
* c-c++-common/gomp/metadirective-1.c: New.
* c-c++-common/gomp/metadirective-2.c: New.
* c-c++-common/gomp/metadirective-3.c: New.
* c-c++-common/gomp/metadirective-4.c: New.
* c-c++-common/gomp/metadirective-5.c: New.
* c-c++-common/gomp/metadirective-6.c: New.
* c-c++-common/gomp/metadirective-7.c: New.
* c-c++-common/gomp/metadirective-8.c: New.
* c-c++-common/gomp/metadirective-construct.c: New.
* c-c++-common/gomp/metadirective-device.c: New.
* c-c++-common/gomp/metadirective-no-score.c: New.
* c-c++-common/gomp/metadirective-target-device-1.c: New.
* c-c++-common/gomp/metadirective-target-device-2.c: New.
libgomp/ChangeLog
* testsuite/libgomp.c-c++-common/metadirective-1.c: New.
* testsuite/libgomp.c-c++-common/metadirective-2.c: New.
* testsuite/libgomp.c-c++-common/metadirective-3.c: New.
* testsuite/libgomp.c-c++-common/metadirective-4.c: New.
* testsuite/libgomp.c-c++-common/metadirective-5.c: New.
* testsuite/libgomp.c-c++-common/metadirective-late-1.c: 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
Diff:
---
gcc/testsuite/c-c++-common/gomp/adjust-args-6.c| 26 +++
.../c-c++-common/gomp/attrs-metadirective-1.c | 47 ++
.../c-c++-common/gomp/attrs-metadirective-2.c | 76 +
.../c-c++-common/gomp/attrs-metadirective-3.c | 24 +++
.../c-c++-common/gomp/attrs-metadirective-4.c | 41 +
.../c-c++-common/gomp/attrs-metadirective-5.c | 26 +++
.../c-c++-common/gomp/attrs-metadirective-6.c | 33
.../c-c++-common/gomp/attrs-metadirective-7.c | 42 +
.../c-c++-common/gomp/attrs-metadirective-8.c | 18 +++
.../c-c++-common/gomp/declare-variant-arg-exprs.c | 29
.../c-c++-common/gomp/declare-variant-dynamic-1.c | 26 +++
.../c-c++-common/gomp/declare-variant-dynamic-2.c | 30
gcc/testsuite/c-c++-common/gomp/metadirective-1.c | 58 +++
gcc/testsuite/c-c++-common/gomp/metadirective-2.c | 75 +
gcc/testsuite/c-c++-common/gomp/metadirective-3.c | 23 +++
gcc/testsuite/c-c++-common/gomp/metadirective-4.c | 40 +
gcc/testsuite/c-c++-common/gomp/metadirective-5.c | 25 +++
gcc/testsuite/c-c++-common/gomp/metadirective-6.c | 32
gcc/testsuite/c-c++-common/gomp/metadirective-7.c | 41 +
gcc/testsuite/c-c++-common/gomp/metadirective-8.c | 17 ++
.../c-c++-common/gomp/metadirective-construct.c| 178 +
.../c-c++-common/gomp/metadirective-device.c | 149 +
.../c-c++-common/gomp/metadirective-no-score.c | 95 +++
.../gomp/metadirective-target-device-1.c | 151 +
.../gomp/metadirective-target-device-2.c | 132 +++
.../libgomp.c-c++-common/metadirective-1.c | 37 +
.../libgomp.c-c++-common/metadirective-2.c | 41 +
.../libgomp.c-c++-common/metadirective-3.c | 36 +
.../libgomp.c-c++-common/metadirective-4.c | 54 +++
.../libgomp.c-c++-common/metadirective-5.c | 48 ++
.../libgomp.c-c++-common/metadirective-late-1.c| 66
.../libgomp.c-c++-common/metadirective-late-2.c| 66
.../metadirective-target-device.c | 76 +
33 files changed, 1858 insertions(+)
diff --git a/gcc/testsuite/c-c++-common/gomp/adjust-args-6.c
b/gcc/testsuite/c-c++-common/gomp/adjust-args-6.c
new file mode 100644
index ..1d5fc4d7ee39
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/gomp/adjust-args-6.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* {
[gcc r15-6964] OpenMP: Update "declare target"/OpenMP context interaction
https://gcc.gnu.org/g:3c8df3693c40c7a29dde3915b66d29fad7134868
commit r15-6964-g3c8df3693c40c7a29dde3915b66d29fad7134868
Author: Sandra Loosemore
Date: Thu Dec 26 18:16:00 2024 +
OpenMP: Update "declare target"/OpenMP context interaction
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 beginning of
the set..."
In OpenMP 5.2 and TR12, it says:
"For procedures that are determined to be target function variants
by a declare target directive..."
The definition of "device routine" in OpenMP 5.1 is confusing, but
certainly the intent of the later versions of the spec is clear that
it doesn't just apply to functions within a begin declare target/end
declare target block.
The only use of the "omp declare target block" function attribute was
to support the 5.0 language, so it can be removed. This patch changes
the context augmentation to use the "omp declare target" attribute
instead.
gcc/c-family/ChangeLog
* c-attribs.cc (c_common_gnu_attributes): Delete "omp declare
target block".
gcc/c/ChangeLog
* c-decl.cc (c_decl_attributes): Don't add "omp declare target
block".
gcc/cp/ChangeLog
* decl2.cc (cplus_decl_attributes): Don't add "omp declare target
block".
gcc/ChangeLog
* omp-general.cc (omp_complete_construct_context): Check
"omp declare target" attribute, not "omp declare target block".
gcc/testsuite/ChangeLog
* c-c++-common/gomp/declare-target-indirect-2.c : Adjust
expected output for removal of "omp declare target block".
* c-c++-common/gomp/declare-variant-8.c: Likewise, the variant
call to f20 is now resolved differently.
* c-c++-common/gomp/reverse-offload-1.c: Adjust expected output.
* gfortran.dg/gomp/declare-variant-8.f90: Likewise, both f18
and f20 now resolve to the variant. Delete obsolete comments.
Diff:
---
gcc/c-family/c-attribs.cc | 2 --
gcc/c/c-decl.cc | 8 ++--
gcc/cp/decl2.cc | 9 ++---
gcc/omp-general.cc | 2 +-
gcc/testsuite/c-c++-common/gomp/declare-target-indirect-2.c | 10 +-
gcc/testsuite/c-c++-common/gomp/declare-variant-8.c | 4 ++--
gcc/testsuite/c-c++-common/gomp/reverse-offload-1.c | 2 +-
gcc/testsuite/gfortran.dg/gomp/declare-variant-8.f90| 12 ++--
8 files changed, 15 insertions(+), 34 deletions(-)
diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index eb76430dd07a..f3181e7b57c4 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -592,8 +592,6 @@ const struct attribute_spec c_common_gnu_attributes[] =
handle_omp_declare_target_attribute, NULL },
{ "omp declare target nohost", 0, 0, true, false, false, false,
handle_omp_declare_target_attribute, NULL },
- { "omp declare target block", 0, 0, true, false, false, false,
- handle_omp_declare_target_attribute, NULL },
{ "non overlapping", 0, 0, true, false, false, false,
handle_non_overlapping_attribute, NULL },
{ "alloc_align", 1, 1, false, true, true, false,
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 56d13884182d..314b118b7c8b 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -5476,12 +5476,8 @@ c_decl_attributes (tree *node, tree attributes, int
flags)
attributes = tree_cons (get_identifier ("omp declare target implicit"),
NULL_TREE, attributes);
else
- {
- attributes = tree_cons (get_identifier ("omp declare target"),
- NULL_TREE, attributes);
- attributes = tree_cons (get_identifier ("omp declare target block"),
- NULL_TREE, attributes);
- }
+ attributes = tree_cons (get_identifier ("omp declare target"),
+ NULL_TREE, attributes);
if (TREE_CODE (*node) == FUNCTION_DECL)
{
int device_type
diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index 869701bceeed..f64aa848b94a 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -1786,13 +1786,8 @@ cplus_decl_attributes (tree *decl, tree attributes, int
flags)
= tree_cons (get_identifier ("omp declare target implicit"),
NULL_TREE, attributes);
else
-
[gcc r15-6966] OpenMP: Improve error message for invalid directive in "assumes".
https://gcc.gnu.org/g:7f8bb6498691cace5cced224bfc72d13724c9b82 commit r15-6966-g7f8bb6498691cace5cced224bfc72d13724c9b82 Author: Sandra Loosemore Date: Wed Jan 15 17:22:53 2025 + OpenMP: Improve error message for invalid directive in "assumes". gcc/c/ChangeLog * c-parser.cc (c_parser_omp_assumption_clauses): Give a more specific error message for invalid directives vs unknown names. gcc/cp/ChangeLog * parser.cc (cp_parser_omp_assumption_clauses): Give a more specific error message for invalid directives vs unknown names. gcc/fortran/ChangeLog * openmp.cc (gfc_omp_absent_contains_clause): Use an Oxford comma in the message. gcc/testsuite/ChangeLog * c-c++-common/gomp/assume-2.c: Adjust expected diagnostics. * c-c++-common/gomp/assumes-2.c: Likewise. * c-c++-common/gomp/begin-assumes-2.c: Likewise. * gfortran.dg/gomp/allocate-6.f90: Likewise. * gfortran.dg/gomp/assumes-2.f90: Likewise. Diff: --- gcc/c/c-parser.cc | 19 --- gcc/cp/parser.cc | 13 + gcc/fortran/openmp.cc | 2 +- gcc/testsuite/c-c++-common/gomp/assume-2.c| 10 +- gcc/testsuite/c-c++-common/gomp/assumes-2.c | 10 +- gcc/testsuite/c-c++-common/gomp/begin-assumes-2.c | 10 +- gcc/testsuite/gfortran.dg/gomp/allocate-6.f90 | 4 ++-- gcc/testsuite/gfortran.dg/gomp/assumes-2.f90 | 2 +- 8 files changed, 40 insertions(+), 30 deletions(-) diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc index b45c7ef961f4..f193329099f5 100644 --- a/gcc/c/c-parser.cc +++ b/gcc/c/c-parser.cc @@ -28846,13 +28846,18 @@ c_parser_omp_assumption_clauses (c_parser *parser, bool is_assume) = c_omp_categorize_directive (directive[0], directive[1], directive[2]); - if (dir == NULL - || dir->kind == C_OMP_DIR_DECLARATIVE - || dir->kind == C_OMP_DIR_INFORMATIONAL - || dir->kind == C_OMP_DIR_META - || dir->id == PRAGMA_OMP_END - || (!dir->second && directive[1]) - || (!dir->third && directive[2])) + if (dir + && (dir->kind == C_OMP_DIR_DECLARATIVE + || dir->kind == C_OMP_DIR_INFORMATIONAL + || dir->kind == C_OMP_DIR_META)) + error_at (dloc, "invalid OpenMP directive name in " + "%qs clause argument: declarative, " + "informational, and meta directives " + "not permitted", p); + else if (dir == NULL + || dir->id == PRAGMA_OMP_END + || (!dir->second && directive[1]) + || (!dir->third && directive[2])) error_at (dloc, "unknown OpenMP directive name in " "%qs clause argument", p); else diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc index 74f4f7cd6d89..ba2c4dbb0538 100644 --- a/gcc/cp/parser.cc +++ b/gcc/cp/parser.cc @@ -49887,10 +49887,15 @@ cp_parser_omp_assumption_clauses (cp_parser *parser, cp_token *pragma_tok, = c_omp_categorize_directive (directive[0], directive[1], directive[2]); - if (dir == NULL - || dir->kind == C_OMP_DIR_DECLARATIVE - || dir->kind == C_OMP_DIR_INFORMATIONAL - || dir->kind == C_OMP_DIR_META + if (dir + && (dir->kind == C_OMP_DIR_DECLARATIVE + || dir->kind == C_OMP_DIR_INFORMATIONAL + || dir->kind == C_OMP_DIR_META)) + error_at (dloc, "invalid OpenMP directive name in " + "%qs clause argument: declarative, " + "informational, and meta directives " + "not permitted", p); + else if (dir == NULL || dir->id == PRAGMA_OMP_END || (!dir->second && directive[1]) || (!dir->third && directive[2])) diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc index 0f1aaa021812..e51ff1f4d29e 100644 --- a/gcc/fortran/openmp.cc +++ b/gcc/fortran/openmp.cc @@ -1620,
[gcc r15-6962] OpenMP: C++ support for metadirectives and dynamic selectors.
https://gcc.gnu.org/g:677e452e55e5a91e699d4f01cc9b88297cc41a0d
commit r15-6962-g677e452e55e5a91e699d4f01cc9b88297cc41a0d
Author: Sandra Loosemore
Date: Tue Jan 14 23:28:02 2025 +
OpenMP: C++ support for metadirectives and dynamic selectors.
Additional shared C/C++ testcases are included in a subsequent patch in this
series.
gcc/cp/ChangeLog
PR middle-end/112779
PR middle-end/113904
* cp-tree.h (struct saved_scope): Add new field
x_processing_omp_trait_property_expr.
(processing_omp_trait_property_expr): New.
* parser.cc (cp_parser_skip_to_end_of_block_or_statement): Add
metadirective_p parameter and handle skipping over the parentheses
in a "for" statement.
(struct omp_metadirective_parse_data): New.
(mangle_metadirective_region_label): New.
(cp_parser_label_for_labeled_statement): Mangle label names in a
metadirective body.
(cp_parser_jump_statement): Likewise.
(cp_parser_omp_context_selector): Allow arbitrary expressions in
device_num and condition properties.
(cp_parser_omp_assumption_clauses): Handle C_OMP_DIR_META.
(analyze_metadirective_body): New.
(cp_parser_omp_metadirective): New.
(cp_parser_pragma): Handle PRAGMA_OMP_METADIRECTIVE.
* parser.h (struct cp_parser): Add omp_metadirective_state field.
* pt.cc (tsubst_omp_context_selector): New.
(tsubst_stmt): Handle OMP_METADIRECTIVE.
* semantics.cc (finish_id_expression_1): Don't diagnose use of
parameter outside function body in dynamic selector expressions
here.
gcc/testsuite/
PR middle-end/112779
PR middle-end/113904
* c-c++-common/gomp/declare-variant-2.c: Adjust output for C++.
* g++.dg/gomp/declare-variant-class-1.C: New.
* g++.dg/gomp/declare-variant-class-2.C: New.
* g++.dg/gomp/metadirective-template-1.C: New.
libgomp/
PR middle-end/112779
PR middle-end/113904
* 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
Diff:
---
gcc/cp/cp-tree.h | 2 +
gcc/cp/parser.cc | 541 -
gcc/cp/parser.h| 6 +
gcc/cp/pt.cc | 126 +
gcc/cp/semantics.cc| 3 +-
.../c-c++-common/gomp/declare-variant-2.c | 4 +-
.../g++.dg/gomp/declare-variant-class-1.C | 32 ++
.../g++.dg/gomp/declare-variant-class-2.C | 37 ++
.../g++.dg/gomp/metadirective-template-1.C | 74 +++
.../libgomp.c++/metadirective-template-1.C | 39 ++
.../libgomp.c++/metadirective-template-2.C | 43 ++
.../libgomp.c++/metadirective-template-3.C | 43 ++
12 files changed, 927 insertions(+), 23 deletions(-)
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index bb10c7ca053d..269aca5d4f40 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1950,6 +1950,7 @@ struct GTY(()) saved_scope {
int suppress_location_wrappers;
BOOL_BITFIELD x_processing_explicit_instantiation : 1;
BOOL_BITFIELD need_pop_function_context : 1;
+ BOOL_BITFIELD x_processing_omp_trait_property_expr : 1;
/* Nonzero if we are parsing the discarded statement of a constexpr
if-statement. */
@@ -2021,6 +2022,7 @@ extern GTY(()) struct saved_scope *scope_chain;
#define processing_template_decl scope_chain->x_processing_template_decl
#define processing_specialization scope_chain->x_processing_specialization
#define processing_explicit_instantiation
scope_chain->x_processing_explicit_instantiation
+#define processing_omp_trait_property_expr
scope_chain->x_processing_omp_trait_property_expr
/* Nonzero if we are parsing the conditional expression of a contract
condition. These expressions appear outside the paramter list (like a
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 2d7ea9fbe2fc..74f4f7cd6d89 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -3020,7 +3020,7 @@ static void cp_parser_skip_to_end_of_statement
static void cp_parser_consume_semicolon_at_end_of_statement
(cp_parser *);
static void cp_parser_skip_to_end_of_block_or_statement
- (cp_parser *);
+ (cp_parser *, bool = false);
static bool cp_parser_skip_to_closing_brace
(cp_parser *);
static bool cp_parser_skip_entire_template_parameter_list
@@ -4245,9 +4245,11 @@ cp_parser_consume_semicolon_at_end_of_statement
(cp_parser *parser)
have consumed a non-nested `;'. */
[gcc r15-6989] OpenMP: Fix metadirective test failures on x86_64 with -m32
https://gcc.gnu.org/g:c6f9f53d6eb5a2568d231ffa56fbec3e2e4c626d
commit r15-6989-gc6f9f53d6eb5a2568d231ffa56fbec3e2e4c626d
Author: Sandra Loosemore
Date: Fri Jan 17 03:59:01 2025 +
OpenMP: Fix metadirective test failures on x86_64 with -m32
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.
Diff:
---
gcc/testsuite/c-c++-common/gomp/metadirective-device.c | 2 +-
gcc/testsuite/c-c++-common/gomp/metadirective-target-device-1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/c-c++-common/gomp/metadirective-device.c
b/gcc/testsuite/c-c++-common/gomp/metadirective-device.c
index 09b795eeabe9..380762477b07 100644
--- a/gcc/testsuite/c-c++-common/gomp/metadirective-device.c
+++ b/gcc/testsuite/c-c++-common/gomp/metadirective-device.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-additional-options "-foffload=disable -fdump-tree-optimized" } */
-/* { dg-additional-options "-DDEVICE_ARCH=x86_64 -DDEVICE_ISA=sse -msse" {
target x86_64-*-* } } */
+/* { dg-additional-options "-DDEVICE_ARCH=x86_64 -DDEVICE_ISA=sse -msse" {
target { x86_64-*-* && { ! ia32 } } } } */
#include
diff --git a/gcc/testsuite/c-c++-common/gomp/metadirective-target-device-1.c
b/gcc/testsuite/c-c++-common/gomp/metadirective-target-device-1.c
index 6373349d37f1..5d3a4c3ff9be 100644
--- a/gcc/testsuite/c-c++-common/gomp/metadirective-target-device-1.c
+++ b/gcc/testsuite/c-c++-common/gomp/metadirective-target-device-1.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-additional-options "-fdump-tree-optimized" } */
-/* { dg-additional-options "-DDEVICE_ARCH=x86_64 -DDEVICE_ISA=mmx -mmmx" {
target x86_64-*-* } } */
+/* { dg-additional-options "-DDEVICE_ARCH=x86_64 -DDEVICE_ISA=mmx -mmmx" {
target { x86_64-*-* && { ! ia32 } } } } */
#include
[gcc r15-7445] [PATCH] OpenMP: Improve Fortran metadirective diagnostics [PR107067]
https://gcc.gnu.org/g:5753f459444fa61a93d23325cd59467dc1838eef
commit r15-7445-g5753f459444fa61a93d23325cd59467dc1838eef
Author: Sandra Loosemore
Date: Sat Feb 8 17:44:55 2025 +
[PATCH] OpenMP: Improve Fortran metadirective diagnostics [PR107067]
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 either.
gcc/fortran/ChangeLog
PR middle-end/107067
* parse.cc (parse_omp_do): Diagnose missing "OMP END METADIRECTIVE"
after loop.
(parse_omp_structured_block): Likewise for strictly structured
block.
(parse_omp_metadirective_body): Use better test for variants ending
at different places. Issue a user diagnostic at the end if any
were inconsistent, instead of calling gcc_assert.
gcc/testsuite/ChangeLog
PR middle-end/107067
* gfortran.dg/gomp/metadirective-11.f90: Remove the dg-ice, update
for current behavior, and add more tests to exercise the new error
code.
Diff:
---
gcc/fortran/parse.cc | 62 +---
.../gfortran.dg/gomp/metadirective-11.f90 | 67 --
2 files changed, 114 insertions(+), 15 deletions(-)
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 5094d9d3eadf..336ea89c5a9f 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -5804,9 +5804,20 @@ do_end:
/* If handling a metadirective variant, treat 'omp end metadirective'
as the expected end statement for the current construct. */
- if (st == ST_OMP_END_METADIRECTIVE
- && gfc_state_stack->state == COMP_OMP_BEGIN_METADIRECTIVE)
-st = omp_end_st;
+ if (gfc_state_stack->state == COMP_OMP_BEGIN_METADIRECTIVE)
+{
+ if (st == ST_OMP_END_METADIRECTIVE)
+ st = omp_end_st;
+ else
+ {
+ /* We have found some extra statements between the loop
+and the "end metadirective" which is required in a
+"begin metadirective" construct, or perhaps the
+"end metadirective" is missing entirely. */
+ gfc_error_now ("Expected OMP END METADIRECTIVE at %C");
+ return st;
+ }
+}
if (st == omp_end_st)
{
@@ -6294,6 +6305,14 @@ parse_omp_structured_block (gfc_statement omp_st, bool
workshare_stmts_only)
accept_statement (st);
st = next_statement ();
}
+ else if (omp_end_st == ST_OMP_END_METADIRECTIVE)
+ {
+ /* We have found some extra statements between the END BLOCK
+and the "end metadirective" which is required in a
+"begin metadirective" construct, or perhaps the
+"end metadirective" is missing entirely. */
+ gfc_error_now ("Expected OMP END METADIRECTIVE at %C");
+ }
return st;
}
else if (st != omp_end_st || block_construct)
@@ -6409,10 +6428,12 @@ parse_omp_metadirective_body (gfc_statement omp_st)
gfc_omp_variant *variant
= new_st.ext.omp_variants;
locus body_locus = gfc_current_locus;
+ bool saw_error = false;
accept_statement (omp_st);
gfc_statement next_st = ST_NONE;
+ locus next_loc;
while (variant)
{
@@ -6470,8 +6491,24 @@ parse_omp_metadirective_body (gfc_statement omp_st)
reject_statement ();
st = next_statement ();
}
+
finish:
+ /* Sanity-check that each variant finishes parsing at the same place. */
+ if (next_st == ST_NONE)
+ {
+ next_st = st;
+ next_loc = gfc_current_locus;
+ }
+ else if (st != next_st
+ || next_loc.nextc != gfc_current_locus.nextc
+ || next_loc.u.lb != gfc_current_locus.u.lb)
+ {
+ saw_error = true;
+ next_st = st;
+ next_loc = gfc_current_locus;
+ }
+
gfc_in_omp_metadirective_body = old_in_metadirective_body;
if (gfc_state_stack->head)
@@ -6483,15 +6520,22 @@ parse_omp_metadirective_body (gfc_statement omp_st)
if (variant->next)
gfc_clear_new_st ();
- /* Sanity-check that each variant finishes parsing at the same place. */
- if (next_st == ST_NONE)
- next_st = st;
- else
- gcc_assert (st == next_st);
-
variant = variant->next;
}
+ if (saw_error)
+{
+ if (omp_st == ST_OMP_METADIRECTIVE)
+ gfc_error_now ("Variants in a metadirective at %L have "
+ "different associations; "
+ "consider using a BLOCK construct "
+ "or BEGIN/END METADIRECTIVE", &body_locus);
+ else
+ gfc_error_now ("Variants in a metadirect
[gcc r15-7487] Doc: Fix some typos and other nearby sloppy-writing issues
https://gcc.gnu.org/g:b9857b78a4afb7ccdb8ff3858b48d25b1df5ceb3
commit r15-7487-gb9857b78a4afb7ccdb8ff3858b48d25b1df5ceb3
Author: Sandra Loosemore
Date: Tue Feb 11 21:52:36 2025 +
Doc: Fix some typos and other nearby sloppy-writing issues
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.
* doc/invoke.texi: Likewise.
Diff:
---
gcc/doc/extend.texi | 87 ++---
gcc/doc/invoke.texi | 62 +++---
2 files changed, 74 insertions(+), 75 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index d79e97d9a030..065bd8b84e14 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -1004,17 +1004,16 @@ The ISO C++14 library also defines the @samp{i} suffix,
so C++14 code
that includes the @samp{} header cannot use @samp{i} for the
GNU extension. The @samp{j} suffix still has the GNU meaning.
-GCC can handle both implicit and explicit casts between the @code{_Complex}
-types and other @code{_Complex} types as casting both the real and imaginary
-parts to the scalar type.
-GCC can handle implicit and explicit casts from a scalar type to a
@code{_Complex}
-type and where the imaginary part will be considered zero.
-The C front-end can handle implicit and explicit casts from a @code{_Complex}
type
-to a scalar type where the imaginary part will be ignored. In C++ code, this
cast
-is considered illformed and G++ will error out.
-
-GCC provides a built-in function @code{__builtin_complex} will can be used to
-construct a complex value.
+GCC handles both implicit and explicit casts between the
+@code{_Complex} types with different scalar base types by casting both
+the real and imaginary parts to the base type of the result.
+GCC also handles implicit and explicit casts from a scalar type to a
+@code{_Complex} type, by giving the imaginary part a zero value.
+
+The C front end can handle implicit and explicit casts from a
+@code{_Complex} type to a scalar type, which uses the value of the
+real part and ignores the imaginary part. In C++ code, this cast is
+considered ill-formed and G++ diagnoses it as an error.
@cindex @code{__real__} keyword
@cindex @code{__imag__} keyword
@@ -1023,7 +1022,7 @@ GCC has a few extensions which can be used to extract the
real
and the imaginary part of the complex-valued expression. Note
these expressions are lvalues if the @var{exp} is an lvalue.
These expressions operands have the type of a complex type
-which might get prompoted to a complex type from a scalar type.
+which might get promoted to a complex type from a scalar type.
E.g. @code{__real__ (int)@var{x}} is the same as casting to
@code{_Complex int} before @code{__real__} is done.
@@ -1035,7 +1034,7 @@ E.g. @code{__real__ (int)@var{x}} is the same as casting
to
@tab Extract the imaginary part of @var{exp}.
@end multitable
-For values of floating point, you should use the ISO C99
+For values of floating-point type, you should use the ISO C99
functions, declared in @code{} and also provided as
built-in functions by GCC@.
@@ -1053,7 +1052,7 @@ with a complex type. This is a GNU extension; for values
of
floating type, you should use the ISO C99 functions @code{conjf},
@code{conj} and @code{conjl}, declared in @code{} and also
provided as built-in functions by GCC@. Note unlike the @code{__real__}
-and @code{__imag__} operators, this operator will not do an implicit cast
+and @code{__imag__} operators, this operator does not do an implicit cast
to the complex type because the @samp{~} is already a normal operator.
GCC can allocate complex automatic variables in a noncontiguous
@@ -3526,7 +3525,7 @@ mismatched allocation and deallocation functions and
diagnose them under
the control of options such as @option{-Wmismatched-dealloc}. It also
makes it possible to diagnose attempts to deallocate objects that were not
allocated dynamically, by @option{-Wfree-nonheap-object}. To indicate
-that an allocation function both satisifies the nonaliasing property and
+that an allocation function both satisfies the nonaliasing property and
has a deallocator associated with it, both the plain form of the attribute
and the one with the @var{deallocator} argument must be used. The same
function can be both an allocator and a deallocator. Since inlining one
@@ -3949,7 +3948,7 @@ caveats.
If the pointer argument is also referred to by an @code{access} attribute on
the
function with @var{access-mode} either @code{read_only} or @code{read_write}
and the latter attribute has the optional @var{size-index} argument
-referring to a size argument, this expressses the maximum size of the access.
+referring to a size argumen
[gcc r15-7486] Doc: Delete obsolete interface.texi chapter from GCC internals manual
https://gcc.gnu.org/g:29a5b1bdd9ff1bbfd2c367aea2f38fc23e6dbfb4
commit r15-7486-g29a5b1bdd9ff1bbfd2c367aea2f38fc23e6dbfb4
Author: Sandra Loosemore
Date: Wed Feb 12 00:17:30 2025 +
Doc: Delete obsolete interface.texi chapter from GCC internals manual
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 "standard compiler" on any target, and the target-specific
issues mentioned are for very old architectures.)
Meanwhile, the GCC user documentation now has a chapter called "Binary
Compatibility" that covers ABI issues in a generic way and also covers
C++ compatibility. Let's keep that one and throw out the obsolete
text that seems to predate the whole notion of an ABI.
gcc/ChangeLog
* Makefile.in (TEXI_GCCINT_FILES): Remove interface.texi.
* doc/gccint.texi (Top): Remove menu entry for the "interface" node,
and include of interface.texi.
* doc/interface.texi: Delete.
Diff:
---
gcc/Makefile.in| 2 +-
gcc/doc/gccint.texi| 5 +---
gcc/doc/interface.texi | 70 --
3 files changed, 2 insertions(+), 75 deletions(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index a8e32e25cf54..c159825e62c8 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3697,7 +3697,7 @@ TEXI_GCC_FILES = gcc.texi gcc-common.texi gcc-vers.texi
frontends.texi\
# the *.texi files have changed.
TEXI_GCCINT_FILES = gccint.texi gcc-common.texi gcc-vers.texi \
contribute.texi makefile.texi configterms.texi options.texi\
-portability.texi interface.texi passes.texi rtl.texi md.texi \
+portability.texi passes.texi rtl.texi md.texi \
$(srcdir)/doc/tm.texi hostconfig.texi fragments.texi \
configfiles.texi collect2.texi headerdirs.texi funding.texi\
gnu.texi gpl_v3.texi fdl.texi contrib.texi languages.texi \
diff --git a/gcc/doc/gccint.texi b/gcc/doc/gccint.texi
index eea2d48f87ab..d88fc1a1c683 100644
--- a/gcc/doc/gccint.texi
+++ b/gcc/doc/gccint.texi
@@ -87,8 +87,7 @@ Compiler Collection (GCC)}.
This manual is mainly a reference manual rather than a tutorial. It
discusses how to contribute to GCC (@pxref{Contributing}), the
characteristics of the machines supported by GCC as hosts and targets
-(@pxref{Portability}), how GCC relates to the ABIs on such systems
-(@pxref{Interface}), and the characteristics of the languages for
+(@pxref{Portability}), and the characteristics of the languages for
which GCC front ends are written (@pxref{Languages}). It then
describes the GCC source tree structure and build system, some of the
interfaces to GCC front ends, and how support for a target system is
@@ -100,7 +99,6 @@ Additional tutorial information is linked to from
@menu
* Contributing::How to contribute to testing and developing GCC.
* Portability:: Goals of GCC's portability features.
-* Interface:: Function-call interface of GCC output.
* Libgcc:: Low-level runtime library used by GCC.
* Languages:: Languages for which GCC front ends are written.
* Source Tree:: GCC source tree structure and build system.
@@ -141,7 +139,6 @@ Additional tutorial information is linked to from
@include contribute.texi
@include portability.texi
-@include interface.texi
@include libgcc.texi
@include languages.texi
@include sourcebuild.texi
diff --git a/gcc/doc/interface.texi b/gcc/doc/interface.texi
deleted file mode 100644
index 1688d6f66ecf..
--- a/gcc/doc/interface.texi
+++ /dev/null
@@ -1,70 +0,0 @@
-@c Copyright (C) 1988-2025 Free Software Foundation, Inc.
-@c This is part of the GCC manual.
-@c For copying conditions, see the file gcc.texi.
-
-@node Interface
-@chapter Interfacing to GCC Output
-@cindex interfacing to GCC output
-@cindex run-time conventions
-@cindex function call conventions
-@cindex conventions, run-time
-
-GCC is normally configured to use the same function calling convention
-normally in use on the target system. This is done with the
-machine-description macros described (@pxref{Target Macros}).
-
-@cindex unions, returning
-@cindex structures, returning
-@cindex returning structures and unions
-However, returning of structure and union values is done differently on
-some target machines. As a result, functions compiled with PCC
-returning such types cannot be called from code compiled with GCC,
-and vice versa. This does not cause trouble often because few Unix
-library routines return structures or unions.
-
-GCC code returns structures and unions that are 1, 2, 4 or 8 bytes
-long in the same registers used for @code{int} or @code{double} return
-values. (GCC typically allocate
[gcc r15-7488] Doc: Fix Texinfo warning in install.texi
https://gcc.gnu.org/g:805329e09cede41209f6c3502fa2c17aefffe91b
commit r15-7488-g805329e09cede41209f6c3502fa2c17aefffe91b
Author: Sandra Loosemore
Date: Tue Feb 11 22:13:49 2025 +
Doc: Fix Texinfo warning in install.texi
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.
Diff:
---
gcc/doc/install.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index d6cf318b3afe..bd7a38048eb3 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2292,7 +2292,7 @@ canadian cross build. The @option{--disable-nls} option
disables NLS@.
Note that this functionality requires either libintl (provided by GNU
gettext) or C standard library that contains support for gettext (such
as the GNU C Library).
-@xref{with-included-gettext,,--with-included-gettext} for more
+@xref{with-included-gettext,,--with-included-gettext}, for more
information on the conditions required to get gettext support.
@item --with-libintl-prefix=@var{dir}
[gcc r15-7930] Sanitizer: Fix typo in previous documentation patch.
https://gcc.gnu.org/g:85b46d0795ac76bc192cb8f88b646a647acf98c1
commit r15-7930-g85b46d0795ac76bc192cb8f88b646a647acf98c1
Author: Sandra Loosemore
Date: Mon Mar 10 16:59:36 2025 +
Sanitizer: Fix typo in previous documentation patch.
gcc/ChangeLog
* doc/invoke.texi (Instrumentation Options): Fix typo introduced
in commit 313edeeeb607fe32da5633cfb6f91977add446f6.
Diff:
---
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 3781697ae55f..853cb346dd67 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -17864,7 +17864,7 @@ The option cannot be combined with
@option{-fsanitize=thread} or
(only with @code{-mlam=u48} or @code{-mlam=u57} options) and AArch64,
in both cases only in ABIs with 64-bit pointers.
-When compiling with @option{-fsanitize=address}, you should also also
+When compiling with @option{-fsanitize=address}, you should also
use @option{-g} to produce more meaningful output.
To get more accurate stack traces, it is possible to use options such as
@option{-O0}, @option{-O1}, or @option{-Og} (which, for instance, prevent
[gcc r15-8683] Doc: Add "Additional Numeric Types" sectioning to extend.texi [PR42270]
https://gcc.gnu.org/g:557e809455a886e8f59f57e5c7b0a940e028d130
commit r15-8683-g557e809455a886e8f59f57e5c7b0a940e028d130
Author: Sandra Loosemore
Date: Thu Mar 13 03:43:04 2025 +
Doc: Add "Additional Numeric Types" sectioning to extend.texi [PR42270]
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.
(Long Long): Likewise.
(Complex): Likewise.
(Floating Types): Likewise.
(Half-Precision): Likewise.
(Decimal Float): Likewise.
(Fixed-Point): Likewise.
Diff:
---
gcc/doc/extend.texi | 94 ++---
1 file changed, 53 insertions(+), 41 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index b919df914648..92ab031fc904 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -31,14 +31,8 @@ extensions, accepted by GCC in C90 mode and in C++.
* Constructing Calls:: Dispatching a call to another function.
* Typeof:: @code{typeof}: referring to the type of an expression.
* Conditionals::Omitting the middle operand of a @samp{?:} expression.
-* __int128:: 128-bit integers---@code{__int128}.
-* Long Long:: Double-word integers---@code{long long int}.
-* Complex:: Data types for complex numbers.
-* Floating Types:: Additional Floating Types.
-* Half-Precision:: Half-Precision Floating Point.
-* Decimal Float:: Decimal Floating Types.
+* Additional Numeric Types:: Additional sizes and formats, plus complex
numbers.
* Hex Floats:: Hexadecimal floating-point constants.
-* Fixed-Point:: Fixed-Point Types.
* Named Address Spaces::Named address spaces.
* Zero Length:: Zero-length arrays.
* Empty Structures::Structures with no members.
@@ -928,8 +922,26 @@ the operand in the middle would perform the side effect
twice. Omitting
the middle operand uses the value already computed without the undesirable
effects of recomputing it.
+@node Additional Numeric Types
+@section Additional Numeric Types
+
+GCC supports additional numeric types, including larger integer types,
+integer and floating-point complex types,
+additional floating-point sizes and formats, decimal floating types,
+and fixed-point types.
+
+@menu
+* __int128:: 128-bit integers---@code{__int128}.
+* Long Long:: Double-word integers---@code{long long int}.
+* Complex:: Data types for complex numbers.
+* Floating Types:: Additional Floating Types.
+* Half-Precision:: Half-Precision Floating Point.
+* Decimal Float:: Decimal Floating Types.
+* Fixed-Point:: Fixed-Point Types.
+@end menu
+
@node __int128
-@section 128-bit Integers
+@subsection 128-bit Integers
@cindex @code{__int128} data types
As an extension the integer scalar type @code{__int128} is supported for
@@ -940,7 +952,7 @@ support in GCC for expressing an integer constant of type
@code{__int128}
for targets with @code{long long} integer less than 128 bits wide.
@node Long Long
-@section Double-Word Integers
+@subsection Double-Word Integers
@cindex @code{long long} data types
@cindex double-word arithmetic
@cindex multiprecision arithmetic
@@ -972,7 +984,7 @@ Likewise, if the function expects @code{long long int} and
you pass
@code{int}. The best way to avoid such problems is to use prototypes.
@node Complex
-@section Complex Numbers
+@subsection Complex Numbers
@cindex complex numbers
@cindex @code{_Complex} keyword
@cindex @code{__complex__} keyword
@@ -1083,7 +1095,7 @@ infinities, NaNs and negative zeros are involved.
@enddefbuiltin
@node Floating Types
-@section Additional Floating Types
+@subsection Additional Floating Types
@cindex additional floating types
@cindex @code{_Float@var{n}} data types
@cindex @code{_Float@var{n}x} data types
@@ -1169,7 +1181,7 @@ typedef _Complex float __attribute__((mode(IC)))
_Complex_ibm128;
@end smallexample
@node Half-Precision
-@section Half-Precision Floating Point
+@subsection Half-Precision Floating Point
@cindex half-precision floating point
@cindex @code{__fp16} data type
@cindex @code{__Float16} data type
@@ -1240,7 +1252,7 @@ It is useful for code that does not have @code{_Float16}
and runs on the x87
FPU.
@node Decimal Float
-@section Decimal Floating Types
+@subsection Decimal Floating Types
@cindex decimal floating types
@cindex @code{_Decimal32} data type
@cindex @code{_Decimal64} data type
@@ -1292,35 +1304,8 @@ the technical report.
Types @code{_Decimal32}, @code{_Decimal64}, and @code{_Decimal128}
are supported by the DWARF debug information format.
-@node Hex Floats
-@section Hex Floats
-@cindex hex floats
-
-I
[gcc r15-9232] Doc: Fix description of -Wno-aggressive-loop-optimizations [PR78874]
https://gcc.gnu.org/g:13c9b353895fef8d5b1593b7527df41487c512d1
commit r15-9232-g13c9b353895fef8d5b1593b7527df41487c512d1
Author: Sandra Loosemore
Date: Sun Apr 6 04:39:59 2025 +
Doc: Fix description of -Wno-aggressive-loop-optimizations [PR78874]
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.
Diff:
---
gcc/doc/invoke.texi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 91ed43dc21a0..d5103f461dfd 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10109,8 +10109,9 @@ a warning.)
@opindex Wno-aggressive-loop-optimizations
@opindex Waggressive-loop-optimizations
@item -Wno-aggressive-loop-optimizations
-Warn if in a loop with constant number of iterations the compiler detects
-undefined behavior in some statement during one or more of the iterations.
+Do not warn if the compiler detects undefined behavior in a loop with
+a constant number of iterations. @option{-Waggressive-loop-optimizations}
+is enabled by default.
@opindex Wno-attributes
@opindex Wattributes
[gcc r15-9236] Doc: Further clarify support for _Bool type
https://gcc.gnu.org/g:b39d5fad621c25812fb764e3a8808bab3f2fe774
commit r15-9236-gb39d5fad621c25812fb764e3a8808bab3f2fe774
Author: Sandra Loosemore
Date: Sun Apr 6 16:03:48 2025 +
Doc: Further clarify support for _Bool type
gcc/ChangeLog
* doc/extend.texi (Boolean Type): Further clarify support for
_Bool in C23 and C++.
Diff:
---
gcc/doc/extend.texi | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 16ad83fc510c..ae3357f83bff 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -13814,7 +13814,13 @@ The C99 standard added @code{_Bool} as a C language
keyword naming the
boolean type. As an extension, GNU C also recognizes @code{_Bool} in
C90 mode as well as with @option{-std=c99} and later.
-GNU C++ does not support the @code{_Bool} keyword.
+C23 added @code{bool} as the preferred name of the boolean type, but
+@code{_Bool} also remains a standard keyword in the language and is
+supported as such by GCC with @option{-std=c23}.
+
+GNU C++ does not support @code{_Bool} as a keyword, but including
+@code{} defines it as a macro in terms of standard C++'s
+@code{bool} type.
@node Variadic Macros
@subsection Macros with a Variable Number of Arguments.
[gcc r15-9225] Docs: Document -fcf-protection without argument [PR112589]
https://gcc.gnu.org/g:3026daa8edcc0d04ba6facdab84c5854255e55c6
commit r15-9225-g3026daa8edcc0d04ba6facdab84c5854255e55c6
Author: Sandra Loosemore
Date: Sat Apr 5 16:36:35 2025 +
Docs: Document -fcf-protection without argument [PR112589]
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 documention for the form without an argument.
Diff:
---
gcc/common.opt | 1 +
gcc/doc/invoke.texi | 27 ++-
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/gcc/common.opt b/gcc/common.opt
index b9e74cd3ac41..2c8fdde54f34 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2055,6 +2055,7 @@ Enum(ilsop_fn) String(memset) Value(ILSOP_MEMSET) Set(4)
fcf-protection
Common RejectNegative Alias(fcf-protection=,full)
+Equivalent to -fcf-protection=full.
fcf-protection=
Common Joined RejectNegative Enum(cf_protection_level) EnumSet
Var(flag_cf_protection) Init(CF_NONE)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 4c9af429ab08..8f51ea6d3e11 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -673,7 +673,7 @@ Objective-C and Objective-C++ Dialects}.
-fsanitize=@var{style} -fsanitize-recover -fsanitize-recover=@var{style}
-fsanitize-trap -fsanitize-trap=@var{style}
-fasan-shadow-offset=@var{number} -fsanitize-sections=@var{s1},@var{s2},...
--fsanitize-undefined-trap-on-error -fbounds-check
+-fsanitize-undefined-trap-on-error -fbounds-check -fcf-protection
-fcf-protection=@r{[}full@r{|}branch@r{|}return@r{|}none@r{|}check@r{]}
-fharden-compares -fharden-conditional-branches -fhardened
-fharden-control-flow-redundancy -fhardcfr-skip-leaf
@@ -18373,7 +18373,8 @@ operand constant, @code{__sanitizer_cov_trace_cmpf} or
@opindex fcf-protection
@item -fcf-protection=@r{[}full@r{|}branch@r{|}return@r{|}none@r{|}check@r{]}
-Enable code instrumentation of control-flow transfers to increase
+@itemx -fcf-protection
+Enable code instrumentation to increase
program security by checking that target addresses of control-flow
transfer instructions (such as indirect function call, function return,
indirect jump) are valid. This prevents diverting the flow of control
@@ -18381,22 +18382,30 @@ to an unexpected target. This is intended to protect
against such
threats as Return-oriented Programming (ROP), and similarly
call/jmp-oriented programming (COP/JOP).
+The @option{-fcf-protection=} keywords are interpreted as follows.
+
The value @code{branch} tells the compiler to implement checking of
validity of control-flow transfer at the point of indirect branch
-instructions, i.e.@: call/jmp instructions. The value @code{return}
-implements checking of validity at the point of returning from a
-function. The value @code{full} is an alias for specifying both
-@code{branch} and @code{return}. The value @code{none} turns off
-instrumentation.
+instructions, i.e.@: call/jmp instructions.
+
+The value @code{return} implements checking of validity at the point of
+returning from a function.
-To override @option{-fcf-protection}, @option{-fcf-protection=none}
-needs to be added and then with @option{-fcf-protection=xxx}.
+The value @code{full} is an alias for specifying both
+@code{branch} and @code{return}.
The value @code{check} is used for the final link with link-time
optimization (LTO). An error is issued if LTO object files are
compiled with different @option{-fcf-protection} values. The
value @code{check} is ignored at the compile time.
+The value @code{none} turns off instrumentation.
+
+@option{-fcf-protection} is an alias for @option{-fcf-protection=full}.
+To override a previous @option{-fcf-protection} option on the command
+line, add @option{-fcf-protection=none} and then
+@option{-fcf-protection=@var{kind}}.
+
The macro @code{__CET__} is defined when @option{-fcf-protection} is
used. The first bit of @code{__CET__} is set to 1 for the value
@code{branch} and the second bit of @code{__CET__} is set to 1 for
[gcc r15-9229] Doc: make regenerate-opt-urls
https://gcc.gnu.org/g:6bf272ec7f17288f461e048e9ca5dc85d83b2bd4 commit r15-9229-g6bf272ec7f17288f461e048e9ca5dc85d83b2bd4 Author: Sandra Loosemore Date: Sun Apr 6 02:26:27 2025 + Doc: make regenerate-opt-urls I keep forgetting to do this :-( gcc/c-family/ChangeLog * c.opt.urls: Regenerate. gcc/d/ChangeLog * lang.opt.urls: Regenerate. Diff: --- 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-family/c.opt.urls index 802729670b08..ad6d8a0b3873 100644 --- a/gcc/c-family/c.opt.urls +++ b/gcc/c-family/c.opt.urls @@ -82,6 +82,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Wabi) Wabi-tag UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-Wabi-tag) +Wpsabi +UrlSuffix(gcc/Warning-Options.html#index-Wno-psabi) + Wabsolute-value UrlSuffix(gcc/Warning-Options.html#index-Wabsolute-value) diff --git a/gcc/d/lang.opt.urls b/gcc/d/lang.opt.urls index 40bbca74b0ed..fa311d408a72 100644 --- a/gcc/d/lang.opt.urls +++ b/gcc/d/lang.opt.urls @@ -75,6 +75,9 @@ UrlSuffix(gcc/Warning-Options.html#index-Wextra) LangUrlSuffix_D(gdc/Warnings.ht Wmismatched-special-enum LangUrlSuffix_D(gdc/Warnings.html#index-Wmismatched-special-enum) +Wpsabi +UrlSuffix(gcc/Warning-Options.html#index-Wno-psabi) + Wspeculative LangUrlSuffix_D(gdc/Warnings.html#index-Wno-speculative)
[gcc r15-9228] Doc: Document -Wpsabi [PR81831]
https://gcc.gnu.org/g:027491d79b2749afb57aa5c8284ed69e6b1c44b5
commit r15-9228-g027491d79b2749afb57aa5c8284ed69e6b1c44b5
Author: Sandra Loosemore
Date: Sun Apr 6 00:11:39 2025 +
Doc: Document -Wpsabi [PR81831]
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/81831
* doc/invoke.texi (Option Summary): Add -Wno-psabi.
(Warning Options): Document -Wpsabi separately from -Wabi.
Note it's enabled by default, not just implied by -Wabi.
Replace the detailed example for a GCC 4.4 change for x86
(which is unlikely to be very interesting nowadays) with
just a list of all targets that presently diagnose these
warnings.
(RS/6000 and PowerPC Options): Add cross-references for
-Wno-psabi.
Diff:
---
gcc/c-family/c.opt | 3 ++-
gcc/doc/invoke.texi | 51 ---
2 files changed, 26 insertions(+), 28 deletions(-)
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index ad216983126e..75b6531860eb 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -303,7 +303,8 @@ C++ ObjC++ Var(warn_abi_tag) Warning
Warn if a subobject has an abi_tag attribute that the complete object type
does not have.
Wpsabi
-C ObjC C++ ObjC++ LTO Var(warn_psabi) Init(1) Warning Undocumented
LangEnabledBy(C ObjC C++ ObjC++,Wabi)
+C ObjC C++ ObjC++ LTO Var(warn_psabi) Init(1) Warning LangEnabledBy(C ObjC C++
ObjC++,Wabi)
+Warn about code affected by incompatible psABI changes.
Wabsolute-value
C ObjC Var(warn_absolute_value) Warning EnabledBy(Wextra)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8f51ea6d3e11..91ed43dc21a0 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -406,7 +406,9 @@ Objective-C and Objective-C++ Dialects}.
-Wparentheses -Wno-pedantic-ms-format
-Wpointer-arith -Wno-pointer-compare -Wno-pointer-to-int-cast
-Wno-pragmas -Wno-pragma-once-outside-header -Wno-prio-ctor-dtor
--Wredundant-decls -Wrestrict -Wno-return-local-addr -Wreturn-type
+-Wno-psabi
+-Wredundant-decls -Wrestrict
+-Wno-return-local-addr -Wreturn-type
-Wno-scalar-storage-order -Wsequence-point
-Wshadow -Wshadow=global -Wshadow=local -Wshadow=compatible-local
-Wno-shadow-ivar
@@ -6497,7 +6499,8 @@ of a derived class.
Warn about code affected by ABI changes. This includes code that may
not be compatible with the vendor-neutral C++ ABI as well as the psABI
-for the particular target.
+for the particular target. The latter warnings are also controlled
+separately by @option{-Wpsabi}, which is implied by @option{-Wabi}.
Since G++ now defaults to updating the ABI with each major release,
normally @option{-Wabi} warns only about C++ ABI compatibility
@@ -6600,27 +6603,21 @@ This was fixed in @option{-fabi-version=10}, the
default for GCC 6.1.
@end itemize
-This option also enables warnings about psABI-related changes.
-The known psABI changes at this point include:
+@opindex Wpsabi
+@opindex Wno-psabi
+@item -Wpsabi @r{(C, Objective-C, C++ and Objective-C++ only)}
-@itemize @bullet
-
-@item
-For SysV/x86-64, unions with @code{long double} members are
-passed in memory as specified in psABI. Prior to GCC 4.4, this was not
-the case. For example:
+@option{-Wpsabi} enables warnings about processor-specific ABI
+changes, such as changes in alignment requirements or how function
+arguments are passed. On several targets, including AArch64, ARM,
+x86, MIPS, RS6000/PowerPC, and S/390, these details have changed
+between different versions of GCC and/or different versions of the C
+or C++ language standards in ways that affect binary compatibility of
+compiled code. With @option{-Wpsabi}, GCC can detect potentially
+incompatible usages and warn you about them.
-@smallexample
-union U @{
- long double ld;
- int i;
-@};
-@end smallexample
-
-@noindent
-@code{union U} is now always passed in memory.
-
-@end itemize
+@option{-Wpsabi} is enabled by default, and is also implied by
+@option{-Wabi}.
@opindex Wchanges-meaning
@opindex Wno-changes-meaning
@@ -32452,18 +32449,18 @@ and for AIX: @samp{vec-extabi}, @samp{vec-default}@.
Change the current ABI to use IBM extended-precision long double.
This is not likely to work if your system defaults to using IEEE
extended-precision long double. If you change the long double type
-from IEEE extended-precision, the compiler will issue a warning unless
-you use the @option{-Wno-psabi} option. Requires @option{-mlong-double-128}
-to be enabled.
+from IEEE extended-precision, the compiler issues a warning unless
+you use the @option{-Wno-psabi} option (@pxref{Warning Options}).
+Requires @option{-mlo
[gcc r15-8961] OpenMP: Fix declaration in append-args-interop.c test case
https://gcc.gnu.org/g:876a521a198130bac638d682444e908b331c1185
commit r15-8961-g876a521a198130bac638d682444e908b331c1185
Author: Sandra Loosemore
Date: Thu Mar 27 00:59:37 2025 +
OpenMP: Fix declaration in append-args-interop.c test case
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 of the C front end code that checks whether
a type of a variant matches the base function after accounting for the
added interop arguments. Using "(void)" instead of "()" works in all
C dialects as well as C++, so do that.
gcc/testsuite/ChangeLog
* c-c++-common/gomp/append-args-interop.c: Fix declaration of base
function to be correct for pre-C23 dialects.
Diff:
---
gcc/testsuite/c-c++-common/gomp/append-args-interop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/c-c++-common/gomp/append-args-interop.c
b/gcc/testsuite/c-c++-common/gomp/append-args-interop.c
index 9494625cbbbc..1211450ce63e 100644
--- a/gcc/testsuite/c-c++-common/gomp/append-args-interop.c
+++ b/gcc/testsuite/c-c++-common/gomp/append-args-interop.c
@@ -23,7 +23,7 @@ typedef enum omp_interop_t __GOMP_UINTPTR_T_ENUM
float repl1(omp_interop_t, omp_interop_t, omp_interop_t);
#pragma omp declare variant(repl1) match(construct={dispatch})
append_args(interop(target), interop(targetsync), interop (target))
-float base1();
+float base1(void);
float
test (int *a, int *b)
[gcc/devel/omp/gcc-14] testsuite: Fix up append-args-interop.f90 test
https://gcc.gnu.org/g:dbf98134378b63b1a5c206f8db0739ceb7fdffe3 commit dbf98134378b63b1a5c206f8db0739ceb7fdffe3 Author: Jakub Jelinek Date: Wed Mar 26 14:41:15 2025 +0100 testsuite: Fix up append-args-interop.f90 test The gcc/testsuite/*/gomp/ tests aren't compiled with include or module paths pointing to libgomp, so shouldn't be using omp.h nor use omp_lib etc. The following patch adjusts the test to define it locally, like e.g. recently in interop-5.f90 test or many other tests which have their own definitions of types or enumerators they need. 2025-03-26 Jakub Jelinek * gfortran.dg/gomp/append-args-interop.f90: Don't use omp_lib, instead use iso_c_binding and define omp_interop_kind parameter locally. (cherry picked from commit d402a3911d5eeb4680397458aa31dad4c3f5136e) Diff: --- gcc/testsuite/gfortran.dg/gomp/append-args-interop.f90 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/testsuite/gfortran.dg/gomp/append-args-interop.f90 b/gcc/testsuite/gfortran.dg/gomp/append-args-interop.f90 index 11a0f01daa46..f2c4d9714647 100644 --- a/gcc/testsuite/gfortran.dg/gomp/append-args-interop.f90 +++ b/gcc/testsuite/gfortran.dg/gomp/append-args-interop.f90 @@ -6,7 +6,8 @@ ! append_args clause. module m - use omp_lib, only: omp_interop_kind + use iso_c_binding, only: c_intptr_t + integer, parameter :: omp_interop_kind = c_intptr_t contains subroutine g(x,y,z) integer(omp_interop_kind) :: x, y, z
[gcc/devel/omp/gcc-14] OpenMP: Fix declaration in append-args-interop.c test case
https://gcc.gnu.org/g:ce9c73f85adb2929ce191f891103d00a32d0129c
commit ce9c73f85adb2929ce191f891103d00a32d0129c
Author: Sandra Loosemore
Date: Thu Mar 27 00:59:37 2025 +
OpenMP: Fix declaration in append-args-interop.c test case
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 of the C front end code that checks whether
a type of a variant matches the base function after accounting for the
added interop arguments. Using "(void)" instead of "()" works in all
C dialects as well as C++, so do that.
gcc/testsuite/ChangeLog
* c-c++-common/gomp/append-args-interop.c: Fix declaration of base
function to be correct for pre-C23 dialects.
(cherry picked from commit 876a521a198130bac638d682444e908b331c1185)
Diff:
---
gcc/testsuite/c-c++-common/gomp/append-args-interop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/c-c++-common/gomp/append-args-interop.c
b/gcc/testsuite/c-c++-common/gomp/append-args-interop.c
index 9494625cbbbc..1211450ce63e 100644
--- a/gcc/testsuite/c-c++-common/gomp/append-args-interop.c
+++ b/gcc/testsuite/c-c++-common/gomp/append-args-interop.c
@@ -23,7 +23,7 @@ typedef enum omp_interop_t __GOMP_UINTPTR_T_ENUM
float repl1(omp_interop_t, omp_interop_t, omp_interop_t);
#pragma omp declare variant(repl1) match(construct={dispatch})
append_args(interop(target), interop(targetsync), interop (target))
-float base1();
+float base1(void);
float
test (int *a, int *b)
[gcc/devel/omp/gcc-14] OpenMP: Create additional interop objects with append_args
https://gcc.gnu.org/g:8110f3d036ed33770e5a2f0ab89b3600c26df457
commit 8110f3d036ed33770e5a2f0ab89b3600c26df457
Author: Sandra Loosemore
Date: Wed Mar 26 21:09:36 2025 +
OpenMP: Create additional interop objects with append_args
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 the GOMP_interop builtin.
This is a backport of commit f016ee89955ab4da5fe7ef89368e9437bb5ffb13 from
mainline.
gcc/fortran/ChangeLog
* trans-openmp.cc (gfc_trans_omp_declare_variant): Remove accidental
redeclaration of pref.
gcc/ChangeLog
* gimplify.cc (modify_call_for_omp_dispatch): Adjust arguments.
Remove the "sorry" for the case where new interop objects must be
constructed, and add code to make it work instead.
(gimplify_variant_call_expr): Re-work want_value/pointerize logic
and adjust the calls to modify_call_for_omp_dispatch.
gcc/testsuite/ChangeLog
* c-c++-common/gomp/append-args-1.c: Adjust expected behavior.
* c-c++-common/gomp/append-args-interop.c: New.
* c-c++-common/gomp/dispatch-11.c: Adjust expected behavior.
* g++.dg/gomp/append-args-1.C: Likewise.
* gfortran.dg/gomp/append-args-interop.f90: New.
* gfortran.dg/gomp/declare-variant-mod-2.f90: Adjust expected
behavior.
libgomp/ChangeLog
* libgomp.texi (OpenMP 5.1): Mark append_args as fully supported.
Co-Authored-By: Tobias Burnus
Diff:
---
gcc/fortran/trans-openmp.cc| 4 +-
gcc/gimplify.cc| 226 ++---
gcc/testsuite/c-c++-common/gomp/append-args-1.c| 14 +-
.../c-c++-common/gomp/append-args-interop.c| 44
gcc/testsuite/c-c++-common/gomp/dispatch-11.c | 3 -
gcc/testsuite/g++.dg/gomp/append-args-1.C | 18 +-
.../gfortran.dg/gomp/append-args-interop.f90 | 27 +++
.../gfortran.dg/gomp/declare-variant-mod-2.f90 | 6 -
libgomp/libgomp.texi | 3 +-
9 files changed, 278 insertions(+), 67 deletions(-)
diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index b226cf5b231b..534e5b769eae 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -11628,8 +11628,8 @@ gfc_trans_omp_declare_variant (gfc_namespace *ns,
gfc_namespace *parent_ns)
tree pref = NULL_TREE;
if (n->u.init.len)
{
- tree pref = build_string (n->u.init.len,
- n->u2.init_interop);
+ pref = build_string (n->u.init.len,
+ n->u2.init_interop);
TREE_TYPE (pref) = build_array_type_nelts (
unsigned_char_type_node,
n->u.init.len);
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 042dd6f32fcf..9592b5f8043d 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3894,8 +3894,8 @@ maybe_fold_stmt (gimple_stmt_iterator *gsi)
/* OpenMP: Handle the append_args and adjust_args clauses of
declare_variant for EXPR, which is a CALL_EXPR whose CALL_EXPR_FN
- is the variant, within a dispatch construct with clauses DISPATCH_CLAUSES
- and location DISPATCH_LOC.
+ is the variant, within a dispatch construct with clauses DISPATCH_CLAUSES.
+ WANT_VALUE and POINTERIZE are as for expand_variant_call_expr.
'append_args' causes interop objects are added after the last regular
(nonhidden, nonvariadic) arguments of the variant function.
@@ -3905,7 +3905,7 @@ maybe_fold_stmt (gimple_stmt_iterator *gsi)
address. */
static tree
modify_call_for_omp_dispatch (tree expr, tree dispatch_clauses,
- location_t dispatch_loc)
+ bool want_value, bool pointerize)
{
tree fndecl = get_callee_fndecl (expr);
@@ -3913,9 +3913,11 @@ modify_call_for_omp_dispatch (tree expr, tree
dispatch_clauses,
if (!fndecl)
return expr;
+ tree init_code = NULL_TREE;
+ tree cleanup = NULL_TREE;
+ tree clobbers = NULL_TREE;
int nargs = call_expr_nargs (expr);
tree dispatch_device_num = NULL_TREE;
- tree dispatch_device_num_init = NULL_TREE;
tree dispatch_interop = NULL_TREE;
tree dispatch_append_args = NULL_TREE;
int nfirst_args = 0;
@@ -3976,14 +3978,6 @@ modify_call_for_omp_dispatch (tree expr, tree
dispatch_clauses,
"the % clause must be present if the % "
[gcc r15-9045] Doc: Move Integer Overflow Builtins section [PR42270]
https://gcc.gnu.org/g:7af7e80d859da9a2c0f6d228b8489e0bd8c0e61c
commit r15-9045-g7af7e80d859da9a2c0f6d228b8489e0bd8c0e61c
Author: Sandra Loosemore
Date: Wed Mar 26 16:43:18 2025 +
Doc: Move Integer Overflow Builtins section [PR42270]
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.
Diff:
---
gcc/doc/extend.texi | 303 ++--
1 file changed, 153 insertions(+), 150 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index de9c2b36ba38..f0bbff6dd042 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -14244,8 +14244,6 @@ a function call results in a compile-time error.
* Stack Scrubbing:: Stack scrubbing internal interfaces.
* Vector Extensions:: Using vector instructions through built-in functions.
* Atomic Memory Access:: __atomic and __sync builtins.
-* Integer Overflow Builtins:: Built-in functions to perform arithmetics and
-arithmetic overflow checking.
* Object Size Checking:: Built-in functions for limited buffer overflow
checking.
* New/Delete Builtins:: Built-in functions for C++ allocations and
deallocations.
@@ -14831,6 +14829,8 @@ floating-point or integer operand.
* Bit Operation Builtins:: Counting bits and similar functions.
* Byte-Swapping Builtins:: Reversing byte order.
* CRC Builtins:: Compute cyclic redundancy checks.
+* Integer Overflow Builtins:: Built-in functions to perform arithmetics
+ and arithmetic overflow checking.
@end menu
@node Floating-Point Format Builtins
@@ -15445,6 +15445,157 @@ Similar to @code{__builtin_crc64_data64}, except the
@var{data} argument type
is 32-bit.
@enddefbuiltin
+@node Integer Overflow Builtins
+@subsection Built-in Functions to Perform Arithmetic with Overflow Checking
+@cindex overflow checking builtins
+@cindex integer arithmetic overflow checking builtins
+@cindex builtins for arithmetic overflow checking
+
+The following built-in functions allow performing simple arithmetic operations
+together with checking whether the operations overflowed.
+
+@defbuiltin{bool __builtin_add_overflow (@var{type1} @var{a}, @var{type2}
@var{b}, @var{type3} *@var{res})}
+@defbuiltinx{bool __builtin_sadd_overflow (int @var{a}, int @var{b}, int
*@var{res})}
+@defbuiltinx{bool __builtin_saddl_overflow (long int @var{a}, long int
@var{b}, long int *@var{res})}
+@defbuiltinx{bool __builtin_saddll_overflow (long long int @var{a}, long long
int @var{b}, long long int *@var{res})}
+@defbuiltinx{bool __builtin_uadd_overflow (unsigned int @var{a}, unsigned int
@var{b}, unsigned int *@var{res})}
+@defbuiltinx{bool __builtin_uaddl_overflow (unsigned long int @var{a},
unsigned long int @var{b}, unsigned long int *@var{res})}
+@defbuiltinx{bool __builtin_uaddll_overflow (unsigned long long int @var{a},
unsigned long long int @var{b}, unsigned long long int *@var{res})}
+
+These built-in functions promote the first two operands into infinite
precision signed
+type and perform addition on those promoted operands. The result is then
+cast to the type the third pointer argument points to and stored there.
+If the stored result is equal to the infinite precision result, the built-in
+functions return @code{false}, otherwise they return @code{true}. As the
addition is
+performed in infinite signed precision, these built-in functions have fully
defined
+behavior for all argument values.
+
+The first built-in function allows arbitrary integral types for operands and
+the result type must be pointer to some integral type other than enumerated or
+boolean type, the rest of the built-in functions have explicit integer types.
+
+The compiler will attempt to use hardware instructions to implement
+these built-in functions where possible, like conditional jump on overflow
+after addition, conditional jump on carry etc.
+
+@enddefbuiltin
+
+@defbuiltin{bool __builtin_sub_overflow (@var{type1} @var{a}, @var{type2}
@var{b}, @var{type3} *@var{res})}
+@defbuiltinx{bool __builtin_ssub_overflow (int @var{a}, int @var{b}, int
*@var{res})}
+@defbuiltinx{bool __builtin_ssubl_overflow (long int @var{a}, long int
@var{b}, long int *@var{res})}
+@defbuiltinx{bool __builtin_ssubll_overflow (long long int @var{a}, long long
int @var{b}, long long int *@var{res})}
+@defbuiltinx{bool __builtin_usub_overflow (unsigned int @var{a}, unsigned int
@var{b}, unsigned int *@var{res})}
+@defbuiltinx{bool __builtin_usubl_overflow (unsigned long int @var{a},
unsigned long int @var{b}, unsigned long int *@var{res})}
+@defbuiltinx{bool __builtin_usubll_overflow (unsigned long long int @var{a},
unsigned long
[gcc r15-9042] Doc: Move builtin documentation to a new chapter [PR42270]
https://gcc.gnu.org/g:1fb78f025f726e2268da142f07007b1fb0819fb1
commit r15-9042-g1fb78f025f726e2268da142f07007b1fb0819fb1
Author: Sandra Loosemore
Date: Tue Mar 25 05:25:34 2025 +
Doc: Move builtin documentation to a new chapter [PR42270]
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, but I ran into a technical limitation of Texinfo:
it only supports sectioning depth up to @subsubsection, and we already
had quite a few of those in the target-specific builtins sections. So
instead I have pulled all the existing sections out into a new
chapter. This actually makes sense since some of the builtins are
specific to C++ anyway and are not C language extensions at all.
Subsequent patches in this series will move things around within the
new chapter; this one just adds the new container node and adjusts
the menus.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (C Extensions): Move menu items for
builtin-related sections to...
(Built-in Functions): New chapter.
* doc/gcc.texi (Introduction): Add menu entry for new chapter.
Diff:
---
gcc/doc/extend.texi | 51 ---
gcc/doc/gcc.texi| 1 +
2 files changed, 37 insertions(+), 15 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 371e82a6852f..386b6b0f5b1d 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -36,21 +36,6 @@ extensions, accepted by GCC in C90 mode and in C++.
* Using Assembly Language with C:: Instructions and extensions for interfacing
C with assembler.
* Syntax Extensions:: Other extensions to C syntax.
* Semantic Extensions:: GNU C defines behavior for some non-standard
constructs.
-* Nonlocal Gotos:: Built-ins for nonlocal gotos.
-* Constructing Calls:: Built-ins for dispatching a call to another function.
-* Return Address:: Getting the return or frame address of a function.
-* Stack Scrubbing:: Stack scrubbing internal interfaces.
-* Vector Extensions:: Using vector instructions through built-in functions.
-* __sync Builtins:: Legacy built-in functions for atomic memory access.
-* __atomic Builtins:: Atomic built-in functions with memory model.
-* Integer Overflow Builtins:: Built-in functions to perform arithmetics and
-arithmetic overflow checking.
-* x86 specific memory model extensions for transactional memory:: x86 memory
models.
-* Object Size Checking:: Built-in functions for limited buffer overflow
-checking.
-* New/Delete Builtins:: Built-in functions for C++ allocations and
deallocations.
-* Other Builtins:: Other built-in functions.
-* Target Builtins:: Built-in functions specific to particular targets.
@end menu
@node Additional Numeric Types
@@ -14217,6 +14202,42 @@ extension explicit. Additionally, using @code{const}
and
@code{volatile} in this way is specific to GNU C and does not work in
GNU C++.
+@node Built-in Functions
+@chapter Built-in Functions Provided by GCC
+@cindex Built-in Functions
+
+GCC provides a very large number of implicitly-declared built-in
+functions that are typically inlined by the compiler. Some of these
+builtins directly correspond to standard library routines, while
+others provide the underlying functionality needed to implement
+features provided by library functions or similar ``glue'' between GCC
+and other programming languages or libraries. Others are
+target-specific, providing direct access to instructions that have no
+direct C equivalents without the need to write assembly language. There
+are also builtins to support various kinds of runtime error checking.
+
+Most builtins have names prefixed with @samp{__builtin_}. Except as
+otherwise documented, all built-in functions are available from any
+of the C family languages supported by GCC.
+
+@menu
+* Nonlocal Gotos:: Built-ins for nonlocal gotos.
+* Constructing Calls:: Built-ins for dispatching a call to another function.
+* Return Address:: Getting the return or frame address of a function.
+* Stack Scrubbing:: Stack scrubbing internal interfaces.
+* Vector Extensions:: Using vector instructions through built-in functions.
+* __sync Builtins:: Legacy built-in functions for atomic memory access.
+* __atomic Builtins:: Atomic built-in functions with memory model.
+* Integer Overflow Builtins:: Built-in functions to perform arithmetics and
+arithmetic overflow checking.
+* x86 specific memory model extensions for transactional memory:: x86 memory
models.
+* Object Size Checking:: Built-in functions for limited buffer
[gcc r15-9041] Doc: Add a container section to consolidate attribute documentation [PR42270]
https://gcc.gnu.org/g:1cfb1b58804859199bc2502ab35e08bfd0039040
commit r15-9041-g1cfb1b58804859199bc2502ab35e08bfd0039040
Author: Sandra Loosemore
Date: Tue Mar 25 02:56:48 2025 +
Doc: Add a container section to consolidate attribute documentation
[PR42270]
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 the new container section that is more explicit about
both syntaxes being accepted as a GNU extension.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Attributes): New section.
(Function Attributes): Make it a subsection of the new section.
(Variable Attributes): Likewise.
(Type Attributes): Likewise.
(Label Attributes): Likewise.
(Enumerator Attributes): Likewise.
(Attribute Syntax): Likewise.
Diff:
---
gcc/doc/extend.texi | 174 ++--
1 file changed, 101 insertions(+), 73 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index e68b810c043b..371e82a6852f 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -26,14 +26,7 @@ extensions, accepted by GCC in C90 mode and in C++.
* Additional Numeric Types:: Additional sizes and formats, plus complex
numbers.
* Aggregate Types::Extensions to arrays, structs, and unions.
* Named Address Spaces::Named address spaces.
-* Function Attributes:: Declaring that functions have no side effects,
-or that they can never return.
-* Variable Attributes:: Specifying attributes of variables.
-* Type Attributes:: Specifying attributes of types.
-* Label Attributes::Specifying attributes on labels.
-* Enumerator Attributes:: Specifying attributes on enumerators.
-* Statement Attributes:: Specifying attributes on statements.
-* Attribute Syntax::Formal syntax for attributes.
+* Attributes:: GCC supports both standard and legacy attribute syntax.
* Pragmas:: Pragmas accepted by GCC.
* Thread-Local::Per-thread variables.
* OpenMP:: Multiprocessing extensions.
@@ -1595,8 +1588,43 @@ The preprocessor symbols @code{__SEG_FS} and
@code{__SEG_GS} are
defined when these address spaces are supported.
@end table
+@node Attributes
+@section Attributes Specific to GCC
+@cindex attributes
+@cindex declaring attributes
+@cindex GNU attributes
+
+Attributes provide a mechanism to declare additional properties of
+functions, variables, types, and statements. For example, attributes
+can be used to control placement of objects in particular memory
+sections, or to specify properties that can allow the compiler to
+generate better code or diagnostics, such as declaring that a function
+never returns. GCC supports a large number of such attributes, which
+are documented in this section.
+
+GCC provides two different ways to specify attributes: the traditional
+GNU syntax using @samp{__attribute__ ((...))} annotations, and the
+newer standard C and C++ syntax using @samp{[[...]]} with the
+@samp{gnu::} namespace prefix on attribute names.
+The traditional syntax, described in detail in @ref{Attribute Syntax},
+is supported in all non-strict C and C++ language dialects.
+The standard syntax is supported in C with @option{-std=c23} or later,
+in C++ with @option{-std=c++11} or later, and as an extension in older
+GNU C and C++ dialects.
+
+@menu
+* Function Attributes:: Declaring that functions have no side effects,
+or that they can never return.
+* Variable Attributes:: Specifying attributes of variables.
+* Type Attributes:: Specifying attributes of types.
+* Label Attributes::Specifying attributes on labels.
+* Enumerator Attributes:: Specifying attributes on enumerators.
+* Statement Attributes:: Specifying attributes on statements.
+* Attribute Syntax::Formal syntax for attributes.
+@end menu
+
@node Function Attributes
-@section Declaring Attributes of Functions
+@subsection Declaring Attributes of Functions
@cindex function attributes
@cindex declaring attributes of functions
@@ -1698,7 +1726,7 @@ GCC plugins may provide their own attributes.
@end menu
@node Common Function Attributes
-@subsection Common Function Attributes
+@subsubsection Common Function Attributes
The following attributes are supported on most targets.
@@ -3760,7 +3788,7 @@ The default for the attribute is controlled by
@option{-fzero-call-used-regs}.
@c This is the end of the target-independent attribute table
@node AArch64 Function Attributes
-@subsection AArch64 Function Attributes
+@subsubsection AArch64 Function Attributes
The following target-specific function attributes are available for the
AArch
[gcc r15-9040] Doc: Remove separate "Target Format Checks" section [PR42270]
https://gcc.gnu.org/g:991aa8f992a4f5ea6ebe1bd7aec61d3071c23b8f
commit r15-9040-g991aa8f992a4f5ea6ebe1bd7aec61d3071c23b8f
Author: Sandra Loosemore
Date: Tue Mar 25 05:22:38 2025 +
Doc: Remove separate "Target Format Checks" section [PR42270]
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 into the main discussion of the "format" attribute,
in particular because that discussion already contains similar discussion
for mingw/Windows targets.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Function Attributes): Merge text from "Target
Format Checks" into the main discussion of the format and
format_arg attributes.
(Target Format Checks): Delete section.
Diff:
---
gcc/doc/extend.texi | 95 ++---
1 file changed, 39 insertions(+), 56 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index ed766e53dcc4..e68b810c043b 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -58,7 +58,6 @@ extensions, accepted by GCC in C90 mode and in C++.
* New/Delete Builtins:: Built-in functions for C++ allocations and
deallocations.
* Other Builtins:: Other built-in functions.
* Target Builtins:: Built-in functions specific to particular targets.
-* Target Format Checks:: Format checks specific to particular targets.
@end menu
@node Additional Numeric Types
@@ -2219,18 +2218,43 @@ for consistency with the @code{printf} style format
string argument
@code{my_format}.
The parameter @var{archetype} determines how the format string is
-interpreted, and should be @code{printf}, @code{scanf}, @code{strftime},
+interpreted.
+Valid archetypes include @code{printf}, @code{scanf}, @code{strftime},
@code{gnu_printf}, @code{gnu_scanf}, @code{gnu_strftime} or
@code{strfmon}. (You can also use @code{__printf__},
-@code{__scanf__}, @code{__strftime__} or @code{__strfmon__}.) On
-MinGW targets, @code{ms_printf}, @code{ms_scanf}, and
-@code{ms_strftime} are also present.
+@code{__scanf__}, @code{__strftime__} or @code{__strfmon__}.)
@var{archetype} values such as @code{printf} refer to the formats accepted
by the system's C runtime library,
while values prefixed with @samp{gnu_} always refer
-to the formats accepted by the GNU C Library. On Microsoft Windows
-targets, values prefixed with @samp{ms_} refer to the formats accepted by the
+to the formats accepted by the GNU C Library.
+
+@anchor{Target Format Checks}
+On MinGW and Microsoft Windows targets, @code{ms_printf},
+@code{ms_scanf}, and @code{ms_strftime} are also present. Values
+prefixed with @samp{ms_} refer to the formats accepted by the
@file{msvcrt.dll} library.
+
+@anchor{Solaris Format Checks}
+Solaris targets also support the @code{cmn_err} (or @code{__cmn_err__})
+archetype.
+@code{cmn_err} accepts a subset of the standard @code{printf}
+conversions, and the two-argument @code{%b} conversion for displaying
+bit-fields. See the Solaris man page for @code{cmn_err} for more information.
+
+@anchor{Darwin Format Checks}
+Darwin targets also support the @code{CFString} (or
+@code{__CFString__}) archetype in the @code{format} attribute.
+Declarations with this archetype are parsed for correct syntax
+and argument types. However, parsing of the format string itself and
+validating arguments against it in calls to such functions is currently
+not performed.
+
+For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
+recognized in the same context. Declarations including these format attributes
+are parsed for correct syntax, however the result of checking of such format
+strings is not yet defined, and is not carried out by this version of the
+compiler.
+
The parameter @var{string-index}
specifies which argument is the format string argument (starting
from 1), while @var{first-to-check} is the number of the first
@@ -2265,15 +2289,7 @@ standard modes, the X/Open function @code{strfmon} is
also checked as
are @code{printf_unlocked} and @code{fprintf_unlocked}.
@xref{C Dialect Options,,Options Controlling C Dialect}.
-For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
-recognized in the same context. Declarations including these format attributes
-are parsed for correct syntax, however the result of checking of such format
-strings is not yet defined, and is not carried out by this version of the
-compiler.
-The target may also provide additional types of format checks.
-@xref{Target Format Checks,,Format Checks Specific to Particular
-Target Machines}.
@cindex @code{format_arg} function attribute
@opindex Wformat-nonliteral
@@ -2328,13 +2344,17 @@ requested by @option{-ansi
[gcc r15-9137] Doc: Document enum with underlying type extension [PR117689]
https://gcc.gnu.org/g:42b2fc3fc9c06c174ec4d2c0566f54b624bc70b5
commit r15-9137-g42b2fc3fc9c06c174ec4d2c0566f54b624bc70b5
Author: Sandra Loosemore
Date: Tue Apr 1 19:34:14 2025 +
Doc: Document enum with underlying type extension [PR117689]
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
PR c/117689
* doc/extend.texi (Incomplete Enums): Rename to
(Enum Extensions): This. Document support for specifying the
underlying type of an enum as an extension in all earlier C
and C++ standards. Document that a forward declaration with
underlying type is not an incomplete type, and which dialects
GCC supports that in.
Diff:
---
gcc/doc/extend.texi | 62 ++---
1 file changed, 50 insertions(+), 12 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index a49b1cdd1e35..76fb210060da 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -12943,7 +12943,7 @@ C and/or C++ standards, while others remain specific to
GNU C.
* Typeof:: @code{typeof}: referring to the type of an expression.
* Offsetof::Special syntax for @code{offsetof}.
* Alignment:: Determining the alignment of a function, type or
variable.
-* Incomplete Enums::@code{enum foo;}, with details to follow.
+* Enum Extensions:: Forward declarations and specifying the underlying
type.
* Variadic Macros:: Macros with a variable number of arguments.
* Conditionals::Omitting the middle operand of a @samp{?:} expression.
* Case Ranges:: `case 1 ... 9' and such.
@@ -13643,22 +13643,60 @@ If the operand of the @code{__alignof__} expression
is a function,
the expression evaluates to the alignment of the function which may
be specified by attribute @code{aligned} (@pxref{Common Function Attributes}).
-@node Incomplete Enums
-@subsection Incomplete @code{enum} Types
+@node Enum Extensions
+@subsection Extensions to @code{enum} Type Declarations
+@anchor{Incomplete Enums}
+@cindex @code{enum} extensions
+@cindex base type of an @code{enum}
+@cindex underlying type of an @code{enum}
+@cindex forward declaration of an @code{enum}
+@cindex opaque @code{enum} types
+@cindex incomplete @code{enum} types
-You can define an @code{enum} tag without specifying its possible values.
-This results in an incomplete type, much like what you get if you write
-@code{struct foo} without describing the elements. A later declaration
-that does specify the possible values completes the type.
+The C23 and C++11 standards added new syntax to specify the underlying
+type of an @code{enum} type. For example,
+@smallexample
+enum pet : unsigned char @{ CAT, DOG, ROCK @};
+@end smallexample
+
+In GCC, this feature is supported as an extension in all older
+dialects of C and C++ as well. For C++ dialects before C++11, use
+@option{-Wno-c++11-extensions} to silence the associated warnings.
+
+You can also forward-declare an @code{enum} type, without specifying
+its possible values. The enumerators are supplied in a later
+redeclaration of the type, which must match the underlying type of the
+first declaration.
+
+@smallexample
+enum pet : unsigned char;
+static enum pet my_pet;
+...
+enum pet : unsigned char @{ CAT, DOG, ROCK @};
+@end smallexample
+
+Forward declaration of @code{enum} types with an explicit underlying
+type is also a feature of C++11 that is supported as an extension by
+GCC for all C dialects. However, it's not available in C++ dialects
+prior to C++11.
+
+The C++ standard refers to a forward declaration of an @code{enum}
+with an explicit underlying type as an @dfn{opaque type}. It is not
+considered an incomplete type, since its size is known. That means
+you can declare variables or allocate storage using the type before
+the redeclaration, not just use pointers of that type.
+
+GCC has also traditionally supported forward declarations of
+@code{enum} types that don't include an explicit underlying type
+specification. This results in an incomplete type, much like what you
+get if you write @code{struct foo} without describing the elements.
You cannot allocate variables or storage using the type while it is
incomplete. However, you can work with pointers to that type.
-This extension may not be very useful, but it makes the handling of
-@code{enum} more consistent with the way @code{struct} and @code{union}
-are handled.
-
-This extension is not supported by GNU C++.
+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
[gcc r15-9140] Doc: Document _Bool type as C90 extension [PR118118]
https://gcc.gnu.org/g:4c708fa411fa708e7abc717b0880d6f708967a37
commit r15-9140-g4c708fa411fa708e7abc717b0880d6f708967a37
Author: Sandra Loosemore
Date: Tue Apr 1 23:10:16 2025 +
Doc: Document _Bool type as C90 extension [PR118118]
gcc/ChangeLog
PR c/118118
* doc/extend.texi (Boolean Type): New section.
Diff:
---
gcc/doc/extend.texi | 12
1 file changed, 12 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 76fb210060da..d2bf6048be78 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -12944,6 +12944,7 @@ C and/or C++ standards, while others remain specific to
GNU C.
* Offsetof::Special syntax for @code{offsetof}.
* Alignment:: Determining the alignment of a function, type or
variable.
* Enum Extensions:: Forward declarations and specifying the underlying
type.
+* Boolean Type:: Support for the @code{_Bool} keyword.
* Variadic Macros:: Macros with a variable number of arguments.
* Conditionals::Omitting the middle operand of a @samp{?:} expression.
* Case Ranges:: `case 1 ... 9' and such.
@@ -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
+@subsection Support for the @code{_Bool} Type
+@cindex boolean type
+@cindex @code{_Bool} keyword
+
+The C99 standard added @code{_Bool} as a C language keyword naming the
+boolean type. As an extension, GNU C also recognizes @code{_Bool} in
+C90 mode as well as with @option{-std=c99} and later.
+
+GNU C++ does not support the @code{_Bool} keyword.
+
@node Variadic Macros
@subsection Macros with a Variable Number of Arguments.
@cindex variable number of arguments
[gcc r15-9142] Doc: Cross-reference constructor and init_priority attributes [PR118982]
https://gcc.gnu.org/g:12533c0c8b27dcbb1b83517bf4eb09faa98bf814
commit r15-9142-g12533c0c8b27dcbb1b83517bf4eb09faa98bf814
Author: Sandra Loosemore
Date: Wed Apr 2 02:50:10 2025 +
Doc: Cross-reference constructor and init_priority attributes [PR118982]
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 Wakely
gcc/ChangeLog
PR c++/118982
* doc/extend.texi (Common Function Attributes): For the
constructor/destructory attribute, be more explicit about the
relationship between the constructor attribute and
the C++ init_priority attribute, and add a cross-reference.
Also document that most targets support this.
(C++ Attributes): Similarly for the init_priority attribute.
Diff:
---
gcc/doc/extend.texi | 51 ---
1 file changed, 32 insertions(+), 19 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index d2bf6048be78..48c3aeb1318b 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2035,24 +2035,32 @@ called. Functions with these attributes are useful for
initializing data that is used implicitly during the execution of
the program.
-On some targets the attributes also accept an integer argument to
+On most targets the attributes also accept an integer argument to
specify a priority to control the order in which constructor and
-destructor functions are run. A constructor
-with a smaller priority number runs before a constructor with a larger
-priority number; the opposite relationship holds for destructors. Note
-that priorities 0-100 are reserved. So, if you have a constructor that
+destructor functions are run. The @var{priority} argument is a
+constant integral expression bounded between 101 and 65535 inclusive;
+priorities 0-100 are reserved for use by the compiler and its runtime
+libraries.
+A constructor with a smaller priority number runs before a constructor with
+a larger priority number; the opposite relationship holds for destructors.
+So, if you have a constructor that
allocates a resource and a destructor that deallocates the same
-resource, both functions typically have the same priority. The
-priorities for constructor and destructor functions are the same as
-those specified for namespace-scope C++ objects (@pxref{C++ Attributes}).
-However, at present, the order in which constructors for C++ objects
-with static storage duration and functions decorated with attribute
-@code{constructor} are invoked is unspecified. In mixed declarations,
-attribute @code{init_priority} can be used to impose a specific ordering.
-
-Using the argument forms of the @code{constructor} and @code{destructor}
-attributes on targets where the feature is not supported is rejected with
-an error.
+resource, both functions typically have the same priority.
+
+The order in which constructors for C++ objects with static storage
+duration are invoked relative to functions decorated with attribute
+@code{constructor} is normally unspecified. You can use
+attribute @code{init_priority} (@pxref{C++ Attributes}) on the
+declarations of namespace-scope C++ objects to impose a specific
+ordering; the @var{priority} for the @code{init_priority} attribute
+has the same effect as the @var{priority} for the @code{constructor}
+attribute.
+
+Using the argument form of the @code{constructor} and
+@code{destructor} attributes on targets where the feature is not
+supported is rejected with an error. Only a few targets (typically
+those not using ELF object format, or the GNU linker) reject this
+usage.
@cindex @code{copy} function attribute
@item copy
@@ -30291,11 +30299,11 @@ variable or function or moving it into a tagged
inline namespace.
In Standard C++, objects defined at namespace scope are guaranteed to be
initialized in an order in strict accordance with that of their definitions
@emph{in a given translation unit}. No guarantee is made for initializations
-across translation units. However, GNU C++ allows users to control the
+across translation units. However, GNU C++ allows you to control the
order of initialization of objects defined at namespace scope with the
@code{init_priority} attribute by specifying a relative @var{priority},
-a constant integral expression currently bounded between 101 and 65535
-inclusive. Lower numbers indicate a higher priority.
+with the same meaning as for the @code{constructor} attribute
+(@pxref{Common Function Attributes}).
In the following example, @code{A} would normally be created before
@code{B}, but the @code{init_priority} attribute reverses that order:
@@ -30309,6 +30317,11 @@ Some_Class B __attribute__
[gcc r15-9320] Doc: Copy-edit text about -Wno-xxx [PR90468]
https://gcc.gnu.org/g:5c06ad9ab4a922c86265b2a1b167597c87b646f7
commit r15-9320-g5c06ad9ab4a922c86265b2a1b167597c87b646f7
Author: Sandra Loosemore
Date: Tue Apr 8 16:58:05 2025 +
Doc: Copy-edit text about -Wno-xxx [PR90468]
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 more likely to run into.
gcc/ChangeLog
PR c++/90468
* doc/invoke.texi (Warning Options): Clean up text describing
-Wno-xxx.
Diff:
---
gcc/doc/invoke.texi | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index c1d06da4f5bc..a040d65af0e2 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -6180,10 +6180,11 @@ messages.
@end table
You can request many specific warnings with options beginning with
-@samp{-W}, for example @option{-Wimplicit} to request warnings on
-implicit declarations. Each of these specific warning options also
-has a negative form beginning @samp{-Wno-} to turn off warnings; for
-example, @option{-Wno-implicit}. This manual lists only one of the
+@samp{-W}, for example @option{-Wunused-variable} to request warnings on
+declarations of variables that are never used.
+Each of these specific warning options also
+has a negative form beginning with @samp{-Wno-} to turn off warnings; for
+example, @option{-Wno-unused-variable}. This manual lists only one of the
two forms, whichever is not the default. For further
language-specific options also refer to @ref{C++ Dialect Options} and
@ref{Objective-C and Objective-C++ Dialect Options}.
@@ -6192,15 +6193,15 @@ Additional warnings can be produced by enabling the
static analyzer;
Some options, such as @option{-Wall} and @option{-Wextra}, turn on other
options, such as @option{-Wunused}, which may turn on further options,
-such as @option{-Wunused-value}. The combined effect of positive and
+such as @option{-Wunused-variable}. The combined effect of positive and
negative forms is that more specific options have priority over less
-specific ones, independently of their position in the command-line. For
+specific ones, independently of their position in the command line. For
options of the same specificity, the last one takes effect. Options
enabled or disabled via pragmas (@pxref{Diagnostic Pragmas}) take effect
-as if they appeared at the end of the command-line.
+as if they appeared at the end of the command line.
When an unrecognized warning option is requested (e.g.,
-@option{-Wunknown-warning}), GCC emits a diagnostic stating
+@option{-Wunknown-warning}), GCC gives an error stating
that the option is not recognized. However, if the @option{-Wno-} form
is used, the behavior is slightly different: no diagnostic is
produced for @option{-Wno-unknown-warning} unless other diagnostics
@@ -6209,11 +6210,11 @@ with old compilers, but if something goes wrong, the
compiler
warns that an unrecognized option is present.
The effectiveness of some warnings depends on optimizations also being
-enabled. For example @option{-Wsuggest-final-types} is more effective
-with link-time optimization and some instances of other warnings may
+enabled. For example, @option{-Wsuggest-final-types} is more effective
+with link-time optimization. Some other warnings may
not be issued at all unless optimization is enabled. While optimization
-in general improves the efficacy of control and data flow sensitive
-warnings, in some cases it may also cause false positives.
+in general improves the efficacy of warnings about control and data-flow
+problems, in some cases it may also cause false positives.
@table @gcctabopt
@opindex pedantic
[gcc r15-9389] Doc: Delete misleading sentence from -frounding-math docs [PR105548]
https://gcc.gnu.org/g:93f6ea830348a5a733ecde863cddae80d84bdda0
commit r15-9389-g93f6ea830348a5a733ecde863cddae80d84bdda0
Author: Sandra Loosemore
Date: Fri Apr 11 21:16:41 2025 +
Doc: Delete misleading sentence from -frounding-math docs [PR105548]
gcc/ChangeLog
PR middle-end/105548
* doc/invoke.texi (Optimize Options): Delete misleading sentence
about conversions.
Diff:
---
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 ffde9df85fd3..b9dc3fc7ccdf 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15505,9 +15505,8 @@ default state for @code{FENV_ACCESS}.
@opindex frounding-math
@item -frounding-math
Disable transformations and optimizations that assume default floating-point
-rounding behavior. This is round-to-zero for all floating point
-to integer conversions, and round-to-nearest for all other arithmetic
-truncations. This option should be specified for programs that change
+rounding behavior (round-to-nearest).
+This option should be specified for programs that change
the FP rounding mode dynamically, or that may be executed with a
non-default rounding mode. This option disables constant folding of
floating-point expressions at compile time (which may be affected by
[gcc r15-9390] Doc: Correct documentation for -fstrong-eval-order [PR106618]
https://gcc.gnu.org/g:498933e54dc4669276951d27d3b1bcdc0d4bacb4
commit r15-9390-g498933e54dc4669276951d27d3b1bcdc0d4bacb4
Author: Sandra Loosemore
Date: Fri Apr 11 22:18:45 2025 +
Doc: Correct documentation for -fstrong-eval-order [PR106618]
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
references to C++17.
Diff:
---
gcc/doc/invoke.texi | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b9dc3fc7ccdf..4be80a7f7f9a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -211,8 +211,7 @@ in the following sections.
@item C++ Language Options
@xref{C++ Dialect Options,,Options Controlling C++ Dialect}.
@gccoptlist{-fabi-version=@var{n} -fno-access-control
--faligned-new=@var{n} -fargs-in-order=@var{n}
--fno-assume-sane-operators-new-delete
+-faligned-new=@var{n} -fno-assume-sane-operators-new-delete
-fchar8_t -fcheck-new
-fconcepts -fconstexpr-depth=@var{n} -fconstexpr-cache-depth=@var{n}
-fconstexpr-loop-limit=@var{n} -fconstexpr-ops-limit=@var{n}
@@ -235,6 +234,7 @@ in the following sections.
-fno-optional-diags
-fno-pretty-templates -frange-for-ext-temps
-fno-rtti -fsized-deallocation
+-fstrong-eval-order@r{[}=@var{kind}@r{]}
-ftemplate-backtrace-limit=@var{n}
-ftemplate-depth=@var{n}
-fno-threadsafe-statics -fuse-cxa-atexit
@@ -3581,12 +3581,19 @@ type.
@opindex fstrong-eval-order
@item -fstrong-eval-order
+@itemx -fstrong-eval-order=@var{kind}
Evaluate member access, array subscripting, and shift expressions in
left-to-right order, and evaluate assignment in right-to-left order,
-as adopted for C++17. Enabled by default with @option{-std=c++17}.
+as adopted for C++17. @option{-fstrong-eval-order} is equivalent to
+@option{-fstrong-eval-order=all},
+and is enabled by default with @option{-std=c++17} or later.
+
@option{-fstrong-eval-order=some} enables just the ordering of member
-access and shift expressions, and is the default without
-@option{-std=c++17}.
+access and shift expressions, and is the default for C++ dialects prior to
+C++17.
+
+@option{-fstrong-eval-order=none} is equivalent to
+@option{-fno-strong-eval-order}.
@opindex ftemplate-backtrace-limit
@item -ftemplate-backtrace-limit=@var{n}
[gcc r15-9475] Doc: always_inline attribute vs multiple TUs and LTO [PR113203]
https://gcc.gnu.org/g:fc89b1face0d207710eaa3d8f5af3adcffd5c5c9
commit r15-9475-gfc89b1face0d207710eaa3d8f5af3adcffd5c5c9
Author: Sandra Loosemore
Date: Tue Apr 15 03:49:06 2025 +
Doc: always_inline attribute vs multiple TUs and LTO [PR113203]
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.
Diff:
---
gcc/doc/extend.texi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 3a8e57065150..5bc2785f8025 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -1933,6 +1933,13 @@ Note that if such a function is called indirectly the
compiler may
or may not inline it depending on optimization level and a failure
to inline an indirect call may or may not be diagnosed.
+If you need to use the inlined function in multiple translation units,
+you should put the @code{always_inline} attribute on a function
+definition in a header file that is included in all translation units
+where the function is used. Link-time optimization can inline
+functions across translation units, but only if an optimization level
+that normally enables inlining is additionally specified.
+
@cindex @code{artificial} function attribute
@item artificial
This attribute is useful for small inline wrappers that if possible
[gcc/devel/omp/gcc-14] OpenMP: testsuite fixup for g++.dg/gomp/adjust-args-7.C
https://gcc.gnu.org/g:97067daf1d8e90e3b618ec7fd341a8b2395a6d35
commit 97067daf1d8e90e3b618ec7fd341a8b2395a6d35
Author: Sandra Loosemore
Date: Wed Apr 30 04:16:22 2025 +
OpenMP: testsuite fixup for g++.dg/gomp/adjust-args-7.C
I screwed up this testcase when backporting "OpenMP: C/C++ adjust-args
numeric ranges" to OG14.
gcc/testsuite/ChangeLog
* g++.dg/gomp/adjust-args-7.C: Put dg-require-effective-target
in a comment.
Diff:
---
gcc/testsuite/g++.dg/gomp/adjust-args-7.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/g++.dg/gomp/adjust-args-7.C
b/gcc/testsuite/g++.dg/gomp/adjust-args-7.C
index ceebfeffa739..c793f2f1d20a 100644
--- a/gcc/testsuite/g++.dg/gomp/adjust-args-7.C
+++ b/gcc/testsuite/g++.dg/gomp/adjust-args-7.C
@@ -1,4 +1,4 @@
-{ dg-require-effective-target c++11 }
+/* { dg-require-effective-target c++11 } */
/* PR c++/118859 */
/* Diagnose invalid substituted types of depdendent parameters specified
[gcc/devel/omp/gcc-14] OpenMP: need_device_ptr and need_device_addr support for adjust_args
https://gcc.gnu.org/g:9a06e4d6a117497c2536bf89bb6c7536289e44bb
commit 9a06e4d6a117497c2536bf89bb6c7536289e44bb
Author: Sandra Loosemore
Date: Wed Apr 30 17:46:31 2025 +
OpenMP: need_device_ptr and need_device_addr support for adjust_args
This patch adds support for the "need_device_addr" modifier to the
"adjust args" clause for the "declare variant" directive, and
extends/re-works the support for "need_device_ptr" as well.
This patch builds on waffl3x's recently posted patch, "OpenMP: C/C++
adjust-args numeric ranges", here.
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681806.html
In C++, "need_device_addr" supports mapping reference arguments to
device pointers. In Fortran, it similarly supports arguments passed
by reference, the default for the language, in contrast to
"need_device_ptr" which is used to map arguments of c_ptr type. The
C++ support is straightforward, but Fortran has some additional
wrinkles involving arrays passed by descriptor (a new descriptor must
be constructed with a pointer to the array data which is the only part
mapped to the device), plus special cases for passing optional
arguments and a whole array instead of a reference to its first element.
gcc/cp/ChangeLog
* parser.cc (cp_finish_omp_declare_variant): Adjust error messages.
gcc/fortran/ChangeLog
* trans-openmp.cc (gfc_trans_omp_declare_variant): Disallow
polymorphic and optional arguments with need_device_addr for now,
but
don't reject need_device_addr entirely.
gcc/ChangeLog
* gimplify.cc (modify_call_for_omp_dispatch): Rework logic for
need_device_ptr and need_device_addr adjustments.
gcc/testsuite/Changelog
* c-c++-common/gomp/adjust-args-10.c: Ignore the new sorry since the
lack of proper diagnostic is already xfail'ed.
* g++.dg/gomp/adjust-args-1.C: Adjust output patterns.
* g++.dg/gomp/adjust-args-17.C: New.
* gcc.dg/gomp/adjust-args-3.c: New.
* gfortran.dg/gomp/adjust-args-14.f90: Don't expect this to fail
now.
libgomp/ChangeLog
* libgomp.texi: Mark need_device_addr as supported.
* testsuite/libgomp.c-c++-common/dispatch-3.c: New.
* testsuite/libgomp.c++/need-device-ptr.C: New.
* testsuite/libgomp.fortran/adjust-args-array-descriptor.f90: New.
* testsuite/libgomp.fortran/need-device-ptr.f90: New.
Co-Authored-By: Tobias Burnus
Diff:
---
gcc/cp/parser.cc | 7 +-
gcc/fortran/trans-openmp.cc| 44 --
gcc/gimplify.cc| 88 +--
gcc/testsuite/c-c++-common/gomp/adjust-args-10.c | 2 +
gcc/testsuite/g++.dg/gomp/adjust-args-1.C | 6 +-
gcc/testsuite/g++.dg/gomp/adjust-args-17.C | 44 ++
gcc/testsuite/gcc.dg/gomp/adjust-args-3.c | 47 ++
gcc/testsuite/gfortran.dg/gomp/adjust-args-14.f90 | 2 +-
libgomp/libgomp.texi | 1 +
libgomp/testsuite/libgomp.c++/need-device-ptr.C| 175 +
.../testsuite/libgomp.c-c++-common/dispatch-3.c| 35 +
.../adjust-args-array-descriptor.f90 | 89 +++
.../testsuite/libgomp.fortran/need-device-ptr.f90 | 132
13 files changed, 633 insertions(+), 39 deletions(-)
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 747209fc77f1..e60687f4a4e6 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -51407,7 +51407,8 @@ cp_finish_omp_declare_variant (cp_parser *parser,
cp_token *pragma_tok,
else
{
error_at (adjust_op_tok->location,
- "expected % or %");
+ "expected %, % or "
+ "%");
/* We should be trying to recover here instead of immediately
failing, skipping to close paren and continuing. */
goto fail;
@@ -51418,8 +51419,8 @@ cp_finish_omp_declare_variant (cp_parser *parser,
cp_token *pragma_tok,
/* We should be trying to recover here instead of immediately
failing, skipping to close paren and continuing. */
error_at (adjust_op_tok->location,
- "expected % or % followed "
- "by %<:%>");
+ "expected %, % or "
+ "% followed by %<:%>");
goto fail;
}
/* cp_parser_omp_var_list_no_open used to handle this, we don't use
diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index 73ec9324dea1..b22bdfdf309e 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -11968,6 +11968,34 @@ gfc_trans_omp_declare_variant
[gcc r15-9371] Doc: Discourage the use of -ffloat-store [PR14708]
https://gcc.gnu.org/g:0c210fbbd70af16326ca64bf3447eb38b6fd6e0d
commit r15-9371-g0c210fbbd70af16326ca64bf3447eb38b6fd6e0d
Author: Sandra Loosemore
Date: Fri Apr 11 00:06:17 2025 +
Doc: Discourage the use of -ffloat-store [PR14708]
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.
Diff:
---
gcc/doc/invoke.texi | 42 +++---
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a040d65af0e2..05f6ca66fcef 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15318,32 +15318,24 @@ arithmetic. These options trade off between speed and
correctness. All must be specifically enabled.
@table @gcctabopt
-@opindex ffloat-store
-@item -ffloat-store
-Do not store floating-point variables in registers, and inhibit other
-options that might change whether a floating-point value is taken from a
-register or memory.
-
-@cindex floating-point precision
-This option prevents undesirable excess precision on machines such as
-the 68000 where the floating registers (of the 68881) keep more
-precision than a @code{double} is supposed to have. Similarly for the
-x86 architecture. For most programs, the excess precision does only
-good, but a few programs rely on the precise definition of IEEE floating
-point. Use @option{-ffloat-store} for such programs, after modifying
-them to store all pertinent intermediate computations into variables.
-
@opindex fexcess-precision
@item -fexcess-precision=@var{style}
-This option allows further control over excess precision on machines
+This option allows control over excess precision on machines
where floating-point operations occur in a format with more precision or
-range than the IEEE standard and interchange floating-point types. By
-default, @option{-fexcess-precision=fast} is in effect; this means that
+range than the IEEE standard and interchange floating-point types.
+An example of such a target is x87 floating point on x86 processors,
+which uses an 80-bit representation internally instead of the 64-bit
+IEEE format. For most programs, the excess precision is harmless,
+but some programs may rely on the
+requirements of the C or C++ language standards for handling IEEE values.
+
+By default, @option{-fexcess-precision=fast} is in effect; this means that
operations may be carried out in a wider precision than the types specified
in the source if that would result in faster code, and it is unpredictable
when rounding to the types specified in the source code takes place.
When compiling C or C++, if @option{-fexcess-precision=standard} is specified
-then excess precision follows the rules specified in ISO C99 or C++; in
particular,
+then excess precision follows the rules specified in ISO C99 or C++;
+in particular,
both casts and assignments cause values to be rounded to their
semantic types (whereas @option{-ffloat-store} only affects
assignments). This option is enabled by default for C or C++ if a strict
@@ -15361,6 +15353,18 @@ or @option{-mfpmath=sse+387} is specified; in the
former case, IEEE
semantics apply without excess precision, and in the latter, rounding
is unpredictable.
+@opindex ffloat-store
+@item -ffloat-store
+Do not store floating-point variables in registers, and inhibit other
+options that might change whether a floating-point value is taken from a
+register or memory. This option has generally been subsumed by
+@option{-fexcess-precision=standard}, which is more general. If you do use
+@option{-ffloat-store}, you may need to modify your program to explicitly
+store intermediate computations in temporary variables since
+@option{-ffloat-store} handles rounding to IEEE format
+only on assignments and not casts as @option{-fexcess-precision=standard}
+does.
+
@opindex ffast-math
@item -ffast-math
Sets the options @option{-fno-math-errno},
@option{-funsafe-math-optimizations},
[gcc r15-9374] Doc: Add missing documentation for -ftree-cselim [PR87909]
https://gcc.gnu.org/g:f6b0dc1b1c5f1736e77a42512085f9ab290775fd
commit r15-9374-gf6b0dc1b1c5f1736e77a42512085f9ab290775fd
Author: Sandra Loosemore
Date: Fri Apr 11 03:16:26 2025 +
Doc: Add missing documentation for -ftree-cselim [PR87909]
gcc/ChangeLog
PR tree-optimization/87909
* common.opt.urls: Regenerate.
* doc/invoke.texi (Option Summary): Add -ftree-cselim.
(Optimize Options): Likewise.
Diff:
---
gcc/common.opt.urls | 3 +++
gcc/doc/invoke.texi | 10 --
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/gcc/common.opt.urls b/gcc/common.opt.urls
index 860ebd01ace2..a4b14f5241fc 100644
--- a/gcc/common.opt.urls
+++ b/gcc/common.opt.urls
@@ -1459,6 +1459,9 @@
UrlSuffix(gcc/Optimize-Options.html#index-ftree-coalesce-vars)
ftree-copy-prop
UrlSuffix(gcc/Optimize-Options.html#index-ftree-copy-prop)
+ftree-cselim
+UrlSuffix(gcc/Optimize-Options.html#index-ftree-cselim)
+
ftree-switch-conversion
UrlSuffix(gcc/Optimize-Options.html#index-ftree-switch-conversion)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 05f6ca66fcef..ffde9df85fd3 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -642,8 +642,8 @@ Objective-C and Objective-C++ Dialects}.
-fsplit-wide-types -fsplit-wide-types-early -fssa-backprop -fssa-phiopt
-fstdarg-opt -fstore-merging -fstrict-aliasing -fipa-strict-aliasing
-fthread-jumps -ftracer -ftree-bit-ccp
--ftree-builtin-call-dce -ftree-ccp -ftree-ch
--ftree-coalesce-vars -ftree-copy-prop -ftree-dce -ftree-dominator-opts
+-ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-coalesce-vars
+-ftree-copy-prop -ftree-cselim -ftree-dce -ftree-dominator-opts
-ftree-dse -ftree-forwprop -ftree-fre -fcode-hoisting
-ftree-loop-if-convert -ftree-loop-im
-ftree-phiprop -ftree-loop-distribution -ftree-loop-distribute-patterns
@@ -14072,6 +14072,12 @@ in this pass can
be limited using @option{max-tail-merge-comparisons} parameter and
@option{max-tail-merge-iterations} parameter.
+@opindex ftree-cselim
+@item -ftree-cselim
+Perform conditional store elimination on trees. This flag is enabled by
+default at @option{-O1} and higher on targets that have conditional
+move instructions.
+
@opindex ftree-dce
@item -ftree-dce
Perform dead code elimination (DCE) on trees. This flag is enabled by
[gcc r15-9529] Doc: Add pointer to --help use to main entry for -Q option [PR90465]
https://gcc.gnu.org/g:a5212edf268fde45783106b33e6f74d56d6210d4
commit r15-9529-ga5212edf268fde45783106b33e6f74d56d6210d4
Author: Sandra Loosemore
Date: Wed Apr 16 18:17:11 2025 +
Doc: Add pointer to --help use to main entry for -Q option [PR90465]
-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 for -Q in
connection with --help=.
(Developer Options): Point at --help= documentation for the
other use of -Q.
Diff:
---
gcc/doc/invoke.texi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 0b6644b03154..14a78fd236f6 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2199,6 +2199,7 @@ those that have already been displayed. If
@option{--help} is also
specified anywhere on the command line then this takes precedence
over any @option{--help=} option.
+@opindex Q
If the @option{-Q} option appears on the command line before the
@option{--help=} option, then the descriptive text displayed by
@option{--help=} is changed. Instead of describing the displayed
@@ -21311,8 +21312,13 @@ Toggle @option{-fvar-tracking-assignments}, in the
same way that
@opindex Q
@item -Q
-Makes the compiler print out each function name as it is compiled, and
-print some statistics about each pass when it finishes.
+When used on the command line prior to @option{--help=}, @option{-Q}
+acts as a modifier to the help output. @xref{Overall Options},
+for details about @option{--help=}.
+
+Otherwise, this option makes the compiler print out each function name
+as it is compiled, and print some statistics about each pass when it
+finishes.
@opindex ftime-report
@item -ftime-report
[gcc r15-9534] Doc: make regenerate-opt-urls
https://gcc.gnu.org/g:dbffeadf7f682625c7ac8c251ee62c02c90f32df commit r15-9534-gdbffeadf7f682625c7ac8c251ee62c02c90f32df Author: Sandra Loosemore Date: Wed Apr 16 18:51:28 2025 + Doc: make regenerate-opt-urls gcc/ChangeLog * common.opt.urls: Regenerated. Diff: --- gcc/common.opt.urls | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gcc/common.opt.urls b/gcc/common.opt.urls index 8bd75b1153b0..00775118e6f4 100644 --- a/gcc/common.opt.urls +++ b/gcc/common.opt.urls @@ -31,8 +31,9 @@ UrlSuffix(gcc/Optimize-Options.html#index-Og) Oz UrlSuffix(gcc/Optimize-Options.html#index-Oz) -Q -UrlSuffix(gcc/Developer-Options.html#index-Q) +; skipping UrlSuffix for 'Q' due to multiple URLs: +; duplicate: 'gcc/Developer-Options.html#index-Q-1' +; duplicate: 'gcc/Overall-Options.html#index-Q' Qn UrlSuffix(gcc/System-V-Options.html#index-Qn)
[gcc r15-9539] Doc: Document raw string literals as GNU C extension [PR88382]
https://gcc.gnu.org/g:47561e459e7ea6ad2451310a3f9fee38fc08318d
commit r15-9539-g47561e459e7ea6ad2451310a3f9fee38fc08318d
Author: Sandra Loosemore
Date: Wed Apr 16 22:16:16 2025 +
Doc: Document raw string literals as GNU C extension [PR88382]
gcc/ChangeLog
PR c/88382
* doc/extend.texi (Syntax Extensions): Adjust menu.
(Raw String Literals): New section.
Diff:
---
gcc/doc/extend.texi | 20
1 file changed, 20 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 5bc2785f8025..0978c4c41b25 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -12978,6 +12978,7 @@ C and/or C++ standards, while others remain specific to
GNU C.
* Binary constants::Binary constants using the @samp{0b} prefix.
* Dollar Signs::Dollar sign is allowed in identifiers.
* Character Escapes:: @samp{\e} stands for the character @key{ESC}.
+* Raw String Literals::C++ raw string literals are supported in C.
* Alternate Keywords:: @code{__const__}, @code{__asm__}, etc., for header
files.
* Function Names:: Printable strings which are the name of the current
function.
@@ -13999,6 +14000,25 @@ machines, typically because the target assembler does
not allow them.
You can use the sequence @samp{\e} in a string or character constant to
stand for the ASCII character @key{ESC}.
+@node Raw String Literals
+@subsection Raw String Literals
+@cindex raw string literals
+@cindex string literals, raw
+
+The C++11 standard added syntax for raw string literals prefixed
+with @samp{R}. This syntax allows you to use an arbitrary delimiter
+sequence instead of escaping special characters within the string.
+For example, these string constants are all equivalent:
+
+@smallexample
+const char *s1 = "\\";
+const char *s2 = R"(\)";
+const char *s3 = R"foo(\)foo";
+@end smallexample
+
+As an extension, GCC also accepts raw string literals in C with
+@option{-std=gnu99} or later.
+
@node Alternate Keywords
@subsection Alternate Keywords
@cindex alternate keywords
[gcc r16-333] OpenMP: Restore lost Fortran testcase for 'omp allocate'
https://gcc.gnu.org/g:08ce1b9f6707e00089c4d77d2bb82963d531bb1d
commit r16-333-g08ce1b9f6707e00089c4d77d2bb82963d531bb1d
Author: Tobias Burnus
Date: Thu May 1 15:39:42 2025 +
OpenMP: Restore lost Fortran testcase for 'omp allocate'
This testcase, which is present on the OG13 and OG14 branches, was
overlooked when the Fortran support for 'omp allocate' was added to
mainline (commit d4b6d147920b93297e621124a99ed01e7e310d92 from
December 2023).
libgomp/ChangeLog
* testsuite/libgomp.fortran/allocate-8a.f90: New test.
Diff:
---
libgomp/testsuite/libgomp.fortran/allocate-8a.f90 | 45 +++
1 file changed, 45 insertions(+)
diff --git a/libgomp/testsuite/libgomp.fortran/allocate-8a.f90
b/libgomp/testsuite/libgomp.fortran/allocate-8a.f90
new file mode 100644
index ..5f6c8c1e2717
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/allocate-8a.f90
@@ -0,0 +1,45 @@
+! { dg-additional-options "-fopenmp-allocators" }
+! { dg-additional-options "-fdump-tree-omplower" }
+program main
+ use iso_c_binding
+ use omp_lib
+ implicit none (type, external)
+ integer(omp_allocator_handle_kind):: alloc_h
+ integer :: i, N
+ integer(c_intptr_t) :: intptr
+ integer, allocatable :: A(:)
+ type(omp_alloctrait):: traits(1) = [omp_alloctrait(omp_atk_alignment, 128)]
+
+ N = 10
+ alloc_h = omp_init_allocator(omp_default_mem_space, 1, traits)
+
+ !$omp allocate(A) allocator(alloc_h)
+ allocate(A(N))
+ a(:) = [(i, i=1,N)]
+ if (mod (transfer (loc(a), intptr),128) /= 0) &
+stop 1
+ if (any (a /= [(i, i=1,N)])) &
+stop 2
+ deallocate(A)
+ !$omp allocate(A) allocator(alloc_h) align(512)
+ allocate(A(N))
+ block
+integer, allocatable :: B(:)
+!$omp allocators allocate(allocator(alloc_h), align(256) : B)
+allocate(B(N))
+B(:) = [(2*i, i=1,N)]
+A(:) = B
+if (mod (transfer (loc(B), intptr), 256) /= 0) &
+ stop 1
+! end of scope deallocation
+ end block
+ if (mod (transfer (loc(a), intptr),512) /= 0) &
+stop 1
+ if (any (a /= [(2*i, i=1,N)])) &
+stop 2
+ deallocate(A) ! Must deallocate here - before deallocator is destroyed
+ call omp_destroy_allocator(alloc_h)
+ ! No auto dealloc of A because it is SAVE
+end
+! { dg-final { scan-tree-dump-times "__builtin_GOMP_alloc \\(" 3 "omplower" } }
+! { dg-final { scan-tree-dump-times "__builtin_GOMP_free \\(" 3 "omplower" } }
[gcc r15-9502] Docs: Address -fivopts, -O0, and -Q confusion [PR71094]
https://gcc.gnu.org/g:d91aab4dd6814ca54c211a93fec3f072745a52c4
commit r15-9502-gd91aab4dd6814ca54c211a93fec3f072745a52c4
Author: Sandra Loosemore
Date: Tue Apr 15 18:37:37 2025 +
Docs: Address -fivopts, -O0, and -Q confusion [PR71094]
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 information in all the places users are likely to look
for it.
gcc/ChangeLog
PR tree-optimization/71094
* doc/invoke.texi (Optimize Options): Document that -fivopts is
enabled at -O1 and higher. Add blurb about -O0 causing GCC to
completely ignore most optimization options.
Diff:
---
gcc/doc/invoke.texi | 9 +
1 file changed, 9 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b99da94dca15..0b6644b03154 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -12746,6 +12746,7 @@ complexity than at @option{-O}.
-fipa-pure-const
-fipa-reference
-fipa-reference-addressable
+-fivopts
-fmerge-constants
-fmove-loop-invariants
-fmove-loop-stores
@@ -12854,6 +12855,13 @@ by @option{-O2} and also turns on the following
optimization flags:
Reduce compilation time and make debugging produce the expected
results. This is the default.
+At @option{-O0}, GCC completely disables most optimization passes;
+they are not run even if you explicitly enable them on the command
+line, or are listed by @option{-Q --help=optimizers} as being enabled by
+default. Many optimizations performed by GCC depend on code analysis
+or canonicalization passes that are enabled by @option{-O}, and it would
+not be useful to run individual optimization passes in isolation.
+
@opindex Os
@item -Os
Optimize for size. @option{-Os} enables all @option{-O2} optimizations
@@ -14306,6 +14314,7 @@ Enabled by default at @option{-O1} and higher.
@item -fivopts
Perform induction variable optimizations (strength reduction, induction
variable merging and induction variable elimination) on trees.
+Enabled by default at @option{-O1} and higher.
@opindex ftree-parallelize-loops
@item -ftree-parallelize-loops=n
[gcc r15-9472] Doc: clarify -march=pentiumpro has no MMX support [PR42683]
https://gcc.gnu.org/g:f7a2f0aa6bd28c054cecfda9d2c499a304cd4c2a
commit r15-9472-gf7a2f0aa6bd28c054cecfda9d2c499a304cd4c2a
Author: Sandra Loosemore
Date: Tue Apr 15 00:56:30 2025 +
Doc: clarify -march=pentiumpro has no MMX support [PR42683]
gcc/ChangeLog
PR target/42683
* doc/invoke.texi (x86 Options): Clarify that -march=pentiumpro
doesn't include MMX.
Diff:
---
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 67155eeeda7d..1f7657b72b7f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -34872,7 +34872,7 @@ Intel Lakemont MCU, based on Intel Pentium CPU.
Intel Pentium MMX CPU, based on Pentium core with MMX instruction set support.
@item pentiumpro
-Intel Pentium Pro CPU@.
+Intel Pentium Pro CPU with no MMX support.
@item i686
When used with @option{-march}, the Pentium Pro
[gcc r15-9399] Doc: Explicitly document extensions implied by -march=x86_64 [PR97585]
https://gcc.gnu.org/g:342f1663bfb0e662f12c035c922d72166be9dd22 commit r15-9399-g342f1663bfb0e662f12c035c922d72166be9dd22 Author: Sandra Loosemore Date: Sat Apr 12 04:03:11 2025 + Doc: Explicitly document extensions implied by -march=x86_64 [PR97585] 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. Diff: --- gcc/doc/invoke.texi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 4be80a7f7f9a..fbaa29f49258 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -34838,7 +34838,8 @@ produces code optimized for the local machine under the constraints of the selected instruction set. @item x86-64 -A generic CPU with 64-bit extensions. +A generic CPU with 64-bit extensions, MMX, SSE, SSE2, and FXSR instruction set +support. @item x86-64-v2 @itemx x86-64-v3
[gcc r15-7781] Fortran: Tidy subheadings in Fortran documentation [PR47928]
https://gcc.gnu.org/g:d8f5e1b0ba01ac65dbae98daa065109f18b87751
commit r15-7781-gd8f5e1b0ba01ac65dbae98daa065109f18b87751
Author: Sandra Loosemore
Date: Tue Feb 25 01:03:52 2025 +
Fortran: Tidy subheadings in Fortran documentation [PR47928]
This is a preparatory patch for the main documentation changes requested
in the issue.
gcc/fortran/ChangeLog
PR fortran/47928
* gfortran.texi: Consistently use "@emph{Notes}:" instead of
other spellings.
* intrinsic.texi: Likewise. Also fix an inconsistent capitalization
and remove a redundant "Standard" entry.
Diff:
---
gcc/fortran/gfortran.texi | 57 +++---
gcc/fortran/intrinsic.texi | 40
2 files changed, 48 insertions(+), 49 deletions(-)
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index ba3c3771c43c..b45ea484f457 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -4173,7 +4173,7 @@ The references make up a single linked list of reference
operations. The
the chain. Component and array refs can be arbitrarily mixed as long as they
comply to the Fortran standard.
-@emph{NOTES}
+@emph{Notes}:
The member @code{STATIC_ARRAY_TYPE} is used only when the @code{TYPE} is
@code{CAF_REF_STATIC_ARRAY}. The member gives the type of the data referenced.
Because no array descriptor is available for a descriptorless array and
@@ -4256,7 +4256,7 @@ arguments passed to the program or @code{NULL}.
command-line arguments or @code{NULL}.
@end multitable
-@item @emph{NOTES}
+@item @emph{Notes}:
The function is modelled after the initialization function of the Message
Passing Interface (MPI) specification. Due to the way coarray registration
works, it might not be the first call to the library. If the main program is
@@ -4278,7 +4278,7 @@ been compiled with the @option{-fcoarray=lib} option.
@item @emph{Syntax}:
@code{void _gfortran_caf_finish (void)}
-@item @emph{NOTES}
+@item @emph{Notes}:
For non-Fortran programs, it is recommended to call the function at the end
of the main program. To ensure that the shutdown is also performed for
programs where this function is not explicitly invoked, for instance
@@ -4305,7 +4305,7 @@ This function returns the current image number, which is
a positive number.
in TS18508. Shall be a nonnegative number.
@end multitable
-@item @emph{NOTES}
+@item @emph{Notes}:
If the Fortran intrinsic @code{this_image} is invoked without an argument,
which
is the only permitted form in Fortran 2008, GCC passes @code{0} as
first argument.
@@ -4334,7 +4334,7 @@ Shall be positive.
@item @var{failed} @tab shall be -1, 0, or 1
@end multitable
-@item @emph{NOTES}
+@item @emph{Notes}:
This function follows TS18508. If the num_image intrinsic has no arguments,
then the compiler passes @code{distance=0} and @code{failed=-1} to the
function.
@end table
@@ -4362,7 +4362,7 @@ has executed a @code{FAIL IMAGE} statement.
performed.
@end multitable
-@item @emph{NOTES}
+@item @emph{Notes}:
This function follows TS18508. Because team-functionality is not yet
implemented a null pointer is passed for the @var{team} argument at the moment.
@end table
@@ -4390,7 +4390,7 @@ performed.
@item @var{image} @tab optional; the kind of the resulting integer array.
@end multitable
-@item @emph{NOTES}
+@item @emph{Notes}:
This function follows TS18508. Because team-functionality is not yet
implemented a null pointer is passed for the @var{team} argument at the moment.
@end table
@@ -4418,7 +4418,7 @@ performed.
@item @var{image} @tab optional; the kind of the resulting integer array.
@end multitable
-@item @emph{NOTES}
+@item @emph{Notes}:
This function follows TS18508. Because team-functionality is not yet
implemented a null pointer is passed for the @var{team} argument at the moment.
@end table
@@ -4478,7 +4478,7 @@ an error message; may be @code{NULL}
@item @var{errmsg_len} @tab the buffer size of errmsg.
@end multitable
-@item @emph{NOTES}
+@item @emph{Notes}:
Nonallocatable coarrays have to be registered prior use from remote images.
In order to guarantee this, they have to be registered before the main
program. This can be achieved by creating constructor functions. That is what
@@ -4529,7 +4529,7 @@ to an error message; may be NULL
@item @var{errmsg_len} @tab the buffer size of errmsg.
@end multitable
-@item @emph{NOTES}
+@item @emph{Notes}:
For nonallocatable coarrays this function is never called. If a cleanup is
required, it has to be handled via the finish, stop and error stop functions,
and via destructors.
@@ -4564,7 +4564,7 @@ size_t *opt_dst_charlen)}. GFortran ensures that
functions provided to
@code{_gfortran_caf_register_accessor} adhere to this interface.
@end multitable
-@item @emph{NOTES}
+@item @emph{Notes}:
This function is required to have a nearly constant runtime complex
[gcc r15-7782] Fortran: Whitespace cleanup in documentation [PR47928]
https://gcc.gnu.org/g:1f458cfc17775903ab85bda127d0454014f70906
commit r15-7782-g1f458cfc17775903ab85bda127d0454014f70906
Author: Sandra Loosemore
Date: Tue Feb 25 18:40:06 2025 +
Fortran: Whitespace cleanup in documentation [PR47928]
This is a preparatory patch for the main changes requested in the issue.
gcc/fortran/ChangeLog
PR fortran/47928
* intrinsic.texi: Put a blank line between "@item @emph{}"
subheadings, but not more than one.
Diff:
---
gcc/fortran/intrinsic.texi | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 21da3ff34fa1..c965aef9d426 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -2355,7 +2355,6 @@ coindexed @var{ATOM}, if the remote image has stopped, it
is assigned the value
of @code{ISO_FORTRAN_ENV}'s @code{STAT_STOPPED_IMAGE} and if the remote image
has failed, the value @code{STAT_FAILED_IMAGE}.
-
@item @emph{Standard}:
Fortran 2008 and later; with @var{STAT}, TS 18508 or later
@@ -4587,7 +4586,6 @@ and may not start with @code{0.0}. For @code{CPU_TIME},
the absolute
value is meaningless; only differences between subsequent calls to
this subroutine, as shown in the example below, should be used.
-
@item @emph{Standard}:
Fortran 95 and later
@@ -4644,7 +4642,6 @@ shifted out one end of each rank one section are shifted
back in the other end.
@item @emph{Standard}:
Fortran 90 and later
-
@item @emph{Class}:
Transformational function
@@ -5791,7 +5788,6 @@ dependent. In particular, on POSIX-compliant systems, the
@code{SIGINT} and
such, if the parent process is terminated, the child process might not be
terminated alongside.
-
@item @emph{See also}:
@ref{SYSTEM}
@end table
@@ -5967,7 +5963,6 @@ unlimited polymorphic.
The return value is a scalar of type default logical. It is true if and only if
the dynamic type of A is an extension type of the dynamic type of MOLD.
-
@item @emph{See also}:
@ref{SAME_TYPE_AS}
@end table
@@ -6193,7 +6188,6 @@ for that row is zero.
@item @emph{Standard}:
Fortran 2008 and later
-
@item @emph{Class}:
Transformational function
@@ -7248,7 +7242,6 @@ Function
The return value of @code{GETGID} is an @code{INTEGER} of the default
kind.
-
@item @emph{Example}:
See @code{GETPID} for an example.
@@ -7327,7 +7320,6 @@ Function
The return value of @code{GETPID} is an @code{INTEGER} of the default
kind.
-
@item @emph{Example}:
@smallexample
program info
@@ -7367,7 +7359,6 @@ Function
The return value of @code{GETUID} is an @code{INTEGER} of the default
kind.
-
@item @emph{Example}:
See @code{GETPID} for an example.
@@ -8271,7 +8262,6 @@ Inquiry function.
the corank of @var{COARRAY}.
@end multitable
-
@item @emph{Return value}:
Scalar default integer with the value of the image index that corresponds
to the cosubscripts. For invalid cosubscripts the result is zero.
@@ -8838,6 +8828,7 @@ PROGRAM test_isatty
END DO
END PROGRAM
@end smallexample
+
@item @emph{See also}:
@ref{TTYNAM}
@end table
@@ -8965,6 +8956,7 @@ The return value is of the same type as @var{I}.
@item @emph{Description}:
@code{ISNAN} tests whether a floating-point value is an IEEE
Not-a-Number (NaN).
+
@item @emph{Standard}:
GNU extension
@@ -9034,7 +9026,6 @@ and the kind shall be the default integer kind.
@item @emph{Return value}:
Does not return anything.
-
@item @emph{Example}:
@smallexample
program test_itime
@@ -9147,6 +9138,7 @@ end program test_kind
@item @emph{Description}:
Returns the lower bounds of an array, or a single lower bound
along the @var{DIM} dimension.
+
@item @emph{Standard}:
Fortran 90 and later, with @var{KIND} argument Fortran 2003 and later
@@ -9190,6 +9182,7 @@ dimension, the lower bound is taken to be 1.
@item @emph{Description}:
Returns the lower bounds of a coarray, or a single lower cobound
along the @var{DIM} codimension.
+
@item @emph{Standard}:
Fortran 2008 and later
@@ -9298,14 +9291,12 @@ expression indicating the kind parameter of the result.
The return value is of type @code{INTEGER} and of kind @var{KIND}. If
@var{KIND} is absent, the return value is of default integer kind.
-
@item @emph{Specific names}:
@multitable @columnfractions .20 .23 .20 .33
@headitem Name @tab Argument @tab Return type
@tab Standard
@item @code{LEN(STRING)} @tab @code{CHARACTER} @tab @code{INTEGER}@tab
Fortran 77 and later
@end multitable
-
@item @emph{See also}:
@ref{LEN_TRIM}, @*
@ref{ADJUSTL}, @*
@@ -11387,7 +11378,6 @@ Returns the number of images.
Fortran 2008 and later. With @var{DISTANCE} or @var{FAILED} argument,
Technical Specification (TS) 18508 or later
-
@item @emph{Class}:
Transformational function
@@ -11747,6 +11737,7 @@ program test_population
print *, popcnt(huge(0_8)), poppar(huge(0_8))
en
[gcc r15-7785] Fortran: Small fixes in intrinsic.texi.
https://gcc.gnu.org/g:43a9022aa0fa2fbe66bebd51e6e73759501c04cb
commit r15-7785-g43a9022aa0fa2fbe66bebd51e6e73759501c04cb
Author: Sandra Loosemore
Date: Sun Mar 2 01:43:26 2025 +
Fortran: Small fixes in intrinsic.texi.
gcc/fortran/ChangeLog
* intrinsic.texi: Fix inconsistent capitalization of argument
names and other minor copy-editing.
Diff:
---
gcc/fortran/intrinsic.texi | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 4e6d2faea31c..8c160e58b00a 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -1116,8 +1116,8 @@ end program test_allocated
@end smallexample
@item @emph{Standard}:
-Fortran 90 and later. Note, the @code{SCALAR=} keyword and allocatable
-scalar entities are available in Fortran 2003 and later.
+Fortran 90 and later; for the @code{SCALAR=} keyword and allocatable
+scalar entities, Fortran 2003 and later.
@end table
@@ -2072,7 +2072,7 @@ Fortran 2008 and later; with @var{STAT}, TS 18508 or later
@table @asis
@item @emph{Synopsis}:
-@code{CALL ATOMIC_FETCH_ADD (ATOM, VALUE, old [, STAT])}
+@code{CALL ATOMIC_FETCH_ADD (ATOM, VALUE, OLD [, STAT])}
@item @emph{Description}:
@code{ATOMIC_FETCH_ADD(ATOM, VALUE, OLD)} atomically stores the value of
@@ -3075,24 +3075,24 @@ for @code{UNSIGNED} (@pxref{Unsigned integers})
@table @asis
@item @emph{Synopsis}:
-@code{RESULT = C_ASSOCIATED(c_ptr_1[, c_ptr_2])}
+@code{RESULT = C_ASSOCIATED(CPTR1[, CPTR2])}
@item @emph{Description}:
-@code{C_ASSOCIATED(c_ptr_1[, c_ptr_2])} determines the status of the C pointer
-@var{c_ptr_1} or if @var{c_ptr_1} is associated with the target @var{c_ptr_2}.
+@code{C_ASSOCIATED(CPTR1[, CPTR2])} determines the status of the C pointer
+@var{CPTR1} or if @var{CPTR1} is associated with the target @var{CPTR2}.
@item @emph{Class}:
Inquiry function
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
-@item @var{c_ptr_1} @tab Scalar of the type @code{C_PTR} or @code{C_FUNPTR}.
-@item @var{c_ptr_2} @tab (Optional) Scalar of the same type as @var{c_ptr_1}.
+@item @var{CPTR1} @tab Scalar of the type @code{C_PTR} or @code{C_FUNPTR}.
+@item @var{CPTR2} @tab (Optional) Scalar of the same type as @var{CPTR1}.
@end multitable
@item @emph{Return value}:
The return value is of type @code{LOGICAL}; it is @code{.false.} if either
-@var{c_ptr_1} is a C NULL pointer or if @var{c_ptr1} and @var{c_ptr_2}
+@var{CPTR1} is a C NULL pointer or if @var{CPTR1} and @var{CPTR2}
point to different addresses.
@item @emph{Example}:
@@ -3178,7 +3178,7 @@ Fortran 2003 and later
@table @asis
@item @emph{Synopsis}:
-@code{CALL C_F_PROCPOINTER(cptr, fptr)}
+@code{CALL C_F_PROCPOINTER(CPTR, FPTR)}
@item @emph{Description}:
@code{C_F_PROCPOINTER(CPTR, FPTR)} Assign the target of the C function pointer
@@ -3236,17 +3236,17 @@ Fortran 2003 and later
@table @asis
@item @emph{Synopsis}:
-@code{RESULT = C_FUNLOC(x)}
+@code{RESULT = C_FUNLOC(X)}
@item @emph{Description}:
-@code{C_FUNLOC(x)} determines the C address of the argument.
+@code{C_FUNLOC(X)} determines the C address of the argument.
@item @emph{Class}:
Inquiry function
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
-@item @var{x} @tab Interoperable function or pointer to such function.
+@item @var{X} @tab Interoperable function or pointer to such function.
@end multitable
@item @emph{Return value}:
[gcc r15-7904] inline-asm: Clarify documentation of operand syntax [PR67301]
https://gcc.gnu.org/g:f0ff7539626e25341c1b450b537e69f86e0bd1f6
commit r15-7904-gf0ff7539626e25341c1b450b537e69f86e0bd1f6
Author: Sandra Loosemore
Date: Sat Mar 8 05:23:55 2025 +
inline-asm: Clarify documentation of operand syntax [PR67301]
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.
Diff:
---
gcc/doc/extend.texi | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 13cbc72ed24c..5e40cf8387bb 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -11473,10 +11473,11 @@ Operands are separated by commas. Each operand has
this format:
@table @var
@item asmSymbolicName
-Specifies a symbolic name for the operand.
-Reference the name in the assembler template
-by enclosing it in square brackets
-(i.e.@: @samp{%[Value]}). The scope of the name is the @code{asm} statement
+Specifies an optional symbolic name for the operand. The literal square
+brackets @samp{[]} around the @var{asmSymbolicName} are required both
+in the operand specification and references to the operand in the assembler
+template, i.e.@: @samp{%[Value]}.
+The scope of the name is the @code{asm} statement
that contains the definition. Any valid C variable name is acceptable,
including names already defined in the surrounding code. No two operands
within the same @code{asm} statement can use the same symbolic name.
@@ -11762,10 +11763,11 @@ Operands are separated by commas. Each operand has
this format:
@table @var
@item asmSymbolicName
-Specifies a symbolic name for the operand.
-Reference the name in the assembler template
-by enclosing it in square brackets
-(i.e.@: @samp{%[Value]}). The scope of the name is the @code{asm} statement
+Specifies an optional symbolic name for the operand. The literal square
+brackets @samp{[]} around the @var{asmSymbolicName} are required both
+in the operand specification and references to the operand in the assembler
+template, i.e.@: @samp{%[Value]}.
+The scope of the name is the @code{asm} statement
that contains the definition. Any valid C variable name is acceptable,
including names already defined in the surrounding code. No two operands
within the same @code{asm} statement can use the same symbolic name.
[gcc r15-7877] Documentation: Improve -Wstringop-overflow documentation [PR 113515]
https://gcc.gnu.org/g:888e70b322622528dac17f04738ffa232c6fb82d
commit r15-7877-g888e70b322622528dac17f04738ffa232c6fb82d
Author: Sandra Loosemore
Date: Fri Mar 7 04:35:34 2025 +
Documentation: Improve -Wstringop-overflow documentation [PR 113515]
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
documentation.
Diff:
---
gcc/doc/invoke.texi | 35 +--
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 304de88db07c..fd1ce063a376 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -8229,20 +8229,28 @@ void f (char *d)
@item -Wno-stringop-overflow
@item -Wstringop-overflow
@itemx -Wstringop-overflow=@var{type}
-Warn for calls to string manipulation functions such as @code{memcpy} and
-@code{strcpy} that are determined to overflow the destination buffer. The
+Warn for code that can be statically determined to cause buffer overflows or
+memory overruns, such as calls to @code{memcpy} and
+@code{strcpy} that overflow the destination buffer. The
optional argument is one greater than the type of Object Size Checking to
perform to determine the size of the destination. @xref{Object Size Checking}.
-The argument is meaningful only for functions that operate on character arrays
-but not for raw memory functions like @code{memcpy} which always make use
-of Object Size type-0. The option also warns for calls that specify a size
+The argument is meaningful only for string functions
+that operate on character arrays; raw memory functions like @code{memcpy}
+always use type-zero Object Size Checking.
+
+The option also warns for calls that specify a size
in excess of the largest possible object or at most @code{SIZE_MAX / 2} bytes.
+
The option produces the best results with optimization enabled but can detect
a small subset of simple buffer overflows even without optimization in
calls to the GCC built-in functions like @code{__builtin_memcpy} that
correspond to the standard functions. In any case, the option warns about
just a subset of buffer overflows detected by the corresponding overflow
-checking built-ins. For example, the option issues a warning for
+checking built-ins, such as @code{__builtin___memcpy_chk}, which can perform
+run-time checking if the access cannot be identified as safe
+at compile time.
+
+For example, the option issues a warning for
the @code{strcpy} call below because it copies at least 5 characters
(the string @code{"blue"} including the terminating NUL) into the buffer
of size 4.
@@ -8264,6 +8272,21 @@ const char* f (enum Color clr)
@}
@end smallexample
+The effect of this option is not limited to string or memory
+manipulation functions. In this example, a warning is diagnosed
+because a 1-element array is passed to a function requiring at least a
+4-element array argument:
+
+@smallexample
+void f (int[static 4]);
+
+void g (void)
+@{
+ int *p = (int *) malloc (1 * sizeof(int));
+ f (p); // warning here
+@}
+@end smallexample
+
Option @option{-Wstringop-overflow=2} is enabled by default.
@table @gcctabopt
[gcc r15-7911] OpenMP: Integrate dynamic selectors with dispatch argument handling [PR118457]
https://gcc.gnu.org/g:44b1d52e2f4db57849ca54b63c52a687294b1793
commit r15-7911-g44b1d52e2f4db57849ca54b63c52a687294b1793
Author: Sandra Loosemore
Date: Sun Mar 9 01:50:19 2025 +
OpenMP: Integrate dynamic selectors with dispatch argument handling
[PR118457]
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_call_expr and invoking it from the new variant
substitution code instead. It's handled as a tree -> tree transformation
rather than tree -> gimple because eventually this code may end up being
invoked from the front ends instead of the gimplifier (see PR115076).
gcc/ChangeLog
PR middle-end/118457
* gimplify.cc (modify_call_for_omp_dispatch): New, containing
code split from gimplify_call_expr and modified to emit tree
instead of gimple. Remove the error for falling through to a call
to the base function.
(expand_variant_call_expr): New, split from
gimplify_variant_call_expr.
Call modify_call_for_omp_dispatch on calls to
variants in a dispatch construct context.
(gimplify_variant_call_expr): Make it call expand_variant_call_expr
to do the actual work.
(gimplify_call_expr): Remove sorry for calls involving both
dynamic/late selectors and adjust_args/append_args, and adjust
for new interface. Move adjust_args/append_args code to
modify_call_for_omp_dispatch.
(gimplify_omp_dispatch): Add some comments.
gcc/testsuite/ChangeLog
PR middle-end/118457
* c-c++-common/gomp/adjust-args-6.c: Remove xfails and adjust
expected output.
* c-c++-common/gomp/append-args-5.c: Adjust expected output.
* c-c++-common/gomp/append-args-dynamic.c: New.
* c-c++-common/gomp/dispatch-11.c: Adjust expected output.
* gfortran.dg/gomp/dispatch-11.f90: Likewise.
Diff:
---
gcc/gimplify.cc| 811 ++---
gcc/testsuite/c-c++-common/gomp/adjust-args-6.c| 13 +-
gcc/testsuite/c-c++-common/gomp/append-args-5.c| 19 +-
.../c-c++-common/gomp/append-args-dynamic.c| 94 +++
gcc/testsuite/c-c++-common/gomp/dispatch-11.c | 22 +-
gcc/testsuite/gfortran.dg/gomp/dispatch-11.f90 | 5 -
6 files changed, 499 insertions(+), 465 deletions(-)
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 6869f53ce701..5bdd970f570f 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3872,29 +3872,331 @@ find_supercontext (void)
return NULL_TREE;
}
+/* OpenMP: Handle the append_args and adjust_args clauses of
+ declare_variant for EXPR, which is a CALL_EXPR whose CALL_EXPR_FN
+ is the variant, within a dispatch construct with clauses DISPATCH_CLAUSES
+ and location DISPATCH_LOC.
+
+ 'append_args' causes interop objects are added after the last regular
+ (nonhidden, nonvariadic) arguments of the variant function.
+ 'adjust_args' with need_device_{addr,ptr} converts the pointer target of
+ a pointer from a host to a device address. This uses either the default
+ device or the passed device number, which then sets the default device
+ address. */
+static tree
+modify_call_for_omp_dispatch (tree expr, tree dispatch_clauses,
+ location_t dispatch_loc)
+{
+ tree fndecl = get_callee_fndecl (expr);
+
+ /* Skip processing if we don't get the expected call form. */
+ if (!fndecl)
+return expr;
+
+ int nargs = call_expr_nargs (expr);
+ tree dispatch_device_num = NULL_TREE;
+ tree dispatch_device_num_init = NULL_TREE;
+ tree dispatch_interop = NULL_TREE;
+ tree dispatch_append_args = NULL_TREE;
+ int nfirst_args = 0;
+ tree dispatch_adjust_args_list
+= lookup_attribute ("omp declare variant variant args",
+ DECL_ATTRIBUTES (fndecl));
+
+ if (dispatch_adjust_args_list)
+{
+ dispatch_adjust_args_list = TREE_VALUE (dispatch_adjust_args_list);
+ dispatch_append_args = TREE_CHAIN (dispatch_adjust_args_list);
+ if (TREE_PURPOSE (dispatch_adjust_args_list) == NULL_TREE
+ && TREE_VALUE (dispatch_adjust_args_list) == NULL_TREE)
+ dispatch_adjust_args_list = NULL_TREE;
+}
+ if (dispatch_append_args)
+{
+ nfirst_args = tree_to_shwi (TREE_PURPOSE (dispatch_append_args));
+ dispatch_append_args = TREE_VALUE (dispatch_append_args);
+}
+ dispatch_device_num = omp_find_clause (dispatch_clauses, OMP_CLAUSE_DEVICE);
+ if (dispatch_device_num)
+dispatch_device_num = OMP_CLAUSE_DEVICE_ID (dispatch_device_num);
+ dispatch_interop = omp_find_clause (dispatch_clauses, OMP_CLAUSE_INTEROP);
[gcc r15-7899] Sanitizer: Mention -g option in documentation [PR56682]
https://gcc.gnu.org/g:313edeeeb607fe32da5633cfb6f91977add446f6
commit r15-7899-g313edeeeb607fe32da5633cfb6f91977add446f6
Author: Sandra Loosemore
Date: Fri Mar 7 22:50:19 2025 +
Sanitizer: Mention -g option in documentation [PR56682]
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.
Diff:
---
gcc/doc/invoke.texi | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index c61f35140702..e01d64c5229f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -17861,12 +17861,16 @@ The option cannot be combined with
@option{-fsanitize=thread} or
(only with @code{-mlam=u48} or @code{-mlam=u57} options) and AArch64,
in both cases only in ABIs with 64-bit pointers.
+When compiling with @option{-fsanitize=address}, you should also also
+use @option{-g} to produce more meaningful output.
To get more accurate stack traces, it is possible to use options such as
@option{-O0}, @option{-O1}, or @option{-Og} (which, for instance, prevent
most function inlining), @option{-fno-optimize-sibling-calls} (which prevents
optimizing sibling and tail recursive calls; this option is implicit for
@option{-O0}, @option{-O1}, or @option{-Og}), or @option{-fno-ipa-icf} (which
-disables Identical Code Folding for functions). Since multiple runs of the
+disables Identical Code Folding for functions).
+Using @option{-fno-omit-frame-pointer} also improves stack traces.
+Since multiple runs of the
program may yield backtraces with different addresses due to ASLR (Address
Space Layout Randomization), it may be desirable to turn ASLR off. On Linux,
this can be achieved with @samp{setarch `uname -m` -R ./prog}.
@@ -17972,6 +17976,9 @@ supported options.
The option cannot be combined with @option{-fsanitize=address},
@option{-fsanitize=leak}.
+When compiling with @option{-fsanitize=thread}, you should also use
+@option{-g} to produce more meaningful output.
+
Note that sanitized atomic builtins cannot throw exceptions when
operating on invalid memory addresses with non-call exceptions
(@option{-fnon-call-exceptions}).
[gcc r15-7892] x86: Improve documentation for -msse4 [PR116708]
https://gcc.gnu.org/g:c781da2c10641a651019f8fe77f57ccdbc49f024
commit r15-7892-gc781da2c10641a651019f8fe77f57ccdbc49f024
Author: Sandra Loosemore
Date: Fri Mar 7 17:08:30 2025 +
x86: Improve documentation for -msse4 [PR116708]
gcc/ChangeLog
PR target/116708
* doc/invoke.texi (x86 Options): Clarify how -msse4 and -mno-sse4
interact with other SSE options.
Diff:
---
gcc/doc/invoke.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d95580220731..c61f35140702 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -35924,6 +35924,11 @@ These extensions are also available as built-in
functions: see
@ref{x86 Built-in Functions}, for details of the functions enabled and
disabled by these switches.
+Note that @option{-msse4} enables both SSE4.1 and SSE4.2 support,
+while @option{-mno-sse4} turns off those features; neither form of the
+option affects SSE4A support, controlled separately by
+@option{-msse4a}.
+
To generate SSE/SSE2 instructions automatically from floating-point
code (as opposed to 387 instructions), see @option{-mfpmath=sse}.
[gcc r15-7907] inline-asm: Improve documentation of "asm constexpr".
https://gcc.gnu.org/g:dff059294511b4f42a531d0a91bf185ee1bc7b0a
commit r15-7907-gdff059294511b4f42a531d0a91bf185ee1bc7b0a
Author: Sandra Loosemore
Date: Sat Mar 8 16:25:09 2025 +
inline-asm: Improve documentation of "asm constexpr".
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 are. I've checked what the C++ parser
actually does and fixed the documentation to match, also improving it
to use correct markup and to be more explicit and less implementor-speaky.
gcc/cp/ChangeLog
* parser.cc (cp_parser_asm_definition): Make comment more explicit.
(cp_parser_asm_operand_list): Likewise. Also correct the comment
block at the top of the function to reflect reality.
gcc/ChangeLog
* doc/extend.texi (Basic Asm): Document that AssemblerInstructions
can be an asm constexpr.
(Extended Asm): Move the notes about asm constexprs for
AssemblerTemplate and Clobbers to the corresponding subsections.
Remove the notes for OutputOperands and InputOperands and reword
misleading descriptions of the list item syntax. Note that
constraint strings can be asm constexprs.
(Asm constexprs): Use "title case" for subsection name. Be
explicit about what parts of the asm syntax this applies to and
that the parentheses are required. Correct markup and terminology.
Diff:
---
gcc/cp/parser.cc| 8 +++
gcc/doc/extend.texi | 60 +
2 files changed, 41 insertions(+), 27 deletions(-)
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index c2b81fc281a8..94e8e11e3989 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -23420,7 +23420,7 @@ cp_parser_asm_definition (cp_parser* parser)
/* Look for the opening `('. */
if (!cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN))
return;
- /* Look for the string. */
+ /* Look for the asm template string. */
tree string = cp_parser_asm_string_expression (parser);
if (string == error_mark_node)
{
@@ -30310,12 +30310,12 @@ cp_parser_asm_specification_opt (cp_parser* parser)
asm-operand:
asm-string-expr ( expression )
- [ asm-string-expr ] asm-string-expr ( expression )
+ [ identifier ] asm-string-expr ( expression )
Returns a TREE_LIST representing the operands. The TREE_VALUE of
each node is the expression. The TREE_PURPOSE is itself a
TREE_LIST whose TREE_PURPOSE is a STRING_CST for the bracketed
- string-literal (or NULL_TREE if not present) and whose TREE_VALUE
+ identifier (or NULL_TREE if not present) and whose TREE_VALUE
is a STRING_CST for the string literal before the parenthesis. Returns
ERROR_MARK_NODE if any of the operands are invalid. */
@@ -30343,7 +30343,7 @@ cp_parser_asm_operand_list (cp_parser* parser)
}
else
name = NULL_TREE;
- /* Look for the string. */
+ /* Look for the constraint string. */
tree string_literal = cp_parser_asm_string_expression (parser);
/* Look for the `('. */
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 5e40cf8387bb..6797efc0bb40 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10984,10 +10984,14 @@ of an asm}).
@table @var
@item AssemblerInstructions
-This is a literal string that specifies the assembler code. The string can
-contain any instructions recognized by the assembler, including directives.
-GCC does not parse the assembler instructions themselves and
-does not know what they mean or even whether they are valid assembler input.
+This is a literal string that specifies the assembler code.
+In C++ with @option{-std=gnu++11} or later, it can
+also be a constant expression inside parentheses (see @ref{Asm constexprs}).
+
+The string can contain any instructions recognized by the assembler,
+including directives. GCC does not parse the assembler instructions
+themselves and does not know what they mean or even whether they are
+valid assembler input.
You may place multiple assembler instructions together in a single @code{asm}
string, separated by the characters normally used in assembly code for the
@@ -11128,27 +11132,22 @@ perform a jump to one of the labels listed in the
@var{GotoLabels}.
@item AssemblerTemplate
This is a literal string that is the template for the assembler code. It is a
combination of fixed text and tokens that refer to the input, output,
-and goto parameters. @xref{AssemblerTemplate}. With gnu++11 or later it can
-also be a constant expression inside parens (see @ref{Asm constexprs}).
+and goto parameters. @xref{AssemblerTemplat
[gcc r15-7971] OpenMP/C: Store location in cp_parser_omp_var_list for kind=0 [PR118579]
https://gcc.gnu.org/g:f74ed83e287dbaa20e9649df6cda631ee461ecf5
commit r15-7971-gf74ed83e287dbaa20e9649df6cda631ee461ecf5
Author: Sandra Loosemore
Date: Tue Mar 11 16:36:22 2025 +
OpenMP/C: Store location in cp_parser_omp_var_list for kind=0 [PR118579]
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 OMP_CLAUSE_ERROR.
(c_parser_oacc_data_clause_deviceptr): Use the improved location
for diagnostics, and remove the FIXME.
(c_finish_omp_declare_variant): Likewise.
(c_parser_omp_threadprivate): Likewise.
gcc/testsuite/ChangeLog
PR c/118579
* c-c++-common/gomp/pr118579.c: New testcase.
Diff:
---
gcc/c/c-parser.cc | 36 --
gcc/testsuite/c-c++-common/gomp/pr118579.c | 25 +
2 files changed, 39 insertions(+), 22 deletions(-)
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 7672e06fdd0d..911e7edd4811 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -16282,8 +16282,9 @@ c_parser_oacc_wait_list (c_parser *parser, location_t
clause_loc, tree list)
decl in OMP_CLAUSE_DECL and add the node to the head of the list.
If KIND is nonzero, CLAUSE_LOC is the location of the clause.
- If KIND is zero, create a TREE_LIST with the decl in TREE_PURPOSE;
- return the list created.
+ If KIND is zero (= OMP_CLAUSE_ERROR), create a TREE_LIST with the decl
+ in TREE_PURPOSE and the location in TREE_VALUE (accessible using
+ EXPR_LOCATION); return the list created.
The optional ALLOW_DEREF argument is true if list items can use the deref
(->) operator. */
@@ -16312,6 +16313,7 @@ c_parser_omp_variable_list (c_parser *parser,
while (1)
{
tree t = NULL_TREE;
+ location_t tloc = c_parser_peek_token (parser)->location;
if (kind == OMP_CLAUSE_DEPEND || kind == OMP_CLAUSE_AFFINITY)
{
@@ -16512,7 +16514,7 @@ c_parser_omp_variable_list (c_parser *parser,
if (t == error_mark_node)
;
- else if (kind != 0)
+ else if (kind != 0) /* kind != OMP_CLAUSE_ERROR */
{
switch (kind)
{
@@ -16686,8 +16688,8 @@ c_parser_omp_variable_list (c_parser *parser,
list = u;
}
}
- else
- list = tree_cons (t, NULL_TREE, list);
+ else /* kind == OMP_CLAUSE_ERROR */
+ list = tree_cons (t, build_empty_stmt (tloc), list);
if (kind == OMP_CLAUSE_DEPEND || kind == OMP_CLAUSE_AFFINITY)
{
@@ -16847,7 +16849,6 @@ c_parser_oacc_data_clause (c_parser *parser,
pragma_omp_clause c_kind,
static tree
c_parser_oacc_data_clause_deviceptr (c_parser *parser, tree list)
{
- location_t loc = c_parser_peek_token (parser)->location;
tree vars, t;
/* Can't use OMP_CLAUSE_MAP here (that is, can't use the generic
@@ -16857,12 +16858,7 @@ c_parser_oacc_data_clause_deviceptr (c_parser *parser,
tree list)
for (t = vars; t && t; t = TREE_CHAIN (t))
{
tree v = TREE_PURPOSE (t);
-
- /* FIXME diagnostics: Ideally we should keep individual
-locations for all the variables in the var list to make the
-following errors more precise. Perhaps
-c_parser_omp_var_list_parens() should construct a list of
-locations to go along with the var list. */
+ location_t loc = EXPR_LOCATION (TREE_VALUE (t));
if (!VAR_P (v) && TREE_CODE (v) != PARM_DECL)
error_at (loc, "%qD is not a variable", v);
@@ -27031,6 +27027,7 @@ c_finish_omp_declare_variant (c_parser *parser, tree
fndecl, tree parms)
for (tree c = list; c != NULL_TREE; c = TREE_CHAIN (c))
{
tree decl = TREE_PURPOSE (c);
+ location_t arg_loc = EXPR_LOCATION (TREE_VALUE (c));
int idx;
for (arg = parms, idx = 0; arg != NULL;
arg = TREE_CHAIN (arg), idx++)
@@ -27038,14 +27035,15 @@ c_finish_omp_declare_variant (c_parser *parser, tree
fndecl, tree parms)
break;
if (arg == NULL_TREE)
{
- error_at (loc, "%qD is not a function argument",
+ error_at (arg_loc,
+ "%qD is not a function argument",
decl);
goto fail;
}
if (adjust_args_list.contains (arg))
{
- // TODO fix location
- error_at (loc, "%qD is specif
[gcc/devel/omp/gcc-14] OpenMP: Integrate dynamic selectors with dispatch argument handling [PR118457]
https://gcc.gnu.org/g:29a1c0c4bda74a786db857e409b2e960343211e7
commit 29a1c0c4bda74a786db857e409b2e960343211e7
Author: Sandra Loosemore
Date: Thu Mar 13 19:41:15 2025 +
OpenMP: Integrate dynamic selectors with dispatch argument handling
[PR118457]
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_call_expr and invoking it from the new variant
substitution code instead.
This is a backport of commit 44b1d52e2f4db57849ca54b63c52a687294b1793
from mainline, done by hand instead of cherry-picking because of
differences in the dynamic selector code between OG14 and mainline.
gcc/ChangeLog
PR middle-end/118457
* gimplify.cc (modify_call_for_omp_dispatch): New, containing
code split from gimplify_call_expr and modified to emit tree
instead of gimple. Remove the error for falling through to a call
to the base function.
(gimplify_variant_call_expr): Add omp_dispatch_p argument and
call modify_call_for_omp_dispatch if needed.
(gimplify_call_expr): Adjust call to gimplify_variant_call_expr.
Move adjust_args/append_args code to modify_call_for_omp_dispatch.
gcc/testsuite/ChangeLog
PR middle-end/118457
* c-c++-common/gomp/adjust-args-6.c: New.
* c-c++-common/gomp/append-args-5.c: Adjust expected output.
* c-c++-common/gomp/append-args-dynamic.c: New.
* c-c++-common/gomp/dispatch-11.c: Adjust expected output.
* gfortran.dg/gomp/dispatch-11.f90: Likewise.
Diff:
---
gcc/gimplify.cc| 687 ++---
gcc/testsuite/c-c++-common/gomp/adjust-args-6.c| 27 +
gcc/testsuite/c-c++-common/gomp/append-args-5.c| 19 +-
.../c-c++-common/gomp/append-args-dynamic.c| 94 +++
gcc/testsuite/c-c++-common/gomp/dispatch-11.c | 22 +-
gcc/testsuite/gfortran.dg/gomp/dispatch-11.f90 | 5 -
6 files changed, 447 insertions(+), 407 deletions(-)
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 2bcadcf10383..ea46c81364b3 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3892,6 +3892,303 @@ maybe_fold_stmt (gimple_stmt_iterator *gsi)
return fold_stmt (gsi);
}
+/* OpenMP: Handle the append_args and adjust_args clauses of
+ declare_variant for EXPR, which is a CALL_EXPR whose CALL_EXPR_FN
+ is the variant, within a dispatch construct with clauses DISPATCH_CLAUSES
+ and location DISPATCH_LOC.
+
+ 'append_args' causes interop objects are added after the last regular
+ (nonhidden, nonvariadic) arguments of the variant function.
+ 'adjust_args' with need_device_{addr,ptr} converts the pointer target of
+ a pointer from a host to a device address. This uses either the default
+ device or the passed device number, which then sets the default device
+ address. */
+static tree
+modify_call_for_omp_dispatch (tree expr, tree dispatch_clauses,
+ location_t dispatch_loc)
+{
+ tree fndecl = get_callee_fndecl (expr);
+
+ /* Skip processing if we don't get the expected call form. */
+ if (!fndecl)
+return expr;
+
+ int nargs = call_expr_nargs (expr);
+ tree dispatch_device_num = NULL_TREE;
+ tree dispatch_device_num_init = NULL_TREE;
+ tree dispatch_interop = NULL_TREE;
+ tree dispatch_append_args = NULL_TREE;
+ int nfirst_args = 0;
+ tree dispatch_adjust_args_list
+= lookup_attribute ("omp declare variant variant args",
+ DECL_ATTRIBUTES (fndecl));
+
+ if (dispatch_adjust_args_list)
+{
+ dispatch_adjust_args_list = TREE_VALUE (dispatch_adjust_args_list);
+ dispatch_append_args = TREE_CHAIN (dispatch_adjust_args_list);
+ if (TREE_PURPOSE (dispatch_adjust_args_list) == NULL_TREE
+ && TREE_VALUE (dispatch_adjust_args_list) == NULL_TREE)
+ dispatch_adjust_args_list = NULL_TREE;
+}
+ if (dispatch_append_args)
+{
+ nfirst_args = tree_to_shwi (TREE_PURPOSE (dispatch_append_args));
+ dispatch_append_args = TREE_VALUE (dispatch_append_args);
+}
+ dispatch_device_num = omp_find_clause (dispatch_clauses, OMP_CLAUSE_DEVICE);
+ if (dispatch_device_num)
+dispatch_device_num = OMP_CLAUSE_DEVICE_ID (dispatch_device_num);
+ dispatch_interop = omp_find_clause (dispatch_clauses, OMP_CLAUSE_INTEROP);
+ int nappend = 0, ninterop = 0;
+ for (tree t = dispatch_append_args; t; t = TREE_CHAIN (t))
+nappend++;
+
+ /* FIXME: error checking should be taken out of this function and
+ handled before any attempt at filtering or resolution happens.
+ Otherwise whether or not diagnostics appear is determined by
+ GCC internals, how good th
[gcc r15-8046] Doc: Remove redundant info from documentation of -ansi.
https://gcc.gnu.org/g:81203220af87714fd0f3170a2043ab5d95353eef
commit r15-8046-g81203220af87714fd0f3170a2043ab5d95353eef
Author: Sandra Loosemore
Date: Wed Mar 12 23:36:17 2025 +
Doc: Remove redundant info from documentation of -ansi.
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
* doc/extend.texi (Alternate Keywords): Clean up text and remove
discussion of "restrict", which is not a GNU extension at all.
* doc/invoke.texi (C Dialect Options): Remove detailed discussion.
Diff:
---
gcc/doc/extend.texi | 16 ++--
gcc/doc/invoke.texi | 33 -
2 files changed, 6 insertions(+), 43 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index bae3fba6b2b6..79cc7dfcff9c 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -13049,17 +13049,13 @@ is taken as the minimum size, ignoring how many
instructions GCC thinks it is.
@cindex keywords, alternate
@option{-ansi} and the various @option{-std} options disable certain
-keywords. This causes trouble when you want to use GNU C extensions, or
-a general-purpose header file that should be usable by all programs,
-including ISO C programs. The keywords @code{asm}, @code{typeof} and
+keywords that are GNU C extensions.
+Specifically, the keywords @code{asm}, @code{typeof} and
@code{inline} are not available in programs compiled with
-@option{-ansi} or @option{-std} (although @code{inline} can be used in a
-program compiled with @option{-std=c99} or a later standard). The
-ISO C99 keyword
-@code{restrict} is only available when @option{-std=gnu99} (which will
-eventually be the default) or @option{-std=c99} (or the equivalent
-@option{-std=iso9899:1999}), or an option for a later standard
-version, is used.
+@option{-ansi} or a @option{-std=} option specifying an ISO standard that
+doesn't define the keyword. This causes trouble when you want to use
+these extensions in a header file that can be included in programs that may
+be compiled with with such options.
The way to solve these problems is to put @samp{__} at the beginning and
end of each problematical keyword. For example, use @code{__asm__}
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 4fbb4cda101e..768b98dba74c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2386,39 +2386,6 @@ accepts:
In C mode, this is equivalent to @option{-std=c90}. In C++ mode, it is
equivalent to @option{-std=c++98}.
-This turns off certain features of GCC that are incompatible with ISO
-C90 (when compiling C code), or of standard C++ (when compiling C++ code),
-such as the @code{asm} and @code{typeof} keywords, and
-predefined macros such as @code{unix} and @code{vax} that identify the
-type of system you are using. It also enables the undesirable and
-rarely used ISO trigraph feature. For the C compiler,
-it disables recognition of C++ style @samp{//} comments as well as
-the @code{inline} keyword.
-
-The alternate keywords @code{__asm__}, @code{__extension__},
-@code{__inline__} and @code{__typeof__} continue to work despite
-@option{-ansi}. You would not want to use them in an ISO C program, of
-course, but it is useful to put them in header files that might be included
-in compilations done with @option{-ansi}. Alternate predefined macros
-such as @code{__unix__} and @code{__vax__} are also available, with or
-without @option{-ansi}.
-
-The @option{-ansi} option does not cause non-ISO programs to be
-rejected gratuitously. For that, @option{-Wpedantic} is required in
-addition to @option{-ansi}. @xref{Warning Options}.
-
-The macro @code{__STRICT_ANSI__} is predefined when the @option{-ansi}
-option is used. Some header files may notice this macro and refrain
-from declaring certain functions or defining certain macros that the
-ISO standard doesn't call for; this is to avoid interfering with any
-programs that might use these names for other things.
-
-Functions that are normally built in but do not have semantics
-defined by ISO C (such as @code{alloca} and @code{ffs}) are not built-in
-functions when @option{-ansi} is used. @xref{Other Builtins,,Other
-built-in functions provided by GCC}, for details of the functions
-affected.
-
@opindex std
@item -std=
Determine the language standard. @xref{Standards,,Language Standards
[gcc r15-7669] OpenMP: Silence uninitialized variable warning in C++ front end.
https://gcc.gnu.org/g:c978965b445079abbb88c22ba74de1e26e9f5b81 commit r15-7669-gc978965b445079abbb88c22ba74de1e26e9f5b81 Author: Sandra Loosemore Date: Sat Feb 22 16:54:50 2025 + OpenMP: Silence uninitialized variable warning in C++ front end. 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. Diff: --- gcc/cp/parser.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc index 0578aad1b1cf..9f619b111673 100644 --- a/gcc/cp/parser.cc +++ b/gcc/cp/parser.cc @@ -50383,7 +50383,7 @@ cp_finish_omp_declare_variant (cp_parser *parser, cp_token *pragma_tok, location_t varid_loc = make_location (caret_loc, start_loc, finish_loc); tree append_args_tree = NULL_TREE; - tree append_args_last; + tree append_args_last = NULL_TREE; vec adjust_args_list = vNULL; bool has_match = false, has_adjust_args = false; location_t adjust_args_loc = UNKNOWN_LOCATION;
[gcc r15-9044] Doc: Organize atomic memory builtins documentation [PR42270]
https://gcc.gnu.org/g:34efc890bf7df099e85b34e596dea82f3596aab2
commit r15-9044-g34efc890bf7df099e85b34e596dea82f3596aab2
Author: Sandra Loosemore
Date: Wed Mar 26 14:56:02 2025 +
Doc: Organize atomic memory builtins documentation [PR42270]
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 presented before the legacy _sync one. I also
incorporated material from the separate x86 transactional memory
section directly into the __atomic builtins documentation instead of
retaining that as a parallel section.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Atomic Memory Access): New section.
(__sync Builtins): Make it a subsection of the above.
(Atomic Memory Access): Likewise.
(x86 specific memory model extensions for transactional memory):
Delete this section, incorporating the text into the discussion
of __atomic builtins.
Diff:
---
gcc/doc/extend.texi | 371 +++-
1 file changed, 196 insertions(+), 175 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 68f9398590f4..de9c2b36ba38 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -14243,11 +14243,9 @@ a function call results in a compile-time error.
* Return Address:: Getting the return or frame address of a function.
* Stack Scrubbing:: Stack scrubbing internal interfaces.
* Vector Extensions:: Using vector instructions through built-in functions.
-* __sync Builtins:: Legacy built-in functions for atomic memory access.
-* __atomic Builtins:: Atomic built-in functions with memory model.
+* Atomic Memory Access:: __atomic and __sync builtins.
* Integer Overflow Builtins:: Built-in functions to perform arithmetics and
arithmetic overflow checking.
-* x86 specific memory model extensions for transactional memory:: x86 memory
models.
* Object Size Checking:: Built-in functions for limited buffer overflow
checking.
* New/Delete Builtins:: Built-in functions for C++ allocations and
deallocations.
@@ -16175,149 +16173,27 @@ x = foo ((v128) @{_mm_adds_epu8 (x.mm, y.mm)@});
@c but GCC does not accept it for unions of vector types (PR 88955).
@end smallexample
-@node __sync Builtins
-@section Legacy @code{__sync} Built-in Functions for Atomic Memory Access
-
-The following built-in functions
-are intended to be compatible with those described
-in the @cite{Intel Itanium Processor-specific Application Binary Interface},
-section 7.4. As such, they depart from normal GCC practice by not using
-the @samp{__builtin_} prefix and also by being overloaded so that they
-work on multiple types.
-
-The definition given in the Intel documentation allows only for the use of
-the types @code{int}, @code{long}, @code{long long} or their unsigned
-counterparts. GCC allows any scalar type that is 1, 2, 4 or 8 bytes in
-size other than the C type @code{_Bool} or the C++ type @code{bool}.
-Operations on pointer arguments are performed as if the operands were
-of the @code{uintptr_t} type. That is, they are not scaled by the size
-of the type to which the pointer points.
-
-These functions are implemented in terms of the @samp{__atomic}
-builtins (@pxref{__atomic Builtins}). They should not be used for new
-code which should use the @samp{__atomic} builtins instead.
-
-Not all operations are supported by all target processors. If a particular
-operation cannot be implemented on the target processor, a call to an
-external function is generated. The external function carries the same name
-as the built-in version, with an additional suffix
-@samp{_@var{n}} where @var{n} is the size of the data type.
-
-In most cases, these built-in functions are considered a @dfn{full barrier}.
-That is,
-no memory operand is moved across the operation, either forward or
-backward. Further, instructions are issued as necessary to prevent the
-processor from speculating loads across the operation and from queuing stores
-after the operation.
-
-All of the routines are described in the Intel documentation to take
-``an optional list of variables protected by the memory barrier''. It's
-not clear what is meant by that; it could mean that @emph{only} the
-listed variables are protected, or it could mean a list of additional
-variables to be protected. The list is ignored by GCC which treats it as
-empty. GCC interprets an empty list as meaning that all globally
-accessible variables should be protected.
-
-@defbuiltin{@var{type} __sync_fetch_and_add (@var{type} *@var{ptr}, @var{type}
@var{value}, ...)}
-@defbuiltinx{@var{type} __sync_fetch_and_sub (@var{
[gcc r15-9048] Docs: make regenerate-opt-urls
https://gcc.gnu.org/g:f7085e23148d415e8fefbcbea72cef607aa1 commit r15-9048-gf7085e23148d415e8fefbcbea72cef607aa1 Author: Sandra Loosemore Date: Sun Mar 30 22:05:51 2025 + Docs: make regenerate-opt-urls gcc/c-family/ChangeLog * c.opt.urls: Regenerate. gcc/d/ChangeLog * lang.opt.urls: Regenerate. gcc/m2/ChangeLog * lang.opt.urls: Regenerate. Diff: --- gcc/c-family/c.opt.urls | 4 ++-- gcc/d/lang.opt.urls | 2 +- gcc/m2/lang.opt.urls| 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls index fd7ffd38d538..dcd81dc28d5f 100644 --- a/gcc/c-family/c.opt.urls +++ b/gcc/c-family/c.opt.urls @@ -983,8 +983,8 @@ UrlSuffix(gcc/Warning-Options.html#index-Wzero-length-bounds) ; skipping UrlSuffix for 'ansi' due to multiple URLs: ; duplicate: 'gcc/C-Dialect-Options.html#index-ansi-1' +; duplicate: 'gcc/Library-Builtins.html#index-ansi-2' ; duplicate: 'gcc/Non-bugs.html#index-ansi-3' -; duplicate: 'gcc/Other-Builtins.html#index-ansi-2' ; duplicate: 'gcc/Standards.html#index-ansi' ; skipping UrlSuffix for 'd' due to multiple URLs: @@ -1014,7 +1014,7 @@ UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-fassume-sane-operators-new- ; skipping UrlSuffix for 'fbuiltin' due to multiple URLs: ; duplicate: 'gcc/C-Dialect-Options.html#index-fbuiltin' -; duplicate: 'gcc/Other-Builtins.html#index-fno-builtin-3' +; duplicate: 'gcc/Library-Builtins.html#index-fno-builtin-3' ; duplicate: 'gcc/Warning-Options.html#index-fno-builtin-1' ; skipping LangUrlSuffix_D for 'fbuiltin' due to multiple URLs: ; duplicate: 'gdc/Other-Builtins.html#index-fno-builtin-1' diff --git a/gcc/d/lang.opt.urls b/gcc/d/lang.opt.urls index 8fcb441a10fb..40bbca74b0ed 100644 --- a/gcc/d/lang.opt.urls +++ b/gcc/d/lang.opt.urls @@ -110,7 +110,7 @@ LangUrlSuffix_D(gdc/Runtime-Options.html#index-fbounds-check) LangUrlSuffix_Fort ; skipping UrlSuffix for 'fbuiltin' due to multiple URLs: ; duplicate: 'gcc/C-Dialect-Options.html#index-fbuiltin' -; duplicate: 'gcc/Other-Builtins.html#index-fno-builtin-3' +; duplicate: 'gcc/Library-Builtins.html#index-fno-builtin-3' ; duplicate: 'gcc/Warning-Options.html#index-fno-builtin-1' ; skipping LangUrlSuffix_D for 'fbuiltin' due to multiple URLs: ; duplicate: 'gdc/Other-Builtins.html#index-fno-builtin-1' diff --git a/gcc/m2/lang.opt.urls b/gcc/m2/lang.opt.urls index 4c3e6905c2c6..dc1dbf06371a 100644 --- a/gcc/m2/lang.opt.urls +++ b/gcc/m2/lang.opt.urls @@ -72,8 +72,8 @@ UrlSuffix(gcc/Preprocessor-Options.html#index-P) LangUrlSuffix_Fortran(gfortran/ ; skipping UrlSuffix for 'ansi' due to multiple URLs: ; duplicate: 'gcc/C-Dialect-Options.html#index-ansi-1' +; duplicate: 'gcc/Library-Builtins.html#index-ansi-2' ; duplicate: 'gcc/Non-bugs.html#index-ansi-3' -; duplicate: 'gcc/Other-Builtins.html#index-ansi-2' ; duplicate: 'gcc/Standards.html#index-ansi' ; skipping UrlSuffix for 'c' due to multiple URLs:
[gcc r15-9165] Doc: Clarify use of access attribute [PR101440]
https://gcc.gnu.org/g:4590a31f81ae18e0d887c1a56f510d22754f31ed
commit r15-9165-g4590a31f81ae18e0d887c1a56f510d22754f31ed
Author: Sandra Loosemore
Date: Thu Apr 3 02:40:59 2025 +
Doc: Clarify use of access attribute [PR101440]
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 whether the "arguments" were the arguments to the
attribute or the function, or exactly what a "positional argument"
was. I've tried to rewrite that part to straighten it out, as well as
some light copy-editing throughout.
gcc/ChangeLog
PR c/101440
* doc/extend.texi (Common Function Attributes): Clean up some
confusing language in the description of the "access" attribute.
Diff:
---
gcc/doc/extend.texi | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index d76d333576f9..4302df76c7fa 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -1728,23 +1728,24 @@ write-only accesses to objects that are never read
from. Such accesses
may be diagnosed by warnings such as @option{-Wstringop-overflow},
@option{-Wuninitialized}, @option{-Wunused}, and others.
-The @code{access} attribute specifies that a function to whose by-reference
-arguments the attribute applies accesses the referenced object according to
-@var{access-mode}. The @var{access-mode} argument is required and must be
-one of four names: @code{read_only}, @code{read_write}, @code{write_only},
-or @code{none}. The remaining two are positional arguments.
-
-The required @var{ref-index} positional argument denotes a function
-argument of pointer (or in C++, reference) type that is subject to
-the access. The same pointer argument can be referenced by at most one
-distinct @code{access} attribute.
-
-The optional @var{size-index} positional argument denotes a function
+The @code{access} attribute specifies that a pointer or reference argument
+to the function is accessed according to @var{access-mode}, which must be
+one of @code{read_only}, @code{read_write}, @code{write_only},
+or @code{none}. The semantics of these modes are described below.
+
+The argument the attribute applies to is identifed by @var{ref-index}, which
+is an integer constant representing its position in the argument list.
+Argument numbering starts from 1. You can specify multiple @code{access}
+attributes to describe the access modes of different arguments, but multiple
+@code{access} attributes applying to the same argument are not permitted.
+
+The optional @var{size-index} denotes the position of a function
argument of integer type that specifies the maximum size of the access.
The size is the number of elements of the type referenced by @var{ref-index},
or the number of bytes when the pointer type is @code{void*}. When no
@var{size-index} argument is specified, the pointer argument must be either
-null or point to a space that is suitably aligned and large for at least one
+null or point to a space that is suitably aligned and large enough
+for at least one
object of the referenced type (this implies that a past-the-end pointer is
not a valid argument). The actual size of the access may be less but it
must not be more.
@@ -1756,7 +1757,7 @@ is zero, the referenced object must be initialized. The
mode implies
a stronger guarantee than the @code{const} qualifier which, when cast away
from a pointer, does not prevent the pointed-to object from being modified.
Examples of the use of the @code{read_only} access mode is the argument to
-the @code{puts} function, or the second and third arguments to
+the @code{puts} function, or the second argument to
the @code{memcpy} function.
@smallexample
@@ -1796,12 +1797,13 @@ __attribute__ ((access (write_only, 1, 2), access
(read_write, 3)))
int fgets (char*, int, FILE*);
@end smallexample
-The access mode @code{none} specifies that the pointer to which it applies
+The access mode @code{none} specifies that the pointer argument
+to which it applies
is not used to access the referenced object at all. Unless the pointer is
-null the pointed-to object must exist and have at least the size as denoted
+null, the pointed-to object must exist and have at least the size as denoted
by the @var{size-index} argument. When the optional @var{size-index}
-argument is omitted for an argument of @code{void*} type the actual pointer
-agument is ignored. The referenced object need not be initialized.
+argument is omitted for an argument of @code{void*} type, the actual pointer
+argument is ignored. The referenced object need not be initialized.
The mode is intended to be used as a means to help validate
[gcc r15-9185] Doc: Clean up musttail attribute docs some more
https://gcc.gnu.org/g:26e9139691ac73f53fad64960a0ea48830adfa52
commit r15-9185-g26e9139691ac73f53fad64960a0ea48830adfa52
Author: Sandra Loosemore
Date: Thu Apr 3 05:02:34 2025 +
Doc: Clean up musttail attribute docs some more
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 the code.
In addition, the entire section on musttail was in need of copy-editing
to put it in the present tense, avoid reference to "the user", etc. I've
attempted to clean it up here.
gcc/ChangeLog
* doc/extend.texi (Statement Attributes): Copy-edit the musttail
attribute documentation and correct the comment in the last
example.
Diff:
---
gcc/doc/extend.texi | 46 +++---
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 4302df76c7fa..16ad83fc510c 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9314,7 +9314,7 @@ The @code{gnu::musttail} or @code{clang::musttail}
standard attribute
or @code{musttail} GNU attribute can be applied to a @code{return} statement
with a return-value expression that is a function call. It asserts that the
call must be a tail call that does not allocate extra stack space, so it is
-safe to use tail recursion to implement long running loops.
+safe to use tail recursion to implement long-running loops.
@smallexample
[[gnu::musttail]] return foo();
@@ -9324,11 +9324,11 @@ safe to use tail recursion to implement long running
loops.
__attribute__((musttail)) return bar();
@end smallexample
-If the compiler cannot generate a @code{musttail} tail call it will report
-an error. On some targets tail calls may never be supported.
-The user asserts for @code{musttail} tail calls that lifetime of automatic
+If the compiler cannot generate a @code{musttail} tail call it reports
+an error. On some targets, tail calls may not be supported at all.
+The @code{musttail} attribute asserts that the lifetime of automatic
variables, function parameters and temporaries (unless they have non-trivial
-destruction) can end before the actual call instruction and that any access
+destruction) can end before the actual call instruction, and that any access
to those from inside of the called function results is considered undefined
behavior. Enabling @option{-O1} or @option{-O2} can improve the success of
tail calls.
@@ -9344,9 +9344,9 @@ baz (int *x)
if (*x == 1)
@{
int a = 42;
- /* The call will be tail called (would not be without the
- attribute), dereferencing the pointer in the callee is
- undefined behavior and there will be a warning emitted
+ /* The call is a tail call (would not be without the
+ attribute). Dereferencing the pointer in the callee is
+ undefined behavior, and there is a warning emitted
for this by default (@option{-Wmusttail-local-addr}). */
[[gnu::musttail]] return foo (&a);
@}
@@ -9354,9 +9354,9 @@ baz (int *x)
@{
int a = 42;
bar (&a);
- /* The call will be tail called (would not be without the
- attribute), if bar stores the pointer anywhere, dereferencing
- it in foo will be undefined behavior and there will be a warning
+ /* The call is a tail call (would not be without the
+ attribute). If bar stores the pointer anywhere, dereferencing
+ it in foo is undefined behavior. There is a warning
emitted for this with @option{-Wextra}, which implies
@option{-Wmaybe-musttail-local-addr}. */
[[gnu::musttail]] return foo (nullptr);
@@ -9365,8 +9365,8 @@ baz (int *x)
@{
S s;
/* The s variable requires non-trivial destruction which ought
- to be performed after the foo call returns, so this will
- be rejected. */
+ to be performed after the foo call returns, so this is
+ rejected. */
[[gnu::musttail]] return foo (&s.s);
@}
@}
@@ -9374,9 +9374,9 @@ baz (int *x)
To avoid the @option{-Wmaybe-musttail-local-addr} warning in the
above @code{*x == 2} case and similar code, consider defining the
-maybe escaped variables in a separate scope which will end before the
-return statement if possible to make it clear that the variable is not
-live during the call. So
+maybe-escaped variables in a separate scope that ends before the
+return statement, if that is possible, to make it clear that the
+variable is not live during the call. So:
@smallexample
else if (*x == 2)
@@ -9385,17 +9385,17 @@ live during the call. So
int a = 42;
bar (&a);
@}
- /* The call will be tail called
[gcc r15-9046] Doc: Clean up New/Delete Builtins manual section
https://gcc.gnu.org/g:37f35ebc7c50afdc9aeb4774b7d0ca7e7f32bbf1
commit r15-9046-g37f35ebc7c50afdc9aeb4774b7d0ca7e7f32bbf1
Author: Sandra Loosemore
Date: Wed Mar 26 18:25:51 2025 +
Doc: Clean up New/Delete Builtins manual section
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 Builtins): Cleanup up the text and
explicitly list the builtins being documented.
Diff:
---
gcc/doc/extend.texi | 41 +
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index f0bbff6dd042..a49b1cdd1e35 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -16985,18 +16985,20 @@ is called and the @var{flag} argument passed to it.
@node New/Delete Builtins
@section Built-in functions for C++ allocations and deallocations
-@findex __builtin_operator_new
-@findex __builtin_operator_delete
-Calling these C++ built-in functions is similar to calling
-@code{::operator new} or @code{::operator delete} with the same arguments,
-except that it is an error if the selected @code{::operator new} or
-@code{::operator delete} overload is not a replaceable global operator
-and for optimization purposes calls to pairs of these functions can be
-omitted if access to the allocation is optimized out, or could be replaced
-with implementation provided buffer on the stack, or multiple allocation
-calls can be merged into a single allocation. In C++ such optimizations
-are normally allowed just for calls to such replaceable global operators
-from @code{new} and @code{delete} expressions.
+@cindex builtins for C++ @code{new} and @code{delete} operators
+@cindex @code{new} and @code{delete} builtins
+
+GNU C++ provides builtins that are equivalent to calling
+@code{::operator new} or @code{::operator delete} with the same arguments.
+It is an error if the selected @code{::operator new} or
+@code{::operator delete} overload is not a replaceable global operator.
+For optimization purposes, calls to pairs of these
+builtins can be omitted if access to the allocation is optimized out,
+or could be replaced with an implementation-provided buffer on the stack,
+or multiple allocation calls can be merged into a single allocation.
+In C++ such optimizations are normally allowed just for calls to such
+replaceable global operators from @code{new} and @code{delete}
+expressions.
@smallexample
void foo () @{
@@ -17010,6 +17012,21 @@ void foo () @{
@}
@end smallexample
+These built-ins are only available in C++.
+
+@defbuiltin{{void *} __builtin_operator_new (std::size_t @var{size}, ...)}
+This is the built-in form of @code{operator new}. It accepts the same
+argument forms as a ``usual allocation function'', as described in the
+C++ standard.
+@enddefbuiltin
+
+@defbuiltin{void __builtin_operator_delete (void * @var{ptr}, ...)}
+This is the built-in form of @code{operator delete}. It accepts the same
+argument forms as a ``usual deallocation function'', as described in the
+C++ standard.
+@enddefbuiltin
+
+
@node Other Builtins
@section Other Built-in Functions Provided by GCC
[gcc r15-8684] Doc: Add "Aggregate Types" sectioning to extend.texi [PR42270]
https://gcc.gnu.org/g:9fc2f849f58d3b35a7d7ceca057be07f9ad6284d
commit r15-8684-g9fc2f849f58d3b35a7d7ceca057be07f9ad6284d
Author: Sandra Loosemore
Date: Thu Mar 13 14:52:10 2025 +
Doc: Add "Aggregate Types" sectioning to extend.texi [PR42270]
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 (Aggregate Types): New section.
(Variable Length): Make it a subsection of the above.
(Zero Length): Likewise.
(Empty Structures): Likewise.
(Flexible Array Members in Unions): Likewise.
(Flexible Array Members alone in Structures): Likewise.
(Unnamed Fields): Likewise.
(Cast to Union): Likewise.
(Subscripting): Likewise.
(Initializers): Likewise.
(Compound Literals): Likewise.
(Designated Inits): Likewise.
Diff:
---
gcc/doc/extend.texi | 1324 ++-
1 file changed, 667 insertions(+), 657 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 92ab031fc904..2ea649f64609 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -32,25 +32,15 @@ extensions, accepted by GCC in C90 mode and in C++.
* Typeof:: @code{typeof}: referring to the type of an expression.
* Conditionals::Omitting the middle operand of a @samp{?:} expression.
* Additional Numeric Types:: Additional sizes and formats, plus complex
numbers.
+* Aggregate Types::Extensions to arrays, structs, and unions.
* Hex Floats:: Hexadecimal floating-point constants.
* Named Address Spaces::Named address spaces.
-* Zero Length:: Zero-length arrays.
-* Empty Structures::Structures with no members.
-* Flexible Array Members in Unions:: Unions with Flexible Array Members.
-* Flexible Array Members alone in Structures:: Structures with only Flexible
Array Members.
-* Variable Length:: Arrays whose length is computed at run time.
* Variadic Macros:: Macros with a variable number of arguments.
* Escaped Newlines::Slightly looser rules for escaped newlines.
-* Subscripting::Any array can be subscripted, even if not an lvalue.
* Pointer Arith:: Arithmetic on @code{void}-pointers and function
pointers.
* Variadic Pointer Args:: Pointer arguments to variadic functions.
* Pointers to Arrays:: Pointers to arrays with qualifiers work as expected.
-* Initializers::Non-constant initializers.
-* Compound Literals:: Compound literals give structures, unions
-or arrays as values.
-* Designated Inits::Labeling elements of initializers.
* Case Ranges:: `case 1 ... 9' and such.
-* Cast to Union:: Casting to union type from any member of the union.
* Mixed Labels and Declarations:: Mixing declarations, labels and code.
* Function Attributes:: Declaring that functions have no side effects,
or that they can never return.
@@ -89,7 +79,6 @@ extensions, accepted by GCC in C90 mode and in C++.
* Target Builtins:: Built-in functions specific to particular targets.
* Target Format Checks:: Format checks specific to particular targets.
* Pragmas:: Pragmas accepted by GCC.
-* Unnamed Fields:: Unnamed struct/union fields within structs/unions.
* Thread-Local::Per-thread variables.
* Binary constants::Binary constants using the @samp{0b} prefix.
* OpenMP:: Multiprocessing extensions.
@@ -1451,288 +1440,125 @@ Pragmas to control overflow and rounding behaviors
are not implemented.
Fixed-point types are supported by the DWARF debug information format.
-@node Hex Floats
-@section Hex Floats
-@cindex hex floats
-
-ISO C99 and ISO C++17 support floating-point numbers written not only in
-the usual decimal notation, such as @code{1.55e1}, but also numbers such as
-@code{0x1.fp3} written in hexadecimal format. As a GNU extension, GCC
-supports this in C90 mode (except in some cases when strictly
-conforming) and in C++98, C++11 and C++14 modes. In that format the
-@samp{0x} hex introducer and the @samp{p} or @samp{P} exponent field are
-mandatory. The exponent is a decimal number that indicates the power of
-2 by which the significant part is multiplied. Thus @samp{0x1.f} is
-@tex
-$1 {15\over16}$,
-@end tex
-@ifnottex
-1 15/16,
-@end ifnottex
-@samp{p3} multiplies it by 8, and the value of @code{0x1.fp3}
-is the same as @code{1.55e1}.
-
-Unlike for floating-point numbers in the decimal notation the exponent
-is always required in the hexadecimal notation. Otherwise the compiler
-would not be able to resolve the ambiguity of, e.g., @code{0x1.f}. This
-could mean @code{1.0f} or @code{1.9375} since @samp{f} is also the
-extension for floating-point constants of type @code{float}.
-
-@node
[gcc r15-9155] Doc: #pragma pack documentation cleanup [PR114957] [PR78008] [PR60972]
https://gcc.gnu.org/g:a2e03736fc932ef613ad01a9499126cbaa538bf8
commit r15-9155-ga2e03736fc932ef613ad01a9499126cbaa538bf8
Author: Sandra Loosemore
Date: Wed Apr 2 18:20:35 2025 +
Doc: #pragma pack documentation cleanup [PR114957] [PR78008] [PR60972]
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 long-standing bug [PR60972] reporting that #pragma pack
and the __attribute__(packed) don't get along well. It seems worthwhile
to warn users about that since elsewhere pragmas are cross-referenced
with related or equivalent attributes.
gcc/ChangeLog
PR c/114957
PR c/78008
PR c++/60972
* doc/extend.texi (Structure-Layout Pragmas): Add @cindex
entries and reformat the pragma descriptions to match the markup
used for other pragmas. Document what #pragma pack(0) does.
Add cross-references to similar attributes.
Diff:
---
gcc/doc/extend.texi | 87 +++--
1 file changed, 58 insertions(+), 29 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 109c7d26ea28..d76d333576f9 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9972,50 +9972,79 @@ always the C-language name.
@node Structure-Layout Pragmas
@subsection Structure-Layout Pragmas
-For compatibility with Microsoft Windows compilers, GCC supports a
-set of @code{#pragma} directives that change the maximum alignment of
+@cindex pragma, pack
+@cindex pack pragma
+For compatibility with Microsoft Windows compilers, GCC supports a set
+of @code{#pragma pack} directives that change the maximum alignment of
members of structures (other than zero-width bit-fields), unions, and
-classes subsequently defined. The @var{n} value below always is required
-to be a small power of two and specifies the new alignment in bytes.
+classes subsequently defined. The @var{n} value below specifies the
+new alignment in bytes and may have the value 1, 2, 4, 8, and 16. A
+value of 0 is also permitted and indicates the default alignment (as if
+no @code{#pragma pack} were in effect) should be used.
-@enumerate
-@item @code{#pragma pack(@var{n})} simply sets the new alignment.
-@item @code{#pragma pack()} sets the alignment to the one that was in
+@table @code
+@item #pragma pack(@var{n})
+Sets the new alignment according to @var{n}.
+
+@item #pragma pack()
+Sets the alignment to the one that was in
effect when compilation started (see also command-line option
-@option{-fpack-struct[=@var{n}]} @pxref{Code Gen Options}).
-@item @code{#pragma pack(push[,@var{n}])} pushes the current alignment
+@option{-fpack-struct[=@var{n}]}. @xref{Code Gen Options}).
+
+@item #pragma pack(push[,@var{n}])
+Pushes the current alignment
setting on an internal stack and then optionally sets the new alignment.
-@item @code{#pragma pack(pop)} restores the alignment setting to the one
+
+@item #pragma pack(pop)
+Restores the alignment setting to the one
saved at the top of the internal stack (and removes that stack entry).
Note that @code{#pragma pack([@var{n}])} does not influence this internal
stack; thus it is possible to have @code{#pragma pack(push)} followed by
-multiple @code{#pragma pack(@var{n})} instances and finalized by a single
-@code{#pragma pack(pop)}.
-@end enumerate
+multiple @code{#pragma pack(@var{n})} instances, with the original state
+restored by a single @code{#pragma pack(pop)}.
+
+@end table
+
+You can also use the @code{packed} type attribute (@pxref{Common Type
+Attributes}) to pack a structure. However, the @code{packed}
+attribute interferes with @code{#pragma pack}, and attempting to use
+them together may cause spurious warnings or unexpected behavior.
+@c FIXME: This is PR 60972.
+@cindex pragma, ms_struct
+@cindex ms_struct pragma
+@cindex Microsoft struct layout
Some targets, e.g.@: x86 and PowerPC, support the @code{#pragma ms_struct}
-directive which lays out structures and unions subsequently defined as the
-documented @code{__attribute__ ((ms_struct))}.
+directive, which causes subsequent structure and union declarations to
+be laid out in the same way as
+@code{__attribute__ ((ms_struct))}; @pxref{x86 Variable Attributes}.
-@enumerate
-@item @code{#pragma ms_struct on} turns on the Microsoft layout.
-@item @code{#pragma ms_struct off} turns off the Microsoft layout.
-@item @code{#pragma ms_struct reset} goes back to the default layout.
-@end enumerate
+@table @code
+@item #pragma ms_struct on
+Turns on the Microsoft layout.
+@item #pragma ms_struct off
+Turns off the Microsoft layout.
+@item #pragma ms_struct reset
+Goes back to the default layout.
+@end table
+@cindex
