Andrew Stubbs [Thu, 20 Nov 2025 17:18:13 +0000 (17:18 +0000)]
libgomp, amdgcn: Implement Managed Memory
This patch implements "managed" memory for AMD GCN GPUs in OpenMP. It
builds on the support added to the NVPTX libgomp for CUDA Managed Memory, a
week or two ago.
These features were first posted here a few years ago, as part of a larger
Unified Shared Memory patch series, and then in a slightly changed version just
over a year ago. Hopefully this time the controversial bits have been removed.
Since we do not use HIP we cannot use hipMallocManaged, so this patch attempts
to replicate the same effect by setting the appropriate attributes. This works
on more devices than support proper USM, but still I cannot be sure that the
settings are correct for every device out there (I have tested on gfx900,
gfx906, gfx908, gfx90a, and gfx1100).
The HSA header file update uses the most recent files relicensed for us by AMD,
at the time of the first patch posting. Those files have certainly moved on in
the upstream sources, but I did not ask to get those relicensed.
This commit creates initial gcc/algol68/ChangeLog and
libga68/ChangeLog files with copyright notices and content moved from
the top-level ChangeLog and gcc/ChangeLog.
OpenMP/Fortran: Allow explicit map followed by implicit deep mapping [PR120505]
Consider the following source code, assuming tiles is allocatable:
```
!$omp target enter data map(var%tiles(1)%den1, var%tiles(1)%den2) ! (1)
[...]
!$omp target ! implicitly maps var, which triggers deep mapping of tiles (2)
```
Each omp directive causes a run-time error in libgomp:
(1) libgomp: Mapped array elements must be the same (0x14d729c0 vs 0x14d72a18)
(2) libgomp: Trying to map into device [0x3704ca50..0x3704cb00) object when
[0x3704ca50..0x3704caa8) is already mapped
Regarding (1), the OpenMP spec has the following restriction: "If multiple list
items are explicitly mapped on the same construct and have the same containing
array or have base pointers that share original storage, and if any of the list
items do not have corresponding list items that are present in the device data
environment prior to a task encountering the construct, then the list items must
refer to *the same array elements* of either the containing array or the
implicit array of the base pointers."
Because tiles is allocatable, we cannot prove at compile time that array
elements are the same, so the check is deferred to libgomp. But there the
condition enforcing that all addresses are the same is too strict, so this patch
relaxes it to only check that addresses are sorted in increasing order.
The OpenMP spec allows (2) as long as it is implicit, without extending the
original mapping. So this patch sets the GOMP_MAP_IMPLICIT flag appropriately
on deep maps at compile time to let libgomp know that it is fine.
This patch ensures that such user code is accepted by:
(1) Setting the GOMP_MAP_IMPLICIT flag appropriately on deep maps;
(2) Relaxing the restriction on struct mapping from different containing arrays,
so that the element index need not be the same, instead addresses must be sorted
in increasing order.
This fixes the two errors currently seen when running SPEC HPC clvleaf
benchmark. However, further mapping issues prevent the benchmark from running to
completion.
PR fortran/120505
gcc/ChangeLog:
* omp-low.cc (lower_omp_target): Set GOMP_MAP_IMPLICIT flag.
libgomp/ChangeLog:
* target.c (gomp_map_vars_internal): Allow struct mapping from different
containing array elements as long as adresses are in increasing order.
* testsuite/libgomp.c-c++-common/map-arrayofstruct-2.c: Adjust
dg-output.
* testsuite/libgomp.c-c++-common/map-arrayofstruct-3.c: Likewise.
* testsuite/libgomp.fortran/map-subarray-5.f90: Likewise.
* testsuite/libgomp.fortran/map-subarray-10.f90: New test.
* testsuite/libgomp.fortran/map-subarray-9.f90: New test.
Jakub Jelinek [Mon, 1 Dec 2025 09:44:48 +0000 (10:44 +0100)]
a68: Fix algol68 build on i686-linux
GCC with enabled algol68 fails to build on i686-linux, the error is
../../gcc/algol68/a68-low-multiples.cc:636:31: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘size_t’ {aka ‘unsigned int’} [-Werror=format=]
xasprintf is printf family, so it can't use %zd portably, so the
following patch uses what is used elsewhere, the HOST_SIZE_T_PRINT*
macros with (fmt_size_t) cast - the macros pick the smallest of
%d, %ld and %lld depending on SIZE_MAX, but it could still disagree
on the exact type and cause warnings or for hosts with say 24-bit
size_t it could be even larger, so the cast is needed to handle that.
2025-12-01 Jakub Jelinek <jakub@redhat.com>
* algol68/a68-low-multiples.cc (copy_multiple_dimension_elems): Use
HOST_SIZE_T_PRINT_DEC in xasprintf format string and cast to
fmt_size_t.
Jose E. Marchesi [Sun, 30 Nov 2025 19:42:43 +0000 (20:42 +0100)]
a68: some small a68-diagnostics.cc improvements
This commit fixes a few problems in algol68/a68-diagnostics.cc,
reported by David Malcolm in-list.
gcc/ChangeLog
* algol68/a68-diagnostics.cc (diagnostic): Copypasto "a meek"
should be "a firm". Support printing line number for programs
longer than 9 lines. Use obstack_append_str rather than
obstack_grow.
(obstack_append_str): New function.
Jakub Jelinek [Sun, 30 Nov 2025 14:52:27 +0000 (15:52 +0100)]
c++: Fix error recovery in cp_hide_range_decl [PR122465]
The following testcase shows that range_decl in cp_hide_range_decl is
sometimes also NULL_TREE and not just error_mark_node, and the function
IMHO should treat both the same, not try to hide anything in that case
because it doesn't know what should be hidden. This ICEs during
error recovery since something like cp_hide_range_decl has been introduced
(earlier it wasn't called that way).
The fix tweaks cp_parser_simple_declaration, such that it stores error_mark_node
instead of NULL_TREE into *maybe_range_for_decl in the erroneous cases.
2025-11-30 Jakub Jelinek <jakub@redhat.com>
PR c++/122465
* parser.cc (cp_parser_simple_declaration): Adjust function comment.
Set *maybe_range_for_decl to error_mark_node instead of keeping it
NULL_TREE in error cases or when followed by CPP_COLON.
but which is highly inefficient. This loops has 3 IVs (PR119577), one normal
scalar one, two vector ones, one counting up and one counting down (PR115120)
and has a forced unrolling due to an increase in VF because of the mismatch in
modes between the IVs and the loop body (PR119860).
This patch fixed all three of these issues and we now generate:
which shows that the new scalar IV is efficiently merged with the loop
control one based on IVopts.
To accomplish this the patch reworks how we handle "forced lived inductions"
with regard to vectorization.
Prior to this change when we vectorize a loop with early break any induction
variables would be forced live. Forcing live means that even though the values
aren't used inside the loop we must preserve the values such that when we start
the scalar loop we can pass the correct initial values.
However this had several side-effects:
1. We must be able to vectorize the induction.
2. The induction variable participates in VF determination. This would often
times lead to a higher VF than would have normally been needed. As such the
vector loops become less profitable.
3. IVcannon on constant loop iterations inserts a downward counting IV in
addition to the upwards one in order to support things like doloops.
Normally this duplicate IV is removed by IV opts, but IV doesn't understand
vector inductions. As such we end up with 3 IVs.
This patch fixes all three of these by choosing instead to create a new scalar
IV that's adjusted within the loop and to update all the IV statements outside
the loop by using this new IV.
We re-use vect_update_ivs_after_vectorizer for all exits now and put in a dummy
value representing the IV that is to be generated later.
To do this we delay when we call vect_update_ivs_after_vectorizer until after
the skip_epilogue edge is created and vect_update_ivs_after_vectorizer now
updates all out of loop usages of IVs and not just that in the merge edge to
the scalar loop. This not only generates better code, but negates the need to
fixup the "forced live" scalar IVs later on.
This new scalar IV is then materialized in
vect_update_ivs_after_vectorizer_for_early_breaks. When PFA using masks by
skipping iterations we now roll up the pfa IV into the new scalar IV by
adjusting the first iteration back from start - niters_peel and then take the
MAX <scal_iv, 0> to correctly handle the first iteration.
Because we are now re-using vect_update_ivs_after_vectorizer we have an issue
with UB clamping on non-linear inductions.
At the moment when doing early exit updating I just ignore the possibility of UB
since if the main exit is OK, the early exit is one iteration behind the main
one and so should be ok.
Things however get complicated with PEELED loops.
gcc/ChangeLog:
PR tree-optimization/115120
PR tree-optimization/119577
PR tree-optimization/119860
* tree-vect-loop-manip.cc (vect_can_advance_ivs_p): Check for nonlinear
mult induction and early break.
(vect_update_ivs_after_vectorizer): Support early break exits.
(vect_do_peeling): Support scalar IVs.
* tree-vect-loop.cc (vect_peel_nonlinear_iv_init): Support early break.
(vect_update_nonlinear_iv): use `unsigned_type_for` such that function
works for both vector and scalar types.
(vectorizable_induction, vectorizable_live_operation): Remove vector
early break IV code.
(vect_update_ivs_after_vectorizer_for_early_breaks): New.
(vect_transform_loop): Support new scalar IV for early break.
* tree-vect-slp.cc (vect_analyze_slp): Remove SLP build for early break
IVs.
* tree-vect-stmts.cc (vect_stmt_relevant_p): No longer mark early break
IVs as completely unused rather than used_only_live. They no longer
contribute to the vector loop and so should not be analyzed.
(can_vectorize_live_stmts): Remove vector early vreak IV code.
* tree-vectorizer.h (LOOP_VINFO_EARLY_BRK_NITERS_VAR): New.
(class loop_vec_info): Add early_break_niters_var.
Jose E. Marchesi [Sat, 11 Oct 2025 17:43:02 +0000 (19:43 +0200)]
a68: darwin specific support
This commit:
- Adapts specs in config/darwin.h for libga68.a.
- Amends section processing for non-LTO use in libibery on Darwin.
The initial implementation of the Mach-O simple object code was
mainly targeting LTO cases. The implementation was not suitable for
cases where we are just looking for a regular named section.
Jose E. Marchesi [Sat, 11 Oct 2025 17:42:30 +0000 (19:42 +0200)]
a68: DWARF language codes
This commit makes GCC aware of the DWARF numbers recently allocated
for Algol 68.
For DWARF 5, DW_LANG_Algol68 = 0x44.
For DWARF 6, DW_LNAME_Algol68 = 0x2e
with versioning schema YYYY, starting with 1973 for the original
Revised language. The language extensions we are working on will
be encoded in subsequent versions, 2025 etc.
See https://dwarfstd.org/issues/250304.1.html for more information.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/ChangeLog
* dwarf2out.cc: Set DW_LANG_Algol68 an DW_LNAME_Algol68.
Jose E. Marchesi [Sat, 11 Oct 2025 17:41:38 +0000 (19:41 +0200)]
a68: documentation
This commit adds a new section to the GCC Internals Manual and also
adds two new manuals.
ga68.texi is The GNU Algol 68 Compiler user manual. It describes how
to use the compiler and all the GNU extensions implemented on top of
the Algol 68 programming language.
ga68-internals.texi is The GNU algol68 Compiler Internals manual. It
describes the implementation of the front-end and it is of interest
primarily for developers.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/ChangeLog
* algol68/ga68-internals.texi: New file.
* algol68/ga68.texi: Likewise.
Jose E. Marchesi [Sat, 11 Oct 2025 17:58:04 +0000 (19:58 +0200)]
a68: testsuite: revised MC Algol 68 test set
We cannot distribute the MC Test Set with GCC as of now, due to not
clear distribution terms of the stuff. Until this gets clarified with
the CWI (then Mathematical Centrum) a README.mcts file explains how to
manually fetch and install the test set.
Jose E. Marchesi [Sat, 22 Nov 2025 01:19:13 +0000 (02:19 +0100)]
a68: modules exports
This commit adds the code that handles the exports information for the
module definitions in prelude packets. The exports info is generated
in a section in the output object file.
A precise description of the binary format in which the exports are
encoded is expressed in an included GNU poke pickle ga68-exports.pk.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/ChangeLog
* algol68/a68-exports.cc: New file.
* algol68/ga68-exports.pk: Likewise.
Jose E. Marchesi [Sat, 11 Oct 2025 17:43:37 +0000 (19:43 +0200)]
a68: gcc/algol68 misc files
README contains a description of the front-end, and brief instructions
for developers.
At the moment the front-end doesn't define any custom tree node, as of
yet. gcc/algol68/a68-tree.def is a placeholder where to have these
node codes.
a68-types.h and a68.h are the main header files used by the front-end.
Together they provide data definitions and prototypes of functions
defined in the .cc files.
ga68.vw contains a revised-report like formal description of the
language implemented by this compiler. This includes GNU extensions.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/ChangeLog
Nathaniel Shead [Sat, 15 Nov 2025 04:27:13 +0000 (15:27 +1100)]
c++: Support template block-scope OpenMP user-defined reductions in modules [PR119864]
There were two issues preventing OpenMP reductions of UDTs from working
in modules.
Firstly, we were failing a number of checking asserts in the streaming
logic because the declaration is a DECL_LOCAL_DECL_P but was not
correctly added to the BLOCK of the function template. This is because
cp_parser_omp_declare_reduction only called pushdecl when
!processing_template_decl; correcting this fixed this issue.
The second issue is that modules saw this as a function definition and
so attempted to call allocate_struct_function on it, which crashes.
Given that these reduction functions don't really behave like real
function definitions in any other way, I think the cleanest solution is
to just skip all the function definition post-processing in modules;
this seems to work to get the test functioning correctly, from what I
can see.
PR c++/119864
gcc/cp/ChangeLog:
* module.cc (trees_in::read_function_def): Don't call
post_process on OpenMP UDT reductions.
* parser.cc (cp_parser_omp_declare_reduction): Call push_decl
for block_scope, even when processing_template_decl.
gcc/testsuite/ChangeLog:
* g++.dg/modules/omp-4_a.C: New test.
* g++.dg/modules/omp-4_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jakub Jelinek <jakub@redhat.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jakub Jelinek [Sat, 29 Nov 2025 16:37:58 +0000 (17:37 +0100)]
c++: Limit P2795R5 handling of jumps across vacuous inits to !processing_template_decl [PR122758]
The extra handling of jumps across vacuous inits for -std=c++26
or -ftrivial-auto-var-init={zero,pattern} added for P2795R5 is undesirable
when processing_template_decl, because it creates labels without DECL_NAME
and GOTO_EXPRs to those and those can't be tsubsted.
I was afraid the pop_labels and check_goto_1 and check_previous_goto_1
handling might not happen again during instantiation, but clearly it does
happen fully (and has to, because whether some declaration has vacuous
initialization or not can't be decided in some cases when parsing the
template, if dependent types are involved).
So, this patch just restricts the P2795R5 PR114457 r16-4212 changes
to !processing_template_decl and adds 2 copies of the erroneous2.C testcase,
one changing the function into a function template where nothing is
dependent and another one where most of the declarations are dependent.
2025-11-29 Jakub Jelinek <jakub@redhat.com>
PR c++/122758
* decl.cc (pop_labels): Don't call adjust_backward_gotos if
processing_template_decl.
(decl_instrument_init_bypass_p): Always return false if
processing_template_decl.
(check_goto_1): Don't push anything to direct_goto vector
if processing_template_decl.
* g++.dg/cpp26/erroneous5.C: New test.
* g++.dg/cpp26/erroneous6.C: New test.
Sandra Loosemore [Sat, 29 Nov 2025 02:40:24 +0000 (02:40 +0000)]
doc: Fix alphabetization of FRV/FT32 option documentation sections.
The FRV and FT32 options were incorrectly alphabetized with respect to
each other in the Options Summary, the menu for the Submodel Options
section, and in the order of their respective subsections. Fixed
thusly.
gcc/ChangeLog
* doc/invoke.texi (Options Summary): Switch ordering of FRV
and FT32.
(Submodel Options): Likewise in the menu and section ordering.
doc, frv: Clean up FRV option documentation [PR122243]
frv.opt has a few options that have never been documented in the
manual. In the initial commit of the FRV port (prior to the adoption
of .opt files) they were marked as "Internal debug switch" so I have
explicitly made them "Undocumented", consistently with other options
similarly marked in the original port.
The documentation changes all straightforward here, to bring this
section into conformance with conventions being applied through this
chapter of the manual.
gcc/ChangeLog
PR other/122243
* config/frv/frv.opt (mbranch-cost=): Mark as Undocumented.
(mcond-exec-insns=): Likewise.
(mcond-exec-tempss=): Likewise.
* doc/invoke.texi (Option Summary) <FRV Options>: Remove duplicate
positive/negative forms from the list.
(FRV Options): Combine documentation of positive/negative forms
where they were listed separately. Add @opindex entries for
negative forms.
Sandra Loosemore [Tue, 18 Nov 2025 23:34:09 +0000 (23:34 +0000)]
doc, darwin: Clean up Darwin options and documentation [PR122243]
The Darwin target options documentation was a bit of a mess, with several
undocumented options, some that were listed in the option summary or mentioned
in discussion of other options but not actually documented, and a large
number of options listed in darwin.opt as being obsolete.
I've undocumented all the obsolete options to streamline things, plus a few
others that seem to have been intentially undocumented or supplanted by
other options. For the others that were probably supposed to documented,
I did my best to guess what they're for by reading the code or just
copying the documentation string in the .opt file, but it's certainly
possible I screwed some up.
gcc/ChangeLog
PR other/122243
* config/darwin.opt (findirect-virtual-calls): Mark as Undocumented.
(fterminated-vtables): Likewise.
(multi_module): Likewise.
(multiply_defined): Likewise.
(multiply_defined_unused): Likewise.
(no_dead_strip_inits_and_terms): Likewise.
(noprefixbinding): Likewise.
(nomultidefs): Likewise.
(noprebind): Likewise.
(noseglinkedit): Likewise.
(ObjC, ObjC++): Add documentation strings.
(object): Mark as Undocumented.
(prebind): Likewise.
(prebind_all_twolevel_modules): Likewise.
(private_bundle): Likewise.
(sectobjectsymbols): Likewise.
(sectorder): Likewise.
(seg_addr_table_filename): Likewise.
(segcreate): Likewise.
(seglinkedit): Likewise.
(single_module): Likewise.
(X): Likewise.
(y): Likewise.
(Mach): Likewise.
* doc/invoke.texi (Option Summary) <Darwin Options>: Improve
alphabetization of the list. Remove obsolete/undocumented
options and add missing entries.
(Darwin Options): Add documentation for -arch, -dependency-file,
-fapple-kext, -matt-stubs, -fconstant-cfstrings, -mdynamic-no-pic,
-asm_macosx_version_min, -msymbol-stubs, -mtarget-linker,
-ObjC, -ObjC++, -Wnonportable-cfstrings. Update the list
of options passed to the linker to remove obsolete options
and add missing ones; also move the block of @opindex entries
before the list items instead of putting it in the middle.
gcc/ChangeLog
PR other/122243
* doc/invoke.texi (Option Summary) <C-SKY Options>: Remove
entries for "Undocumented" options -EB, -EL, -mhard-float,
-msoft-float, and nonexistent option -mcse-cc.
(C-SKY Options): Likewise. Also remove references to "Undocumented"
option -mstm and uniformly index/document the -mno- forms for
consistency with other options in this section that already do so.
doc, cris: Clean up CRIS option documentation [PR122243]
This is another patch in the series to make documentation of
target-specific options in invoke.texi match what is in the
corresponding .opt files.
The cris.opt file is a bit strange, with many cases where negative
forms are listed explicitly as separate options from the positive
forms, with both having "RejectNegative" and one (typically the form
that is the default) being marked as "Undocumented". I've left that
alone since fixing it to the more normal style of having a single
option setting a boolean flag would require code changes, and I'm not
set up to build or test this target.
Beyond that, the "Undocumented" status of options in the .opt file did
not in several cases match what was actually documented in the manual.
I've generally assumed that the manual is correct, and e.g. the
-m32-bit, -m16-bit, and -m8-bit options, all previously marked
"Undocumented" but listed in invoke.texi, are preferred to the
equivalent options without the hyphen. I've removed the references to
the obsolete -melf and -maout options and added documentation in the
manual for some options that were previously documented only in the .opt
file.
gcc/ChangeLog
PR other/122243
* config/cris/cris.opt (m32-bit, m16-bit, m8-bit): Remove
Undocumented property.
(m32bit, m8bit): Add Undocumented property.
* doc/invoke.texi (Option Summary) <CRIS Options>: Remove
obsolete -melf and -maout options from table, plus redundant
-mno-mul-bug-workaround.
(CRIS Options): Add @opindex for -mno- forms that didn't already
have one. Remove obsolete -melf documentation. Document
-mbest-lib-options, -moverride-best-lib-options,
-mtrap-using-break8, -mtrap-unaligned-atomic, and
-munaligned-atomic-may-use-library.
doc, blackfin: Don't separately document no- form of Blackfin options [PR122243]
The documentation for Blackfin options had separate entries for the
positive and negative forms of many options, both in the Option Summary
and detailed documentation. This is unnecessarily verbose and counter
to the general rule that only one form of each option is documented.
gcc/ChangeLog
PR other/122243
* doc/invoke.texi (Option Summary) <Blackfin Options>:
Remove redundant -mno- entries.
(Blackfin Options): Combine explicit -mno-* documentation
with that for the corresponding positive form of the option.
Add @opindex entries for the negative forms of options that
didn't already have one.
doc, arm: Clean up ARM option documentation [PR122243]
This patch undocuments ARM target-specific options that have never
been implemented, are already marked as "Undocumented" in arm.opt
file, and/or are presently documented as obsolete or only useful for
back end debugging. I've also cleaned up the option summary to list
only one of the positive or negative forms of each option, and to
consistently index both forms.
gcc/ChangeLog
PR other/122243
* config/arm/arm.opt (mapcs-reentrant): Mark as "Undocumented",
updatehelp string for internal documentation.
(mapcs-stack-check): Likewise update help string.
(mprint-tune-info, mneon-for-64bits): Mark as "Undocumented".
* doc/invoke.texi (Option Summary) <ARM Options>: Remove duplicate
entries for negative forms and entries for options that are
explicitly "Undocumented". Add missing entry for
-mpic-data-is-text-relative. Fix some formatting issues.
(ARM Options): Remove documentation for -mapcs-stack-check,
-mapcs-reentrant, -mflip-thumb, -mneon-for-64-bits,
-mprint-tune-info, and -mverbose-cost-dump. Add index entries
for -mno- option forms. Minor editing for clarity.
doc, gcn: Clean up gcn target options and docs [PR122243] [PR122288]
Per PR target/122288, gcn.opt contained some invalid syntax that was
quietly accepted by the options processor. This patch fixes that,
marks some useless options as "Undocumented", and brings the
documentation into sync with the options file.
I tested the .opt file changes on both a standalone gcn build (gcc and
g++ testsuites) and in an x86_64-linux-gnu build with gcn as offload
target (libgomp).
gcc/ChangeLog
PR other/122243
PR target/122288
* config/gcn/gcn.opt (m32, m64, mgomp): Mark "Undocumented"
since these options don't actually do anything useful.
(flag_bypass_init_error, stack_size_opt, gang_size_opt): Correct
opt file syntax.
(mstack-size=): Mark "Undocumented" since it's obsolete.
* doc/invoke.texi (Option Summary) <AMD GCN Options>:
Remove obsolete options, add missing entries for
-mgang-private-size=, -msram-ecc=, and -mxnack=.
(AMD GCN Options): Likewise.
doc, epiphany: Clean up epiphany target options and docs [PR122243]
gcc/ChangeLog
PR other/122243
* config/epiphany/epiphany.opt (mlong-calls): Make it do something
useful.
(may-round-for-trunc): Make this undocumented option with a weird
name an alias for -mmay-round-for-trunc.
(mfp-iarith): Fix doc string.
* doc/invoke.texi (Option Summary) <Adapteva Epiphany Options>:
Add missing options.
(Adapteva Epiphany Options): Document negative forms also when
that is not the default, or where it's unclear. Document
-may-round-for-trunc and -mfp-iarith. Fix spelling of
-mpost-inc and -mpost-modify.
doc, aarch64: Clean up aarch64 options and documentation [PR122243]
gcc/ChangeLog
PR other/122243
* config/aarch64/aarch64.opt (Wexperimental-fmv-target): Mark
as "Undocumented".
* doc/invoke.texi (Option Summary) <AArch64 Options>: Don't
list "Undocumented" aarch64 options -mverbose-cost-dump or
-Wexperimental-fmv-target, or both positive and negative forms
of other options. Add missing options. Fix whitespace problems.
(AArch64 Options): Light copy-editing. Add missing @opindex
entries to match the documented options. Undocument
-mverbose-cost-dump and -Wexperimental-fmv-target.
Jakub Jelinek [Fri, 28 Nov 2025 21:06:30 +0000 (22:06 +0100)]
analyzer: Fix 3 C++20 warnings in analyzer
I've noticed
../../gcc/analyzer/known-function-manager.cc:86:33: warning: arithmetic between different enumeration types ‘internal_fn’ and ‘built_in_function’ is deprecated
+[-Wdeprecated-enum-enum-conversion]
../../gcc/analyzer/known-function-manager.cc:87:26: warning: arithmetic between different enumeration types ‘internal_fn’ and ‘built_in_function’ is deprecated
+[-Wdeprecated-enum-enum-conversion]
../../gcc/analyzer/known-function-manager.cc:140:33: warning: arithmetic between different enumeration types ‘internal_fn’ and ‘built_in_function’ is deprecated
+[-Wdeprecated-enum-enum-conversion]
warnings. Fixed thusly.
2025-11-28 Jakub Jelinek <jakub@redhat.com>
* known-function-manager.cc (known_function_manager::add): Avoid
arithmetics between enumerators from different enum types.
(known_function_manager::get_internal_fn): Likewise.
Jakub Jelinek [Fri, 28 Nov 2025 21:05:34 +0000 (22:05 +0100)]
powerpc: PowerPC backend, meet C++20
C++20, in particular https://wg21.link/P1120R0 paper voted into it,
deprecates various operations between enumerators from different enumeration
types etc., and as we've switched to -std=gnu++20 by default, this now
results in warnings or errors during stage2 and onwards.
The following patch should fix rs6000 build.
2025-11-28 Jakub Jelinek <jakub@redhat.com>
* config/rs6000/rs6000.cc (complex_multiply_builtin_code):
Avoid arithmetics between enumerators from different enum types.
(complex_divide_builtin_code): Likewise.
Jakub Jelinek [Fri, 28 Nov 2025 21:04:57 +0000 (22:04 +0100)]
loongarch: LoongArch backend, meet C++20
C++20, in particular https://wg21.link/P1120R0 paper voted into it,
deprecates various operations between enumerators from different enumeration
types etc., and as we've switched to -std=gnu++20 by default, this now
results in warnings or errors during stage2 and onwards.
The following patch should fix loongarch build.
2025-11-28 Jakub Jelinek <jakub@redhat.com>
* config/loongarch/loongarch.cc (loongarch_unspec_address_offset):
Avoid arithmetics between enumerators from different enum types.
(loongarch_call_tls_get_addr): Likewise.
Jakub Jelinek [Fri, 28 Nov 2025 21:04:25 +0000 (22:04 +0100)]
mips: MIPS backend, meet C++20
C++20, in particular https://wg21.link/P1120R0 paper voted into it,
deprecates various operations between enumerators from different enumeration
types etc., and as we've switched to -std=gnu++20 by default, this now
results in warnings or errors during stage2 and onwards.
The following patch should fix mips build.
2025-11-28 Jakub Jelinek <jakub@redhat.com>
* config/mips/mips.cc (mips_unspec_address_offset): Avoid
arithmetics between enumerators from different enum types.
Jakub Jelinek [Fri, 28 Nov 2025 21:03:19 +0000 (22:03 +0100)]
riscv: RISCV backend, meet C++20
C++20, in particular https://wg21.link/P1120R0 paper voted into it,
deprecates various operations between enumerators from different enumeration
types etc., and as we've switched to -std=gnu++20 by default, this now
results in warnings or errors during stage2 and onwards.
The following patch should fix riscv build.
2025-11-28 Jakub Jelinek <jakub@redhat.com>
* config/riscv/riscv-v.cc (expand_const_vector_onestep): Avoid
bitwise ops between enumerators from different enum types.
(emit_vec_cvt_x_f): Likewise.
(emit_vec_cvt_x_f_rtz): Likewise.
* config/riscv/riscv.cc (riscv_unspec_address_offset): Avoid
arithmetics between enumerators from different enum types.
Patrick Palka [Fri, 28 Nov 2025 20:38:04 +0000 (15:38 -0500)]
libstdc++: Correctly implement LWG 3946 changes to const_iterator_t [PR122842]
LWG 3946 made const_iterator_t/sentinel_t agree with ranges::cbegin/cend
by defining the aliases in terms of the CPOs, but I defined it the other
way around in an incorrect way that made the aliases not consider
range-ness of const T via __possibly_const_range. This patch
reimplements the proposed resolution in a more obviously correct way,
mirroring the wording.
PR libstdc++/122842
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__access:_CBegin): Define in
terms of const_iterator directly, not const_iterator_t.
(__access::_CEnd): Likewise in terms of const_sentinel vs
const_sentinel_t.
(const_iterator_t): Move down definition and define in terms
of ranges::cbegin as per LWG 3946.
(const_sentinel_t): Likewise in terms of ranges::cend.
* testsuite/24_iterators/const_iterator/1.cc (test02): Correct
test for int[], std::array and std::vector. Also test
std::string.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Andrew MacLeod [Wed, 26 Nov 2025 19:21:13 +0000 (14:21 -0500)]
Undefined bitmasks imply undefined ranges.
bitmask have no way of representing UNDEFINED, and as such, bitmask
intersection returns an unknown_p values instead. This patch has the
function return false in this case, which will indicate UNDEFINED.
PR tree-optimization/122686
gcc/
* range-op.cc (operator_bitwise_and::op1_range): Check for
undefined bitmask.
* value-range.cc (prange::intersect): Handle undefined bitmask
intersection.
(irange::get_bitmask): Ditto.
(irange::intersect_bitmask): Ditto.
* value-range.h (irange_bitmask::intersect): Return false if the
result is UNDEFINED.
Tobias Burnus [Fri, 28 Nov 2025 13:56:30 +0000 (14:56 +0100)]
GCN: Use generic instead of specific arch for default-built multilibs
GCC 15 and ROCm 6.4.0 (released April/May 2025) support generic archs.
Thus, by moving to generic archs, the number of multilibs build by GCC
can be reduced - while the number of supported devices increases.
This commit now replaces the specific gfx... by gfx{9,9-4,10-3,11}-generic,
keeping gfx908 and gfx09a as no generic exists for those.
When building for a device without a multilib but the generic one exists,
there is a diagnostic like:
gcn mkoffload: fatal error: GCC was built without library support for
‘-march=gfx1150’; consider compiling for the associated generic
architecture ‘-march=gfx11-generic’ instead
As gfx900 is no longer build by default, gfx90a was picked as new
default device.
gcc/ChangeLog:
* config.gcc (amdgcn-*-*): Use gfx90a for 'with_arch'.
For TM_MULTILIB_CONFIG, replace specific archs by
gfx{9,9-4,10-3,11}-generic, keep gfx90{8,a}.
* config/gcn/gcn.opt (march=, mtune=): Use gfx90a.
* doc/install.texi (amdgcn): Update accordingly.
With the recent switch in commit r16-5628 defaulting to C++20 some
enumeration arithmetic errors are thrown during bootstrap, now. Fixed
by casting those to type int. I'm using type int here merely because
S390_ALL_BUILTIN_MAX is used in comparisons with other operands of type
int.
projects / thirdparty / gcc.git / log
