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.
Tobias Burnus [Fri, 28 Nov 2025 10:44:41 +0000 (11:44 +0100)]
OpenMP/Fortran: Reject ALLOCATE on non-local static variables with trait:cgroup/pteam/thread [PR122892]
OpenMP 6.0 clarified that static-storage objects may only specify the
omp_cgroup_mem_alloc, omp_pteam_mem_alloc, or omp_thread_mem_alloc allocator
inside a BLOCK or procedure. Let's check for this for Fortran.
PR c/122892
gcc/fortran/ChangeLog:
* openmp.cc (gfc_resolve_omp_allocate): Reject non-local
static variables with cgroup/pteam/thread allocators.
* parse.cc: Permit OMP ALLOCATE in BLOCK DATA.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/allocate-15.f90: Use another allocator as
omp_{cgroup,pteam}_mem_alloc is invalid for non-local static vars.
* gfortran.dg/gomp/allocate-7.f90: Likewise.
* gfortran.dg/gomp/allocate-static-3.f90: New test.
Jakub Jelinek [Fri, 28 Nov 2025 09:59:35 +0000 (10:59 +0100)]
c++: Remove PMF special cases from cxx_get_alias_set [PR119969]
The use of 0 alias set for PMF * types seems to break modref for some reason,
but because PMFs are canonicalized, there should be no reason to special
case the alias set of PMF or PMF * anymore.
2025-11-27 Jakub Jelinek <jakub@redhat.com>
PR c++/119969
* cp-objcp-common.cc (cxx_get_alias_set): Remove special cases
for TYPE_PTRMEMFUNC_P and INDIRECT_TYPE_P for TYPE_PTRMEMFUNC_P.
Charlie Jenkins [Wed, 26 Nov 2025 19:29:51 +0000 (11:29 -0800)]
RISC-V: Support --with-cpu
The --with-cpu will allow riscv compilers to have a default mcpu flag.
Setting -mcpu or -march at compile time will override the configured
--with-cpu.
gcc/ChangeLog:
* config.gcc: Add cpu to supported configure options
* config/riscv/riscv.h (riscv_arch_help): Use --with-cpu during
compilation
* doc/install.texi: Mention in docs that --with-cpu is supported
Jakub Jelinek [Fri, 28 Nov 2025 09:04:53 +0000 (10:04 +0100)]
match.pd: Re-add (y << x) {<,<=,>,>=} x simplifications [PR122733]
Here is my attempt to implement what has been reverted in r16-5648 using ranger.
Note also the changes to the equality pattern, first of all, there
could be e.g. vector << scalar shifts, although they'll likely
fail on the nop_convert vs. nop_convert, but also it would never
match for say unsigned long long @0 and unsigned int @1 etc., pretty
common cases.
The new simplifier asks the ranger about ranges and bitmasks, verifies
@0 is non-zero and that clz of the @0 nonzero bits bitmask (i.e. the minimum
clz of all possible values of @0) is greater than (or greater than or equal
to) maximum shift count. Which one of those depends on if the actual
non-equality comparison is signed or unsigned.
And gimple_match_range_of_expr now includes in itself undefined_p check
and returns false even for that, so that many of the callers don't
need to check that.
2025-11-28 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/122733
* gimple-match-head.cc (gimple_match_range_of_expr): Return false
even when range_of_expr returns true, but the range is undefined_p.
* match.pd ((mult (plus:s@5 (mult:s@4 @0 @1) @2) @3)): Remove
vr0.undefined_p () check.
((plus (mult:s@5 (plus:s@4 @0 @1) @2) @3)): Likewise.
((X + M*N) / N -> X / N + M): Remove vr4.undefined_p () check.
((X - M*N) / N -> X / N - M): Likewise.
((y << x) == x, (y << x) != x): Use convert2? instead of
nop_convert2? and test INTEGRAL_TYPE_P on TREE_TYPE (@0) rather than
TREE_TYPE (@1).
((y << x) {<,<=,>,>=} x): New simplification.
(((T)(A)) + CST -> (T)(A + CST)): Remove vr.undefined_p () check.
(x_5 == cstN ? cst4 : cst3): Remove r.undefined_p () check.
* gcc.dg/match-shift-cmp-4.c: New test.
* gcc.dg/match-shift-cmp-5.c: New test.
Jakub Jelinek [Thu, 27 Nov 2025 19:18:57 +0000 (20:18 +0100)]
c: Fix ICE in c_type_tag on va_list [PR121506]
The C and C++ FEs disagree on what TYPE_NAME on RECORD_TYPE for
structure/class definition is (rather than typedef/using, for
those both have TYPE_NAME of TYPE_DECL with DECL_ORIGINAL_TYPE),
the C FE just uses IDENTIFIER_NODE as TYPE_NAME on RECORD_TYPE,
while the C++ FE uses TYPE_DECL as TYPENAME on RECORD_TYPE and
only DECL_NAME on the TYPE_DECL provides the IDENTIFIER_NODE.
The reason for the C++ FE way is that there can be type definitions
at class scope (rather than just typedefs) and those need to be
among TYPE_FIELDS (so the corresponding TYPE_DECL is in that chain)
etc.
The middle-end can cope with it, e.g.
if (TREE_CODE (TYPE_NAME (node)) == IDENTIFIER_NODE)
pp_tree_identifier (pp, TYPE_NAME (node));
else if (TREE_CODE (TYPE_NAME (node)) == TYPE_DECL
&& DECL_NAME (TYPE_NAME (node)))
dump_decl_name (pp, TYPE_NAME (node), flags);
and many other places.
Now, the backends on various targets create artificial structure
definitions for va_list, e.g. x86 creates struct __va_list_tag
and they do it the C++ FE way so that the C++ FE can cope with those.
Except the new c_type_tag can't deal with that and ICEs.
The following patch fixes it so that it can handle it too.
2025-11-27 Jakub Jelinek <jakub@redhat.com>
PR c/121506
* c-typeck.cc (c_type_tag): If TYPE_NAME is TYPE_DECL
with non-NULL DECL_NAME, return that.
Jakub Jelinek [Thu, 27 Nov 2025 18:04:58 +0000 (19:04 +0100)]
gccrs: Partially unbreak rust build with C++20
I've committed earlier today https://gcc.gnu.org/r16-5628 to switch C++ to
-std=gnu++20 by default. That apparently broke rust build (I don't have
cargo installed, so am not testing rust at all).
Here is a completely untested attempt to fix that.
Note, in C++20 u8"abc" literal has const char8_t[4] type rather than
const char[4] which was the case in C++17, and there is std::u8string
etc.
The casts below to (const char *) is what I've used in libcody as well
to make it compilable with all of C++11 to C++26.
Another thing is that the source for some reason expects -fexec-charset=
to be ASCII compatible and -fwide-exec-charset= to be UTF-16 or UTF-32
or something similar. That is certainly not guaranteed.
Now, if rust-lex.cc can be only compiled with C++17 or later, we
could just use u8'_' etc., but as GCC still only requires C++14, I'd
go with u'_' etc.
2025-11-27 Jakub Jelinek <jakub@redhat.com>
* lex/rust-lex.cc (rust_input_source_test): Cast char8_t string
literals to (const char *) to make it compilable with C++20. Use
char16_t or char32_t character literals instead of ordinary
character literals or wide character literals in expected
initializers.
Matthieu Longo [Mon, 24 Nov 2025 14:56:19 +0000 (14:56 +0000)]
aarch64: Define __ARM_BUILDATTR64_FV
Support for Build Attributes (BA) was originally added in [1]. To facilitate their
use in customers codebases and avoid requiring a new Autotools test for BA support,
the specification was later amended. Toolchains that generate BA sections and
support the assembler directives should define the following preprocessor macro:
__ARM_BUILDATTR64_FV <format-version>
Where <format-version> is the same value as in [2]. Currently, only version 'A'
(0x41) is defined.
This patch also introduces two tests: one that verifies the macro definition for
positive detection of BA support; and another that ensures that no such macro is
defined when BA support is absent.
[1]: 98f5547dce2503d9d0f0cd454184d6870a315538
[2]: [Formal syntax of an ELF Attributes Section](https://github.com/smithp35/
abi-aa/blob/build-attributes/buildattr64/buildattr64.rst#formal-syntax-of-an-elf
-attributes-section)
gcc/ChangeLog:
* config/aarch64/aarch64-c.cc (aarch64_define_unconditional_macros): Define
__ARM_BUILDATTR64_FV when BA support is detected in GAS.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/build-attributes/build-attribute-define-nok.c: New test.
* gcc.target/aarch64/build-attributes/build-attribute-define-ok.c: New test.
Wilco Dijkstra [Thu, 6 Nov 2025 20:49:22 +0000 (20:49 +0000)]
AArch64: Improve ctz and ffs
Use the ctz insn in the ffs expansion so it uses ctz if CSSC
is available. Rather than splitting, keep ctz as a single
insn for simplicity and possible fusion opportunities.
Move clz, ctz, clrsb, rbit and ffs instructions together.
gcc:
* config/aarch64/aarch64.md (ffs<mode>2): Use gen_ctz.
(ctz<mode>2): Model ctz as a single target instruction.
Andrew Pinski [Wed, 26 Nov 2025 21:55:41 +0000 (13:55 -0800)]
reassociation: Fix canonical ordering in some cases
This was noticed in PR122843 were sometimes reassociation
would create the uncanonical order of operands. This fixes
the problem by swapping the order as the rewrite happens.
Wstringop-overflow.c needed to be xfailed since it started
not to warn because well the warning is too dependent on
the order of operands to MIN_EXPR. This testcase
failed if we had supplied -fno-tree-reassoc before too;
but nothing in the IR changes except the order of 2 operands
of MIN_EXPR. I filed PR 122881 for this xfail.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-reassoc.cc (rewrite_expr_tree): Swap
oe1 and oe2 if commutative code and not in
canonical order.
Jonathan Wakely [Thu, 27 Nov 2025 16:13:44 +0000 (16:13 +0000)]
analyzer: Add missing 'const' to equiv_class::operator==
This produces a warning in C++20:
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc: In member function ‘bool ana::constraint_manager::operator==(const ana::constraint_manager&) const’:
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc:1610:42: warning: C++20 says that these are ambiguous, even though the second is reversed:
1610 | if (!(*ec == *other.m_equiv_classes[i]))
| ^
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc:1178:1: note: candidate 1: ‘bool ana::equiv_class::operator==(const ana::equiv_class&)’
1178 | equiv_class::operator== (const equiv_class &other)
| ^~~~~~~~~~~
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc:1178:1: note: candidate 2: ‘bool ana::equiv_class::operator==(const ana::equiv_class&)’ (reversed)
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc:1178:1: note: try making the operator a ‘const’ member function
Robin Dapp [Wed, 26 Nov 2025 09:27:24 +0000 (10:27 +0100)]
forwprop: Nop-convert operands if necessary [PR122855].
This fixes up r16-5561-g283eb27d5f674b where I allowed nop conversions
for the input operands. There are several paths through the function
that still require an explicit nop conversion for them. This patch adds
them.
Andrew Stubbs [Tue, 11 Nov 2025 15:41:04 +0000 (15:41 +0000)]
amdgcn: Auto-detect USM mode and set HSA_XNACK
The AMD GCN runtime must be set to the correct "XNACK" mode for Unified Shared
Memory and/or self-mapping to work, but this is not always clear at compile and
link time due to the split nature of the offload compilation pipeline.
When XNACK mode is enabled, the runtime will restart GPU load/store
instructions that fail due to memory exceptions caused by page-misses. While
this is important for shared-memory systems that might experience swapping, we
are mostly interested in it because it is also used to implement page migration
between host and GPU memory, which is the basis of USM.
This patch checks that the XNACK mode is configured appropriately in the
compiler, and mkoffload then adds a runtime check into the final program to
ensure that the HSA_XNACK environment variable passes the correct mode to the
GPU.
The HSA_XNACK variable must be set before the HSA runtime is even loaded, so
it makes more sense to have this set within the constructor than at some point
later within libgomp or the GCN plugin.
Other toolchains require the end-user to set HSA_XNACK manually (or else wonder
why it's not working), so the constructor also checks that any existing manual
setting is compatible with the binary's requirements.
gcc/ChangeLog:
* config/gcn/gcn.cc (gcn_init_cumulative_args): Emit a warning if the
-mxnack setting looks wrong.
* config/gcn/mkoffload.cc: Include tree.h and omp-general.h.
(process_asm): Add omp_requires parameter.
Emit HSA_XNACK code into mkoffload_setup, as required.
(main): Modify HSACO_ATTR_OFF to preserve user-set -mxnack.
Pass omp_requires to process_asm.
Tomasz Kamiński [Thu, 27 Nov 2025 13:31:51 +0000 (14:31 +0100)]
libstdc++: Fix exposure of TU-local lambda in __detail::__func_handle_t.
The lambda is considered to be TU-local entity, use a named function
instead.
As drive-by, a functor stored inside __func_handle::_Inplace is renamed
to _M_fn, as we no longer limit the functor type to function pointers.
libstdc++-v3/ChangeLog:
* include/std/ranges (__func_handle::__select): Named function
extracted from local lambda.
(__detail::__func_handle_t): Define using __func_handle::__select.
(__func_handle::_Inplace): Raname _M_ptr to _M_fn.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Eric Botcazou [Wed, 19 Nov 2025 08:45:05 +0000 (09:45 +0100)]
ada: Couple of minor fixes for build-in-place calls in anonymous contexts
The current code does not deal with all the anonymous contexts uniformly,
since it potentially creates an activation chain and a master only in the
case of an actual in a call; moreover, the master is created in the scope
of the actual's type, instead of in the context of the call like the chain.
The change also aligns Make_Build_In_Place_Call_In_Anonymous_Context with
sibling routines by calling Make_Build_In_Place_Call_In_Object_Declaration
directly instead of letting the expander recursively do it. It also adds
a missing rewriting in Make_Build_In_Place_Iface_Call_In_Anonymous_Context.
gcc/ada/ChangeLog:
* exp_ch6.adb (Expand_Actuals): Do not create activation chain and
master for build-in-place calls here but...
(Make_Build_In_Place_Call_In_Allocator): Use Unqual_Conv.
(Make_Build_In_Place_Call_In_Anonymous_Context): ...here instead.
Call Make_Build_In_Place_Call_In_Object_Declaration directly.
(Make_Build_In_Place_Iface_Call_In_Anonymous_Context): ...and here
instead. Add missing rewriting of the call.
Eric Botcazou [Wed, 19 Nov 2025 07:39:20 +0000 (08:39 +0100)]
ada: Fix undefined reference with inline subprogram containing generic instance
The problem is that, for an inline subprogram declared in an instance, the
cross-unit inlining machinery does not have the body by the time it decides
to inline calls to the subprogram, because the instantiation of bodies is
deferred until the end of the compilation. So it cannot see whether this
body contains excluded declarations or statements by that time, typically
nested packages or instances thereof.
The fix is to check that Is_Inlined is still set on the subprogram before
passing it on to the back-end for cross-unit inlining. It also removes an
obsolete check that was done precisely there.
This also adjusts the description of the -gnatwp switch, which can be used
to get the reason why cross-inlining has failed, for example here:
g.ads:4:01: warning: in instantiation at generic_si.adb:60 [-gnatwp]
g.ads:4:01: warning: cannot inline "*" (nested package instantiation)
gcc/ada/ChangeLog:
PR ada/122574
* doc/gnat_ugn/building_executable_programs_with_gnat.rst (-gnatwp):
Replace reference to -gnatN with -gnatn and adjust accordingly.
* inline.adb: Remove clauses for Exp_Tss.
(Has_Initialized_Type): Delete.
(Add_Inlined_Subprogram): Test that the Is_Inlined flag is still set
on the subprogram.
* usage.adb (Usage): Adjust description of -gnatwp.
* gnat_ugn.texi: Regenerate.
projects / thirdparty / gcc.git / log
