Jakub Jelinek [Mon, 16 Mar 2026 07:06:52 +0000 (08:06 +0100)]
c++: Fix up sb as condition instantiation error-recovery [PR120039]
The following two testcases ICE during instantation.
Normally for the artificial var used for structured binding as condition
(which has NULL DECL_NAME) there is a DECL_EXPR which registers local
specialization and so tsubst_expr works fine.
But if there are errors while parsing the initializer, the VAR_DECL
has still NULL_TREE DECL_NAME, but error_mark_node TREE_TYPE and
when tsubst_expr is called on it, it falls back to calling lookup_name
(NULL_TREE) and ICEs on that.
The following patch fixes it by not calling lookup_name if DECL_NAME is
NULL.
2026-03-16 Jakub Jelinek <jakub@redhat.com>
PR c++/120039
PR c++/122559
* pt.cc (tsubst_expr) <case VAR_DECL>: Don't call lookup_name on
DECL_NAME (t) if it is NULL_TREE.
* g++.dg/cpp26/decomp28.C: New test.
* g++.dg/cpp26/decomp29.C: New test.
xtensa: constantsynth: Add new 2-insns synthesis method
This patch adds a new 2-instructions constant synthesis method:
- A positive integer value that, despite left-shifting the leading 0 bits,
becomes a negative number that still fits into a signed 12-bit
=> "MOVI(.N) Ax, simm12" + "SRLI Ax, Ax, 1...10"
fortran: Fix use-after-free in CLASS component error recovery [PR124482]
The error recovery added in r16-8021 (PR106946) freed CLASS container
symbols when removing invalid CLASS components from a derived type.
However, gfc_build_class_symbol reuses existing containers when multiple
components share the same class type and attributes. Freeing the
container for a failed component also invalidated it for previously
committed components, causing a use-after-free detectable with valgrind
and manifesting as a SEGV on Solaris/SPARC.
Fix by deferring CLASS container cleanup until after all failed
components are unlinked, then freeing the container only if no remaining
component still references it.
gcc/fortran/ChangeLog:
PR fortran/124482
* decl.cc (gfc_match_data_decl): Defer CLASS container cleanup
until after all failed components are unlinked. Check remaining
component list before freeing a shared container.
Signed-off-by: Christopher Albert <albert@tugraz.at>
François Dumont [Sat, 14 Mar 2026 13:34:29 +0000 (14:34 +0100)]
libstdc++: [_GLIBCXX_DEBUG] _M_invalidate_if incompatible with C++20 [PR124444]
__gnu_cxx::__scoped_lock cannot be instantiated in a C++20 constexpr function. Use
an intermediate method to avoid this situation.
libstdc++-v3/ChangeLog:
PR libstdc++/124444
* include/debug/safe_sequence.h (_Safe_sequence::_M_invalidate_if_impl): New.
(_Safe_sequence::_M_invalidate_if): Call later if not __is_constant_evaluated.
* include/debug/safe_sequence.tcc: Rename _M_invalidate_if into
_M_invalidate_if_impl and remove C++20 constexpr.
Jakub Jelinek [Sat, 14 Mar 2026 19:48:28 +0000 (20:48 +0100)]
c++: Ensure proper ordering of annotations in grokdeclarator [PR124399]
For the cases in the new test like
[[=1]] int a [[=2]], b [[=3]];
we want to order the =1 annotation before =2 or =3 because
https://eel.is/c++draft/meta.reflection#annotation-2.sentence-2
and =1 precedes =2 and =3.
The way we merge the attribute lists in grokdeclarator is done
for speed and memory efficiency though, so we attr_chainon
*attrlist (i.e. =1 above) after declarator->std_attributes
(i.e. =2 or =3 above). That has the advantage that we can keep
sharing the earlier *attrlist between multiple declarations, each one
will have its custom attributes at the start (if any) and then
a shared tail with the shared ones.
The following patch fixes it by checking if annotations are in
both lists (otherwise we keep doing what we've been doing before).
If they are in both, we chainon them the other way but of course
need to copy_list to unshare the shared one for that.
2026-03-14 Jakub Jelinek <jakub@redhat.com>
PR c++/124399
* decl.cc (grokdeclarator): If both *attrlist and
declarator->std_attributes list contain annotations, chainon
declarator->std_attributes to tail of copy_list (*attrlist)
rather than *attrlist to tail of declarator->std_attributes.
* g++.dg/reflect/annotations12.C: Uncomment two tests, remove
temporary test added until that is fixed.
* g++.dg/reflect/annotations13.C: New test.
Jose E. Marchesi [Sat, 14 Mar 2026 15:58:53 +0000 (16:58 +0100)]
a68: fix float standard conversion routine
This commit fixes the implementation of the `float' standard
conversion routine, by amending a typo that originates in the Revised
Report. It also makes the routine to properly handle short short and
short int arguments.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org
libga68/ChangeLog
* standard.a68.in (float): Fix typo from RR and handle short* int
arguments properly.
Jose E. Marchesi [Sat, 14 Mar 2026 15:57:08 +0000 (16:57 +0100)]
a68: fix string and character multiplication
This patch fixes the string operator for string and character
multiplication, to adjust to the semantics specified by the RR. In
particular, multiplying by a negative number or zero must result in
the empty string.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
* a68-low-strings.cc (a68_string_mult): Adjust to RR semantics for
negative or zero factor argument.
* ga68.texi (String operators): Adjust documentation accordingly.
gcc/testsuite/ChangeLog
* algol68/execute/mult-char-1.a68: Multiplying a char or string by
negative or zero factor results in the empty string.
* algol68/execute/mult-string-3.a68: Likewise.
* algol68/execute/mult-string-2.a68: Likewise.
* algol68/execute/mult-string-1.a68: Likewise.
Matthias Klose [Sat, 14 Mar 2026 12:23:47 +0000 (13:23 +0100)]
Ada: Fix libgnat.so link failure on systems with older glibc
It's a regression present on all active branches for older glibc versions,
where dladdr is still in the libdl.so library, and not included in libc.so
as in newer glibc versions.
Nathaniel Shead [Sat, 14 Mar 2026 00:25:47 +0000 (11:25 +1100)]
c++/modules: Fix crash on implicit redeclaration of ABI class types [PR124485]
The crash in the given testcase occurs because the fix for PR122053, r16-4228-gfa6544ef5f50a824cabeda4906453d4545fbf66f, added a call to
lazy_load_pending when doing push_tag, to prevent ICEs at least when
types are textually redefined in lieu of full PR99000 support.
But this means that we might not have loaded the declarations of the ABI
types in lookup_elaborated_type to merge them there yet, but still have
them by the time we get to check_module_override, causing errors, and
then an ICE because tinfo_base_init is not prepared for xref_tag to
fail.
It turns out that doing the lazy load in pushtag is too late; we replace
the decl, but we don't replace the type, and then we end up returning
the type that we were building anyway rather than the type we were
hoping to match against.
The reason I'd done it there originally is because that's the earliest
we have a decl to do lazy_load_pendings with, but it seems that instead
we should have another interface to lazy_load_pendings that can be used
if you already know the name and namespace of the entity that you're
keying too.
PR c++/124485
gcc/cp/ChangeLog:
* cp-tree.h (lazy_load_pendings): Declare new overload.
* module.cc (lazy_load_pendings): Define it.
* name-lookup.cc (lookup_elaborated_type): Load pending entities
with given name before doing namespace-scope lookup.
(pushtag): Remove no-longer-needed pending load.
gcc/testsuite/ChangeLog:
* g++.dg/modules/class-8_b.C: Adjusted expected behaviour.
* g++.dg/modules/pr124485_a.C: New test.
* g++.dg/modules/pr124485_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jakub Jelinek [Sat, 14 Mar 2026 08:52:42 +0000 (09:52 +0100)]
c++: Fix up partial instantiation of structured binding packs [PR124456]
The following testcase ICEs during partial instantiation of structured
binding pack. tsubst_pack_expansion assumed DECL_VALUE_EXPR
in that case will be TREE_VEC containing what should be expanded.
But when the initializer of the structured bindings is still type dependent,
we know neither the size of the sb pack nor its content, cp_finish_decomp
in that case doesn't set DECL_VALUE_EXPR to a TREE_VEC at all, but to
ARRAY_REF of the base and index within the structured binding (and pack if
any).
tsubst_pack_expansion can set arg_pack to NULL_TREE and in that case
else
{
/* We can't substitute for this parameter pack. We use a flag as
well as the missing_level counter because function parameter
packs don't have a level. */
gcc_assert (processing_template_decl || is_auto (parm_pack)
|| args == NULL_TREE);
unsubstituted_packs = true;
}
will trigger and later on in the function unsubstituted_packs is handled
properly.
So, the following patch makes sure to set arg_pack to NULL_TREE in that
case.
2026-03-14 Jakub Jelinek <jakub@redhat.com>
PR c++/124456
* pt.cc (tsubst_pack_expansion): For structured binding pack
with type dependent pack set arg_pack to NULL_TREE.
Nathaniel Shead [Fri, 13 Mar 2026 15:23:09 +0000 (02:23 +1100)]
c++/modules: Support loading a lazy member while trying to declare it [PR124478]
The testcase shows an issue where we end up indirectly loading a
special member function while we're attempting to lazily declare it.
This causes errors in the install_implicit_member because
CLASSTYPE_LAZY* has been cleared, so it assumes that the member exists
already.
There are a few options to approach this issue:
1. Remove the error when we fail with install_implicit_member, and just
silently assume that a case like this is happening. This should be
safe, but could make it harder to understand future issues in this
area.
2. Put all implicitly declared special members on the pending list for
the class type, and add calls to lazy_load_pendings at the start of
lazily_declare_fn and check if the functions have now been
provided. But this could unnecessarily bloat out the pending tables
as aggregate types used in lots of modules will add their special
members to every module's pending table.
3. Detect exactly this special case in implicitly_declare_fn and halt
processing. This should only impact lazily_declare_fn, but makes its
API more complex.
This patch takes option three. Just because we know that the function
has been lazily declared somewhere else doesn't mean we can easily find
its declaration, however; luckily nothing actually uses the return type
of lazily_declare_fn, so we can change that to void instead and save on
some effort.
PR c++/124478
gcc/cp/ChangeLog:
* cp-tree.h (lazily_declare_fn): Make return type void.
* method.cc (is_lazy_special_member): New function.
(implicitly_declare_fn): Bail early if we lazy loaded the member
we're trying to declare.
(lazily_declare_fn): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/modules/imp-member-6_a.C: New test.
* g++.dg/modules/imp-member-6_b.C: New test.
* g++.dg/modules/imp-member-6_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Andrew Pinski [Sat, 14 Mar 2026 00:09:49 +0000 (17:09 -0700)]
testsuite: make the prevent tailcall in pr17377.c more robust
With improvements (not actually implemented yet but shows up with LLVM),
the call in pr17377.c to prevent a tail call does not work. So
to make it more robust, we need to mark the variable x as being volatile.
Pushed as obvious after testing on x86_64-linux-gnu.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/pr17377.c: Mark global variable x
as volatile.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
But that new instruction no longer traps as it is load from the stack. So later on
purge_dead_edges removes the REG_EH_REGION note and the edge to the eh landing pad
but this is during find_many_sub_basic_blocks in split3 and nothing then removes the
unreachable basic blocks.
To fix this, instead of depending on a later pass to clean this up, cprop_hardreg
should call purge_all_dead_edges if non-call exceptions were enabled and then
also call cleanup_cfg (to remove the unreachable blocks).
Bootstrapped and tested on x86_64-linux-gnu and lightly tested for aarch64-linux-gnu.
PR rtl-optimization/124454
gcc/ChangeLog:
* regcprop.cc (pass_cprop_hardreg::execute): If something
changed and non-call exceptions is on, call purge_all_dead_edges
and cleanup_cfg.
gcc/testsuite/ChangeLog:
* gcc.dg/pr124454-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Jakub Jelinek [Fri, 13 Mar 2026 20:58:46 +0000 (21:58 +0100)]
libcpp: Fix up -MP for - input [PR105412]
For -MP we used to emit something like below in GCC 9 and earlier:
touch a.h; echo '#include "a.h"' | ./cc1 -quiet -E -M -MP -
-: /usr/include/stdc-predef.h a.h
/usr/include/stdc-predef.h:
a.h:
but since r10-205 we emit instead just
touch a.h; echo '#include "a.h"' | ./cc1 -quiet -E -M -MP -
-: /usr/include/stdc-predef.h a.h
a.h:
i.e. the rule for /usr/include/stdc-predef.h is removed. Similarly
with -nostdinc:
touch a.h; echo '#include "a.h"' | ./cc1 -quiet -E -nostdinc -M -MP -
-: a.h
a.h:
r10-205 changed that to:
touch a.h; echo '#include "a.h"' | ./cc1 -quiet -E -nostdinc -M -MP -
-: a.h
a.h:
The rationale for the change was
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-05/msg00323.html
where after the mkdeps.cc reimplementation it started ICEing on
- input (file->path[0] is "" in that case).
The problem is that by leaving out the "" dependency (which we then
in some cases indeed ignore) the -MP printing
if (CPP_OPTION (pfile, deps.phony_targets))
for (unsigned i = 1; i < d->deps.size (); i++)
fprintf (fp, "%s:\n", munge (d->deps[i]));
starts at d->deps[1] unconditionally and so ignores the first dependency
even when it is not the main file.
So, either we could just revert the r10-205 change and ensure we don't
ICE on it and keep ignoring it when it should be ignored, or the
following patch fixes it by not adding the "" dep, but remembering that
in that case we should start iterating from i = 0; and not from i = 1;
2026-03-13 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/105412
* files.cc (_cpp_stack_file): Call deps_add_dep even on
empty file path.
* mkdeps.cc (class mkdeps): Add first_phony_dep member.
(mkdeps::mkdeps ()): Initialize it to 1.
(deps_add_dep): When called first with "" argument, decrease
d->first_phony_dep to 0.
(make_write): For -MP iterate from d->first_phony_dep
rather than 1.
[PR117182, LRA]: Move point of skipping postponed insn
Working on PR117182 I found that a pseudo generated for save/restore
value around call is changed by equivalence which is constant as we
propagate equivalence for such pseudos to generate a better code. The
constant substitutes output of the save insn which can be changed to
memory containing constant by reload insn. We don't want this. The
patch fixes this.
gcc/ChangeLog:
PR target/117182
* lra-constraints.cc (curr_insn_transform): Don't change an output
operand by constant or invariant equivalence.
Andre Vieira [Fri, 13 Mar 2026 15:31:18 +0000 (15:31 +0000)]
arm: Add support for _BitInt(N)
This patch adds support for C23's _BitInt feature to the arm port.
gcc/ChangeLog:
* config/arm/arm.cc (TARGET_C_BITINT_TYPE_INFO): New Macro.
(arm_return_in_memory): Return true for any _BitInt(N) where N > 64.
(arm_needs_doubleword_align): Return true for any _BitInt(N) where N > 32.
(arm_bitint_type_info): New.
* config/arm/arm-protos.h (arm_bitint_type_info): New declaration.
libgcc/ChangeLog:
* config/arm/libgcc-bpabi.ver: Add new symbols.
* config/arm/t-softfp: Enable use of floatbitinthf and pass necessary options to build fp16.
Saurabh Jha [Thu, 12 Mar 2026 11:57:26 +0000 (11:57 +0000)]
aarch64: mingw: Fix _ARM_PCS_AAPCS64 [PR122953]
Windows platforms do not support the default procedure calling standard,
AAPCS64. So _ARM_PCS_AAPCS64 should not be set for Windows targets.
This fixes the setting of __ARM_PCS_AAPCS64 by making it conditional on
non-Windows targets.
PR target/122953
gcc/ChangeLog:
* config/aarch64/aarch64-c.cc
(TARGET_AARCH64_MS_ABI): Explicitly set it to 0 if not on mingw.
(aarch64_define_unconditional_macros): Remove __ARM_PCS_AAPCS64
from here.
(aarch64_update_cpp_builtins): Define __ARM_PCS_AAPCS64 if not
on Windows ABI.
---
Hey,
Regression tested on aarch64-linux-gnu and found no regressions.
Built for arch64-w64-mingw32, ran target dependent tests, and
found no regressions.
Jakub Jelinek [Fri, 13 Mar 2026 13:13:44 +0000 (14:13 +0100)]
tree-profile: Formatting fixes
On Fri, Mar 13, 2026 at 11:12:54AM +0100, Jørgen Kvalsvik wrote:
> > Note, big parts of tree-profile.cc now use some weird formatting, not GCC
> > style, indentation by 4 columns instead of 2, { on the same column as line
> > above it instead of 2 columns to the right, etc. I think it would be nice
> > to get that incrementally fixed.
>
> Yeah, since writing the MC/DC support it I've changed my setup to properly
> apply the GNU style, but I haven't wanted to make too much noise with
> patches for it. I can change the style incrementally whenever I pass over
> this, or maybe even a single pass that fixes all of it.
Given that it is so different from GNU style, incrementally adjusting it is
hard, if done incrementally it would mean usually reformat whole function
rather than just a few lines in it.
So I think it is better to change it once.
Here is my attempt to do so, fixed what I saw.
2026-03-13 Jakub Jelinek <jakub@redhat.com>
* tree-profile.cc (struct conds_ctx): Formatting fixes.
Rename B1, B2, G1, G2 and G3 members to b1, b2, g1, g2 and g3.
Adjust all uses.
(topological_cmp, topological_src_cmp, index_of, single_p,
single_edge, contract_edge_up): Formatting fixes.
(struct outcomes): Likewise.
(conditional_succs, condition_index, condition_uid,
masking_vectors, emit_assign, emit_bitwise_op): Likewise.
(make_top_index_visit, make_top_index): Likewise. Rename
L argument to l.
(paths_between): Formatting fixes.
(struct condcov): Likewise.
(cov_length, cov_blocks, cov_masks, cov_maps, cov_free): Likewise.
(find_conditions): Likewise. Don't start warning_at message with
uppercase letter.
(struct counters): Formatting fixes.
(find_counters, resolve_counter, resolve_counters,
instrument_decisions): Likewise.
(init_ic_make_global_vars): Comment formatting fixes.
(gimple_init_gcov_profiler): Formatting fixes.
Jakub Jelinek [Fri, 13 Mar 2026 13:11:57 +0000 (14:11 +0100)]
testsuite: Fix up gcc.dg/analyzer/ice-pr124375-1.c for 32-bit targets [PR124375]
On Wed, Mar 11, 2026 at 08:51:03PM -0400, David Malcolm wrote:
> * gcc.dg/analyzer/ice-pr124375-1.c: New test.
Unfortunately this test FAILs on i686-linux (and guess all
other sizeof (int) == sizeof (__PTRDIFF_TYPE__) targets).
The problem is that on x86_64-linux the warning is indeed emitted on the
__printf_buffer_offset = __printf_buffer_spec /* { dg-warning "stack-based buffer over-read" } */
line but on i686-linux (or x86_64-linux with -m32) on the
: step0_jumps[' '];
line. I think the difference is due to a useless cast missing on the latter
(int and __PTRDIFF_TYPE__ are either the same or uselessly compatible, so
there is no extra cast stmt which holds some particular location).
On lp64 the above is (int)(__print_buffer_spec ? &&do_form_unknown - &&do_form_unknown
: (__PTRDIFF_TYPE__) step0_jumps[' ']);
So, either we would need to expect this dg-warning for say lp64 only and
expect a dg-warning on the other line for ilp32 (but what to do for
non-lp64/ilp32 targets?), or limit the test to lp64 only, or the following
patch just forces it onto one line (we regularly go over the 80 line limit
in the testsuite, often by a lot) and then it really doesn't matter on which
column the warning is emitted.
Tested on x86_64-linux and i686-linux by making sure the pre r16-8019
still ICEd on it (both 64-bit and 32-bit) and that latest trunk warns
on the right line with both.
2026-03-13 Jakub Jelinek <jakub@redhat.com>
PR analyzer/124375
* gcc.dg/analyzer/ice-pr124375-1.c (__printf_buffer): Put the whole ?:
expression on a single line.
Jørgen Kvalsvik [Fri, 13 Mar 2026 09:45:26 +0000 (10:45 +0100)]
Count non-complex incoming edges [PR124462]
This is really a gcov/instrumentation bug, but it was filed under ipa.
We did filter out incoming complex edges, but didn't account for the
case where a block has multiple incoming edges without actually being a
conditional outcome. We also need to check that we have >= 2 incoming
edges after filtering out the complex ones to make sure it is a (short
circuiting) before we try to compute the masking table.
PR ipa/124462
gcc/ChangeLog:
* tree-profile.cc (masking_vectors): Skip blocks with less than
2 non-complex incoming edges.
* config/xtensa/xtensa.cc (constantsynth_pass1):
Change the comparison between src and SET_SRC(pat) to be performed
using rtx_equal_p rather than between references (pointer values)
directly, and adjust the destination of changes in validate_change
to eliminate the need to call gen_rtx_SET.
(constantsynth_pass2):
Fill in missing spacing in one place and changes dump file output
slightly.
xtensa: Rename/reduce from split_DI_SF_DF_const to convert_SF_const in 'xt_largeconst2'
The order in which split_DI_SF_DF_const in the target-specific pass
'xt_largeconst2' is processed has been changed to be after split2, so
that the splitting of D[IF]mode assignments to S[IF]mode by the split
parts of movd[if]_internal MD patterns is now performed earlier.
Therefore, in split_DI_SF_DF_const, there is no need to split the
allocation of the D[IF]mode constant, and only the function to change
the allocation of the SFmode constant to SImode remains.
This patch reduces the functionality of split_DI_SF_DF_const as
described above and renames it to convert_SF_const.
gcc/ChangeLog:
* config/xtensa/xtensa.cc (xtensa_split_operand_pair)
Move the common code from the split part of movd[if]_internal
MD patterns into this function, since this function is only
called from the split part of that patterns.
Also, during non-debug optimization, re-register new literal
pool entries with the split values themselves instead of
splitting the memory reference of the source numeric constant
placed in the pool.
(split_DI_SF_DF_const):
Rename to convert_SF_const and remove the split function of
D[IF]mode constant assignment.
(do_largeconst2):
Change the call from split_DI_SF_DF_const to convert_SF_const.
* config/xtensa/xtensa.md (movdi_internal, movdf_internal):
Reduce their split parts to just a call to xtensa_split_operand_pair.
xtensa: Minor changes to FPreg_neg_scaled_simm12b in 'xt_largeconst2'
Having a non-zero finite REAL_VALUE_TYPE is equivalent to having it be
normal, because REAL_VALUE_TYPE can only be zero, normal, infinity, or
NaN (see gcc/real.h).
gcc/ChangeLog:
* config/xtensa/xtensa.cc (FPreg_neg_scaled_simm12b_1):
Change the test to determine whether REAL_VALUE_TYPE is a non-
zero finite value to whether it is normal.
(FPreg_neg_scaled_simm12b):
Place the call to FPreg_neg_scaled_simm12b_1 last in the
expression to improve performance, and change the dump file
output slightly.
xtensa: Split target-specific pass 'xt_largeconst' into two
Previously, in 1eefa6e0c84e3008ed7ac44d08a8e5206038fb33 and a series of
subsequent commits, we added a target-specific optimization pass
'xt_largeconst' right after postreload to convert assignments of numeric
constants that don't fit into immediate fields to a more efficient
implementation than the standard one (references to literal pool entries),
if available.
However, the processes performed in this pass are a mixture of essential
and optional ones (such as optimizations), which is not good in terms of
structure or execution efficiency. Additionally, large numeric constant
assignments may be emitted after this pass, for example during stack frame
construction in function prologue.
To address these issues, this patch splits the processing in this pass
into two parts:
- places the mandatory processing (i.e., restoring delegitimized forms
of large numeric constant assignments to valid ones) immediately after
postreload, and
- places the rest, optional processing (i.e., optimizations) immediately
before regrename, which a reasonable location after pro_and_epilogue
and before sched2.
gcc/ChangeLog:
* config/xtensa/xtensa-passes.def (pass_xtensa_largeconst):
Rename to pass_xtensa_largeconst1.
(pass_xtensa_largeconst2): New target-specific pass.
* config/xtensa/xtensa-protos.h (make_pass_xtensa_largeconst):
Rename to make_pass_xtensa_largeconst1.
(make_pass_xtensa_largeconst2): New function prototype.
* config/xtensa/xtensa.cc (litpool_set_src_1):
Change to process large numeric constant assignments to DImode
as well as [SH]Imode.
(do_largeconst):
Rename it to do_largeconst1 and leave only the mandatory insn
transformation process.
(do_largeconst2): New function that inherits the optional insn
transformation processes from the old do_largeconst.
(rest_of_handle_largeconst):
Rename to rest_of_handle_largeconst1 and change to call
do_largeconst1.
(rest_of_handle_largeconst2): New function that calls
do_largeconst2.
(pass_data_xtensa_largeconst)
Rename to pass_data_xtensa_largeconst1.
(pass_xtensa_largeconst):
Rename to pass_xtensa_largeconst1 and change to call
rest_of_handle_largeconst1.
(pass_data_xtensa_largeconst2): New opt_pass data.
(pass_xtensa_largeconst2):
New rtl_opt_pass that runs rest_of_handle_largeconst2 when non-
debug optimizations are enabled.
(make_pass_xtensa_largeconst):
Rename to make_pass_xtensa_largeconst1.
(make_pass_xtensa_largeconst2): New function definition.
Jakub Jelinek [Fri, 13 Mar 2026 08:16:26 +0000 (09:16 +0100)]
i386: Fix up movrs<mode> suffix for -masm=intel [PR124461]
For movrs<mode> the insn was using insn suffix unconditionally, so
movrsl or movrsq even for -masm=intel, when gas expects movrs and derives
what size of insn it is from the operands.
There is no movrs effective target, so I've just used dg-do compile with
scan-assembler to test it instead of dg-do assemble.
2026-03-13 Jakub Jelinek <jakub@redhat.com>
PR target/124461
* config/i386/i386.md (movrs<mode>): Use <imodesuffix> only for
-masm=att, not for -masm=intel.
Jakub Jelinek [Fri, 13 Mar 2026 08:15:11 +0000 (09:15 +0100)]
c++: Include 26 in make check-c++-all
I'm not regularly using make check-c++-all (using
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 instead), so this is just
from curiosity.
I wonder if it is a good idea to leave 26 out (whether it is intentional
or not). I know impcx includes 26 plus -fimplicit-constexpr, but e.g.
given r16-7990 some tests will not be tested at all for 26 in that case and
others will test different behavior.
Jakub Jelinek [Fri, 13 Mar 2026 08:13:09 +0000 (09:13 +0100)]
c++: Fix up *display_string_of on anon union member [PR124388]
{,u8}display_string_of was printing any unnamed FIELD_DECL as
%T::<unnamed bit-field>, but anon union member is also unnamed and
is not a bit-field.
Fixed by printing %T::<anonymous union> for anon union NSDM and
%T::<unnamed member> for anything else unnamed (e.g. anon struct NSDM).
2026-03-13 Jakub Jelinek <jakub@redhat.com>
PR c++/124388
* reflect.cc (eval_display_string_of): Only print <unnmamed bit-field>
for DECL_UNNAMED_BIT_FIELD, for anon union print <anonymous union>,
otherwise print <unnamed member>.
* g++.dg/reflect/display_string_of1.C (S, NS5::S): Add
union { int a; }. Add static_assertions that the unnamed non-static
data member is printed as <unnamed member>.
* g++.dg/reflect/u8display_string_of1.C (S, NS5::S): Add
union { int a; }. Add static_assertions that the unnamed non-static
data member is printed as <unnamed member>.
fortran: Fix OpenMP iterator depend lowering for component arrays [PR102459]
When lowering an OpenMP depend clause with an iterator expression such as
x(j)%a, the front end currently looks only at the first REF_ARRAY to
decide between scalar-reference lowering and array-descriptor lowering.
For x(j)%a that first ref is the scalar base element x(j), but the full
expression is still the rank-1 component array a.
As a result, the code calls gfc_conv_expr_reference on an array-valued
expression, which later reaches gfc_conv_scalarized_array_ref without a
scalarizer state and ICEs.
Fix this by choosing the lowering path from the rank of the full
expression. Rank-zero expressions still use gfc_conv_expr_reference,
while array-valued expressions are lowered through gfc_conv_expr_descriptor.
Apply the same adjustment to the analogous depobj helper and add a
regression test for task depend clauses covering both x(j)%a and the
scalar control case x(j)%a(1).
gcc/fortran/ChangeLog:
PR fortran/102459
* trans-openmp.cc (gfc_trans_omp_clauses): Choose the scalar
reference path from the full expression rank rather than the first
array reference.
(gfc_trans_omp_depobj): Likewise.
gcc/testsuite/ChangeLog:
PR fortran/102459
* gfortran.dg/pr102459.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
Fortran: Allow task-reduction allocatable scalars without outer ref [PR102596]
OpenMP task reduction lowering can call gfc_omp_clause_default_ctor for
an allocatable scalar with outer == NULL_TREE. That is valid for scalar
allocatables that only need fresh storage allocation and do not need a
copied descriptor or allocatable-component walk.
The Fortran hook asserted unconditionally on outer != NULL_TREE, so
reduction(task, +:r) with an allocatable scalar ICEd during omplower.
Fix this by requiring outer only for the cases that actually use it:
descriptor-based allocatables and types with allocatable components.
Keep the assertion for those cases and allow NULL outer for plain scalar
allocatables. Add a regression test for the allocatable task-reduction
case.
gcc/fortran/ChangeLog:
PR fortran/102596
* trans-openmp.cc (gfc_omp_clause_default_ctor): Only require an
outer reference when the constructor path actually uses it.
gcc/testsuite/ChangeLog:
PR fortran/102596
* gfortran.dg/pr102596.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
Nathaniel Shead [Sun, 22 Feb 2026 15:20:38 +0000 (02:20 +1100)]
c++/reflection: Support members_of and imported namespace-scope names [PR124200]
namespace_members_of needs to iterate over all VECTOR_BINDINGs
for the given namespace, and handle deduplication.
PR c++/124200
gcc/cp/ChangeLog:
* name-lookup.h (walk_namespace_bindings): Declare.
* name-lookup.cc (walk_namespace_bindings): New function.
* reflect.cc (namespace_members_of): Use it.
gcc/testsuite/ChangeLog:
* g++.dg/modules/reflect-2_a.H: New test.
* g++.dg/modules/reflect-2_b.C: New test.
* g++.dg/modules/reflect-2_c.C: New test.
* g++.dg/modules/reflect-3_a.H: New test.
* g++.dg/modules/reflect-3_b.C: New test.
* g++.dg/modules/reflect-3_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Co-authored-by: Thomas Berger <loki+gcc@loki.codes> Reviewed-by: Jason Merrill <jason@redhat.com> Reviewed-by: Marek Polacek <polacek@redhat.com>
Nathaniel Shead [Sun, 8 Mar 2026 14:10:02 +0000 (01:10 +1100)]
c++/modules: Reparent linemaps for partition direct loads [PR124309]
The attached testcase failed because when part-11_d.C sees the import
of X through Z:part, the module's location is maintained as the indirect
(imported) location through Y that came first, but it is still promoted
to a direct import.
When part-11_e.C reads the module then it sees a direct import of X
through Z, but there is no valid source location for X in Z (because we
only kept the imported location) and so we report a bad CMI.
This fixes the issue by updating a module seen as direct for the first
time via a partition to reparent the module's location to where the
partition imported it from, so we properly process it as a direct
location that we need to write out, similarly to what we do when we
reimport an indirect module within the module purview.
PR c++/124309
gcc/cp/ChangeLog:
* module.cc (enum module_directness): Fix inconsistent
capitalisation.
(module_state::read_imports): Reparent module locations newly
seen as direct via partition.
gcc/testsuite/ChangeLog:
* g++.dg/modules/part-11_a.C: New test.
* g++.dg/modules/part-11_b.C: New test.
* g++.dg/modules/part-11_c.C: New test.
* g++.dg/modules/part-11_d.C: New test.
* g++.dg/modules/part-11_e.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
And then calls simplify_subreg on it.
simplify_subreg then sees it can remove the vec_concat as this is
the lower part and try to do `(subreg:DD (const_int -1 [0xffffffffffffffff]))`
but that is an invalid constant for DF64 so simplify_subreg rejects
that and returns NULL but there is code in simplify_subreg to create
a SUBREG then if the subreg validates. The problem is we are using DImode
for the inner mode and that validates but when gen_rtx_SUBREG is called
the inner mode of DImode is not there; only VOIDmode.
So the fix is to check for VOIDmode before the call to validate_subreg.
Bootstrapped and tested on x86_64-linux-gnu. And lightly tested for aarch64-linux-gnu.
PR rtl-optimization/123822
gcc/ChangeLog:
* simplify-rtx.cc (simplify_context::simplify_subreg): Check the
mode of the part to be non-VOIDmode before calling gen_rtx_SUBREG.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr123822-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
[PR124452, LRA]: Move point of skipping postponed insn
Patch for PR115042 skipped processing postponed insns after possible
generation of address reloads for the postponed insns. The reload
insns were lost in the code and this resulted in wrong code generation.
To fix this the patch moves skipping the postponed insn before any
reload generation.
gcc/ChangeLog:
PR rtl-optimization/124452
* lra-constraints.cc (curr_insn_transform): Move return on the
postponed insn before any reload generation.
Andrew Pinski [Sat, 7 Mar 2026 19:24:14 +0000 (11:24 -0800)]
testsuite/c++: Fix lifetime of lambda in pr103953.C [PR119930]
So in the end the problem with pr103953.C is the lifetime
of a lambda object is not extended past the statement.
With sane operator new we are able to delete stores using
that object as it is dead afterwards.
So the fix to the testcase is to make the lambda its own
object and then call it.
I also went back to check to make sure the original issue was
reproducible with this version too.
Tested on x86_64-linux-gnu and the testcase failure is gone.
PR testsuite/119930
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/torture/pr103953.C: Store the second
lambda into its own object to extend its lifeime.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
this patch is no longer needed to avoid the HAVE_GNU_AS/HAVE_GNU_LD
misdetections on Solaris. In fact, the few remaining uses of those
macros are expected to be removed in GCC 17 stage 1.
For the moment, I'd like to revert the patch above.
Bootstrapped without regressions no i386-pc-solaris2.11,
sparc-sun-solaris2.11, x86_64-pc-linux-gnu, and by comparing auto-host.h
in make configure-gcc for a cross to arm-none-eabi.
Rainer Orth [Thu, 12 Mar 2026 19:57:21 +0000 (20:57 +0100)]
testsuite: Remove xfails in gcc.dg/attr-alloc_size-11.c [PR80006]
As described in PR middle-end/80006, the gcc.dg/attr-alloc_size-11.c
test XPASSes on many targets:
XPASS: gcc.dg/attr-alloc_size-11.c missing range info for short (test for warnings, line 51)
XPASS: gcc.dg/attr-alloc_size-11.c missing range info for signed char (test for warnings, line 50)
Therefore, this patch removes the xfails.
Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and
x86_64-pc-linux-gnu.
Rainer Orth [Thu, 12 Mar 2026 19:51:02 +0000 (20:51 +0100)]
libphobos: Implement IeeeFlags on SPARC [PR123202]
The libphobos.phobos/std_math_hardware.d test FAILs on SPARC:
FAIL: libphobos.phobos/std_math_hardware.d (test for excess errors)
UNRESOLVED: libphobos.phobos/std_math_hardware.d compilation failed to produce executable
Rainer Orth [Thu, 12 Mar 2026 19:46:22 +0000 (20:46 +0100)]
libstdc++: Increase timeout for 23_containers/mdspan/submdspan tests [PR124290]
The 23_containers/mdspan/submdspan/selections tests often time out on
Solaris/SPARC:
WARNING: 23_containers/mdspan/submdspan/selections/left_padded.cc -std=gnu++26 (test for excess errors) program timed out.
FAIL: 23_containers/mdspan/submdspan/selections/left_padded.cc -std=gnu++26 (test for excess errors)
Even on an unloaded system, compilation takes ca. 4 minutes, close to
the default DejaGnu timeout of 5 minutes. Setting/increasing the
timeout factor to 2 was not enough, so this patch raises it to 4 for all
5 tests.
Tested on sparc-sun-solaris2.11 and x86_64-pc-linux-gnu.
Marek Polacek [Wed, 11 Mar 2026 17:28:30 +0000 (13:28 -0400)]
c++/reflection: class member access with [: T::BASELINK :] [PR124440]
Let
struct B { consteval virtual int fn() const { return 1; } };
struct D : B { consteval int fn() const override { return 2; } };
and consider
d.[:^^B::fn:]() // #1
d.[:^^B:]::fn() // #2
then #1 should yield 2 and #2 should yield 1: #1 doesn't count as
qualified name lookup and so should be treated as "d.fn()" where
lookup_vfn_in_binfo in build_over_call finds D::fn. But #2 is like
"d.B::fn()" which should prevent a virtual function call and we
should be calling B::fn.
We already handle this correctly outside of templates: finish_call_expr
only checks IDK to see if it should disallow_virtual, but in tsubst_expr
it looks at BASELINK_QUALIFIED_P, which is wrongly set for #1.
BASELINK_QUALIFIED_P is always set by adjust_result_of_q_name_lookup,
so cp_parser_postfix_dot_deref_expression should clear it for case #1.
With this patch, we only set BASELINK_QUALIFIED_P if qualifying_scope
was not null.
Unfortunately we can't avoid the adjust_result_ call because then
lookup_vfn_in_binfo gets a binfo that isn't BINFO_PRIMARY_P and it won't
find D::fn. It seems it is necessary to have that adjust_result_ ->
lookup_base adjustment.
And then tsubst_expr has to do the same thing for when we have
d.[:^^T::fn:]()
where T is a tparm that is substituted with B.
PR c++/124440
gcc/cp/ChangeLog:
* parser.cc (cp_parser_postfix_dot_deref_expression): Pass
parser->scope to adjust_result_of_qualified_name_lookup even
when splice_p. Assign the result of
adjust_result_of_qualified_name_lookup to name.
* pt.cc (tsubst_expr): Call adjust_result_of_qualified_name_lookup
for BASELINKs in splice-expressions.
* search.cc (adjust_result_of_qualified_name_lookup): Return early
if decl is not a BASELINK. If qualifying_scope is null, use decl's
binfo. Set BASELINK_QUALIFIED_P only if qualifying_scope wasn't
null.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/member21.C: Uncomment the commented out asserts.
Paul Thomas [Thu, 12 Mar 2026 17:50:55 +0000 (17:50 +0000)]
Fortran: Add missing deferred type PDT errors in allocate [PR115316]
2026-03-12 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/115316
* match.cc (spec_list_type): A version of gfc_spec_list_type,
which returns true if any of the LEN parameters are deferred.
(gfc_match_allocate): Use it to set saw_deferred if any of the
parameters of the allocate object are deferred.
gcc/testsuite/
PR fortran/115316
* gfortran.dg/pdt_87.f03: New test.
Paul Thomas [Thu, 12 Mar 2026 17:35:51 +0000 (17:35 +0000)]
Fortran: gfortran PDT component access [PR122696]
2026-03-12 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/122696
* resolve.cc (resolve_assoc_var): A generic function selector
must be resolved to a specific function before doing anything
more with the associate name.
gcc/testsuite/
PR fortran/122696
* gfortran.dg/pdt_89.f03: New test.
Steve Baird [Thu, 12 Mar 2026 17:18:36 +0000 (18:18 +0100)]
Ada: Fix Program_Error raised in a Bounded_Indefinite_Holders instance
If Ada.Containers.Bounded_Indefinite_Holders is instantiated with an
Element_Type that requires finalization, the declaration of a Holder
object with an explicit initial value may incorrectly raise Program_Error
during its elaboration.
gcc/ada/
PR ada/124016
* libgnat/a-cbinho.adb (Create_Subpool): Handle the case where
the type Holder_Subpool has nontrivial finalization. Declare the
local variable Subpool with its Import aspect specified (to avoid
unwanted finalization), and make corresponding changes in order to
initialize that variable.
* libgnat/s-stposu.ads (_Adjust_Clone): New procedure.
* libgnat/s-stposu.adb (_Adjust_Clone): New body.
Eric Botcazou [Thu, 12 Mar 2026 17:11:34 +0000 (18:11 +0100)]
Ada: Fix missing error for dangling pointer from access discriminant
This restores the original computation of the scope depth of the innermost
enclosing master of a given node and performs a couple of other cleanups.
Note that this has uncovered an issue in the ACATS c3a0025 test and the
change contains the modification that has been submitted to the ACAA.
gcc/ada/
PR ada/124369
* accessibility.adb (Accessibility_Message): Give an error instead
of a warning in an instance when No_Dynamic_Accessibility_Checks is
in effect.
(Innermost_Master_Scope_Depth): Restore the original computation of
the nearest enclosing dynamic scope.
* sem_attr.adb (Resolve_Attribute) <Attribute_Access>: Call the
Accessibility_Message routine in all cases to give accessibility
errors and do not return. Call the Static_Accessibility_Level
function in all cases to compute static accessibility levels.
Add guard before calling Prefix_With_Safe_Accessibility_Level.
Eric Botcazou [Thu, 12 Mar 2026 16:52:08 +0000 (17:52 +0100)]
Ada: Complete implementation of AI12-0402
This implements AI12-0402 in the function computing the accessibility level
of function calls in the general case, as opposed to the more specific case
of the RM 6.4.1(6.4) legality rule. This also removes a ??? note attached
to the handling of N_Assignment_Statement nodes in this function.
gcc/ada/
PR ada/124376
* accessibility.adb (Accessibility_Level): Minor formatting tweaks.
(Accessibility_Level.Function_Call_Or_Allocator_Level): Implement
AI12-0402. Reimplement the loop climbing up the parent chain to
find an object being initialized. Restrict the specific handling
of N_Assignment_Statement nodes to the anonymous access type case.
* doc/gnat_rm/implementation_of_ada_2022_features.rst: Adjust the
entries of AI12-0277, AI12-0345 & AI12-0372, add one for AI12-0402.
* gnat_rm.texi: Regenerate.
Martin Jambor [Thu, 12 Mar 2026 15:59:34 +0000 (16:59 +0100)]
ipa-prop: Skip analysis od static constructor entries with no index (PR124260)
PR 124260 is about dereferencing a NULL "index" tree when traversing
static constructors of global variables. As discussed in the bug, it
is unclear whether that is allowed but ObjC compiler creates these at
least on 32bit hosts. Ian plans to fix this in the FE in the next
stage1 but for this stage4, such entries can be easily skipped in
ipa-prop (too). The collected information is used for speculative
"devirtualization" ony and so if we miss a relevant entry, it may only
result in a "bad" decision whether to do that or not.
gcc/ChangeLog:
2026-03-11 Martin Jambor <mjambor@suse.cz>
PR objc/124260
* ipa-prop.cc (ipa_analyze_var_static_initializer): Skip a constructor
entry if its index is NULL.
Nathaniel Shead [Thu, 12 Mar 2026 13:47:36 +0000 (00:47 +1100)]
c++/modules: Support diagnostic classification changes in macros [PR124459]
Diagnostic classification changes via _Pragma can occur in macros, but
weren't taking effect in imported modules. The issue is that we were
reading the diagnostic classification map before we processed the macro
maps, which meant that all locations in macros were just falling back
to the abstract location of the module itself. Fixed by moving the
processing after we've read the macro maps.
PR c++/124459
gcc/cp/ChangeLog:
* module.cc (module_state::read_initial): Move
read_diagnostic_classification after read_macro_maps.
gcc/testsuite/ChangeLog:
* g++.dg/modules/warn-spec-4_a.C: New test.
* g++.dg/modules/warn-spec-4_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Nathaniel Shead [Mon, 2 Mar 2026 14:24:06 +0000 (01:24 +1100)]
c++/modules: Merge synthesized definitions of defaulted members [PR124311]
When a TU synthesizes a definition of a defaulted member function we
mark the TU that did this as the originating module, and so export it
from there. If this TU is imported into a module that already has a
declaration of this entity the declarations should be merged.
This patch fixes an issue where this merging was not occurring for
explicitly defaulted member functions, by checking DECL_DEFAULTED_FN
instead of just DECL_ARTIFICIAL.
PR c++/124311
gcc/cp/ChangeLog:
* module.cc (trees_in::key_mergeable): Check DECL_DEFAULTED_FN
instead of DECL_ARTIFICIAL.
gcc/testsuite/ChangeLog:
* g++.dg/modules/imp-member-5_a.C: New test.
* g++.dg/modules/imp-member-5_b.C: New test.
* g++.dg/modules/imp-member-5_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Nathaniel Shead [Sat, 7 Mar 2026 06:14:55 +0000 (17:14 +1100)]
c++/modules: Check for redeclarations of members in wrong module
We had missed checking whether we were doing an (outside class)
declaration of a member attached to the wrong module. This patch adds
those checks.
Within duplicate_decls/maybe_module_redeclare there's not a nice way to
do this because the attachment of a member is always calculated based on
the attachment of its owning type, which defeats the purpose here.
Instead I added the checks to start_decl and grokfndecl where we do
other various checks for if a redeclaration of a class member is legal.
gcc/cp/ChangeLog:
* decl.cc (start_decl): Check module_may_redeclare for members.
(grokfndecl): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/modules/class-12_a.C: New test.
* g++.dg/modules/class-12_b.C: New test.
* g++.dg/modules/class-12_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jakub Jelinek [Thu, 12 Mar 2026 14:23:48 +0000 (15:23 +0100)]
testsuite: Add testcase for bug fixed on trunk but not in 15/14 [PR124154]
This testcase used to be rejected before r16-970, but is accepted since
then. It used to be rejected in 15.1 and 14.2 too, but PR120123
r15-9757 and r14-11823 backports started to ICE on it instead.
In 13/12 it is still rejected, so not a regression there.
2026-03-12 Jakub Jelinek <jakub@redhat.com>
PR c++/124154
* g++.dg/cpp23/explicit-obj-lambda21.C: New test.
Nathaniel Shead [Sat, 7 Mar 2026 13:13:28 +0000 (00:13 +1100)]
c++/modules: Fix ICE in xref_basetypes on class redefinition
In a modules scenario, when we bail out of begin_class_definition due to
an error in module_may_redeclare, we return error_mark_node but had
already started building the class definition. When we re-enter
cp_parser_class_head we then successfully reach xref_basetypes, where we
then crash because the binfo slot is non-null.
This fixes the issue by moving the module_may_redeclare check earlier,
to before we call xref_basetypes, so that we don't start building the
definition if we were going to bail anyway. As a side effect this also
moves the check to before we update the DECL_SOURCE_LOCATION of the type
to the start of the class head, so that when we complain about
mismatched attachment we can point to the imported declaration rather
than referring to ourselves again.
Nathaniel Shead [Sat, 7 Mar 2026 15:48:10 +0000 (02:48 +1100)]
c++/modules: Don't create bindings for hidden friends [PR124390]
In r16-6343-gc368ea51b3bae27e3007b9bd89f6162c4c80259f we stopped walking
attached decls for a DECL_MODULE_KEYED_DECLS_P entity during dependency
gathering so that we didn't unnecessarily expose them if they weren't
going to be emitted anyway, and relied on walking the definition to
properly setup dependencies.
But the linked PR shows that if those attached decls instantiate a
template that pushes a hidden friend, they might be found anyway even if
we don't find them via the function definition, because we see the
hidden decls during add_binding_entity.
Apart from causing this crash, walking these hidden decls is both
pointless (hidden friends, if needed, will always be walked by their
owning class type, and ADL does not need namespace-scope bindings to
call them) and expensive, because this can cause a large swathe of other
otherwise discarded GMF entities to be marked as reachable.
This patch fixes the issue by not creating bindings for hidden friends.
Perhaps no hidden entities should have bindings at all, but doing this
causes make_dependency to break on the underlying alias decl for a
purview DECL_LOCAL_DECL_P when considering additional bindings that need
to be created, and I think we might need this to stay around so that we
can properly merge these decls anyway (though I haven't investigated
this yet). So this patch goes for a more minimal fix for now.
PR c++/124390
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_binding_entity): Don't create
bindings for hidden friends.
gcc/testsuite/ChangeLog:
* g++.dg/modules/friend-13.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jakub Jelinek [Thu, 12 Mar 2026 14:13:54 +0000 (15:13 +0100)]
c++: Fix up ICE check_out_of_consteval_use_r on some OpenMP clauses
When testing make check in libgomp with
RUNTESTFLAGS='--target_board=unix/-std=gnu++26/-freflection'
there are several ICEs. One is what I've just committed a fix for,
another one is on OpenMP clauses with iterators, where we use
TREE_VEC with 6 arguments as a temporary hack created by
cp_parser_omp_iterator, the first operand of that is an artificial
VAR_DECL for a variable that should be later on temporarily in scope
when handling the iterator during gimplification, then a few
expressions for low/high bound/step and finally the last one can
be a BLOCK covering the expression in the clause argument. Unfortunately
check_out_of_consteval_use_r just ICEs on it, BLOCK doesn't have TREE_TYPE.
While this could be handled specially for
OMP_CLAUSE with OMP_CLAUSE_{DEPEND,AFFINITY,TO,FROM,MAP} only and only for
TREE_VECs in TREE_LIST of their argument, just punting on BLOCK like the
patch below seems to be far easier.
Note, with these 2 changes no ICEs in libgomp make check left.
2026-03-12 Jakub Jelinek <jakub@redhat.com>
* reflect.cc (check_out_of_consteval_use_r): Don't walk BLOCK
subtrees.
Richard Biener [Thu, 12 Mar 2026 12:03:02 +0000 (13:03 +0100)]
bootstrap/124406 - fix lean LTO profiledboostrap
On s390x we are seeing CFG divergence when using the boostrap-lto-lean
config with profiledbootstrap which uses a non-LTO build for
stageprofile and a LTO build for stagefeedback. This is caused by
local IPA pure-const skipping some analysis only when not doing LTO.
The following removes this divergence. Proposed by Honza in the PR,
profilebootstrapped with bootstrap-lto-lean on s390x-linux-gnu.
PR bootstrap/124406
* ipa-pure-const.cc (skip_function_for_local_pure_const):
Do not analyze interposable functions when LTO is enabled.
H.J. Lu [Wed, 11 Mar 2026 15:43:01 +0000 (08:43 -0700)]
sh: Remove TARGET_PROMOTE_PROTOTYPES
TARGET_PROMOTE_PROTOTYPES is an optimization, not an ABI requirement.
TARGET_PROMOTE_FUNCTION_MODE should be used for ABI requirement, which
is properly defined for sh. Remove TARGET_PROMOTE_PROTOTYPES from sh.
Jakub Jelinek [Thu, 12 Mar 2026 11:39:43 +0000 (12:39 +0100)]
fortran: Fix UB in transfer_expr [PR124450]
trans-io.cc (transfer_array_component) calls transfer_expr with
NULL code:
transfer_expr (&se, &cm->ts, tmp, NULL, NULL_TREE);
I'm surprised it doesn't ICE in other spots that dereference
code->whatever but each one is guarded with some condition
that perhaps don't trigger in that case for some reason.
Anyway, the &code->loc case does trigger, it doesn't ICE, but
it is undefined behavior in the compiler when code is NULL,
and we'd crash if the where argument of 3*sizeof(void*) is
dereferenced. Code I've checked can handle NULL where though.
2026-03-12 Jakub Jelinek <jakub@redhat.com>
PR fortran/124450
* trans-io.cc (transfer_expr): If code is NULL, call
transfer_array_component with NULL where argument rather than
&code->loc.
Paul Thomas [Thu, 12 Mar 2026 11:21:23 +0000 (11:21 +0000)]
Fortran: gfortran PDT component access [PR97818]
2026-03-12 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/97818
* trans-decl.cc (gfc_trans_deferred_vars): Make sure that the
result symbol is referenced before allocating parameterized
components.
gcc/testsuite/
PR fortran/97818
* gfortran.dg/pdt_88.f03: New test.
Philipp Tomsich [Mon, 23 Feb 2026 19:22:03 +0000 (20:22 +0100)]
fold-mem-offsets: Clarify why do_analysis pre-marks the memory insn
The bitmap_set_bit call before fold_offsets in do_analysis is
intentional: fold_offsets requires all uses of a definition to already
be in can_fold_insns before it will mark the definition as foldable.
Pre-marking the memory instruction (which is the root use) is necessary
for its address definitions to pass this check during the DFS.
Replace the generic comment with one that explains this dependency.
Jonathan Wakely [Wed, 11 Mar 2026 21:22:12 +0000 (21:22 +0000)]
libstdc++: Fix mingw-w64 build due to __max macro
The stdlib.h header on mingw defines a function-like macro called __max,
which causes an error here:
include/format:3785:55: error: macro '__max' requires 2 arguments, but only 1 given
3785 | iter_difference_t<_OutIter> __max(_M_max);
We have lots of existing variables called __max, but this is the only
case that uses direct-initialization and so interferes with the
function-like macro in stdlib.h
The fix applied here is just to rename the variable. We can't use
direct-list-initialization because the conversion from size_t to the
difference type would be narrowing. We prefer not to use
copy-initialization so that conversion to the difference type is
explicit not implicit.
Andrew Pinski [Wed, 11 Mar 2026 21:41:31 +0000 (14:41 -0700)]
symtab: Fix init and fini priority to reset to default [PR120030]
Right now if try to reset the priority of a constructor to the
default (65535), there is an ICE.
To fix this the assert is wrong and intead we should check
if the priority is already the default if not then we should
just update it.
Bootstrapped and tested on x86_64-linux-gnu.
PR middle-end/120030
gcc/ChangeLog:
* symtab.cc (symtab_node::set_init_priority): Better
handle the case of setting the priority back to default.
(cgraph_node::set_fini_priority): Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/constructor-2.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Again while looking into PR 120030, there was no documentation
of what it means to have multiple constructor/destructor attributes
on the same function. Basically the last priority wins.
gcc/ChangeLog:
* doc/extend.texi (constructor/destructor): Add documentation
about multiple attributes here.
Andrew Pinski [Wed, 11 Mar 2026 21:29:20 +0000 (14:29 -0700)]
doc/extend: Document constructor/destructor priority when none is supplied
Noticed while working on PR 120030, the priority/order of constructor/destructor
without an argument is not documented.
This adds that the default priority is 65535 (last in order).
gcc/ChangeLog:
* doc/extend.texi (constructor/destructor): Document
the priority when none is supplied.
Jakub Jelinek [Thu, 12 Mar 2026 08:09:42 +0000 (09:09 +0100)]
openmp, c++: Fix up TREE_TYPE of OMP_TASK
I've made a typo a few years ago and used void_node instead of void_type_node
as TREE_TYPE of OMP_TASK in the taskwait depend case. This got later
on copied also for dispatch.
With reflection this leads to ICEs (but guess except for the testcase
we should also backport it to release branches).
2026-03-12 Jakub Jelinek <jakub@redhat.com>
* parser.cc (cp_parser_omp_taskwait): Set TREE_TYPE of OMP_TASK
to void_type_node rather than void_node.
(cp_parser_omp_dispatch): Likewise.
Jakub Jelinek [Thu, 12 Mar 2026 07:50:35 +0000 (08:50 +0100)]
libstdc++: Use CTAD for span in std::define_static_object [PR124443]
The standard in https://eel.is/c++draft/meta.reflection#meta.define.static-17
uses CTAD for span but we were avoiding that and using span<const _Up>
instead.
2026-03-12 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/124443
* include/std/meta (std::define_static_object): Use CTAD for span.
Jakub Jelinek [Thu, 12 Mar 2026 07:48:47 +0000 (08:48 +0100)]
c++: Support proxy iterators in reflection get_range_elts [PR124425]
I've punted up on proxy iterators because I didn't know how to construct
a test for those.
The following patch adds support for thosse. Besides converting those
to valuet if needed and for classes making sure they live in a TARGET_EXPR
where they can be subsequently destructed, the patch adds
CLEANUP_POINT_EXPRs around the deref and inc expressions such that the
TARGET_EXPRs in those expressions are immediately destructed after returning
what we need.
cmp doesn't need that because
cmp = condition_conversion (cmp);
already adds that.
Without the CLEANUP_POINT_EXPRs stuff is destructed (and marked as if out of
lifetime) only in some CLEANUP_POINT_EXPR surrounding the metafn call, which
is certainly too late for stuff that is reentered and left again in every
iteration.
I wrongly thought I'd need to duplicate the first part of CLEANUP_POINT_EXPR
handling in reflect.cc (which is complicated because struct constexpr_ctx
is only defined in constexpr.cc), then cxx_eval_constant_expression
e.g. deref and then duplicate the second part of CLEANUP_POINT_EXPR
handling, but it seems that the CLEANUP_POINT_EXPR evaluation just returns
what was returned from the recursive call on its operand, which is I think
exactly what we need.
This change broke 2 testcases, reflect_constant_array4.C and
define_static_array4.C, but IMHO correctly so, apparently what I had
there was creating std::pair<const int &, const int &> with references
to something that should have been immediately destructed in each iteration.
So, the patch fixes those tests to use std::pair<int, int> instead.
2026-03-12 Jakub Jelinek <jakub@redhat.com>
PR c++/124425
* reflect.cc (get_range_elts): Handle proxy iterators. Call
fold_build_cleanup_point_expr on both deref and inc.
* g++.dg/reflect/define_static_array4.C: Enable commented out
static_asserts and fix up the first one.
(as_pair): Make sure to return std::pair <int, int>.
* g++.dg/reflect/reflect_constant_array4.C: Enable commented out
static_asserts and fix up the first one.
(as_pair): Make sure to return std::pair <int, int>.
* g++.dg/reflect/reflect_constant_array7.C: New test.
* g++.dg/reflect/reflect_constant_array8.C: New test.
Nathaniel Shead [Wed, 11 Mar 2026 12:21:02 +0000 (23:21 +1100)]
c++/modules: Allow merging members of instantiations attached to named modules [PR124431]
The crash in the linked PR occurs because we treat all entities attached
to a (different) named module as being unmergeable, and so end up with
two different FIELD_DECLs for the member of a type.
But templates can be instantiated or specialised in any module, not just
the module they originated from, but are still considered attached to
that named module. It seems that we already handle class-scope
VAR_DECL, FUNCTION_DECL, TYPE_DECL, and TEMPLATE_DECL correctly by using
a MK_decl_spec or MK_type_spec merge kind, but FIELD_DECLs and
CONST_DECLs are not depended upon separately and so never get
MK_template_mask specs.
For these cases I think we can always rely on the container being
accurate and having its fields already setup, so this patch fixes the
issue by allowing non-unique merge kind for decls with a template
specialisation container of code TYPE_DECL.
PR c++/124431
gcc/cp/ChangeLog:
* module.cc (trees_in::key_mergeable): Allow merging members of
template specialisations.
gcc/testsuite/ChangeLog:
* g++.dg/modules/merge-21_a.C: New test.
* g++.dg/modules/merge-21_b.C: New test.
* g++.dg/modules/merge-21_c.C: New test.
* g++.dg/modules/merge-21_d.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Fortran: Fix ICE after rejected CHARACTER duplicate declaration [PR82721]
When a CHARACTER declaration is rejected because the symbol already has
a different basic type, declaration parsing may already have created a
fresh gfc_charlen node for the rejected entity. reject_statement()
undoes symbol-table changes, but it does not roll back the namespace
charlen list, so the stale len(...) expression can survive and later be
resolved through dangling symtree pointers, causing corrupted
diagnostics or an ICE.
Fix this in build_sym by discarding only the unattached gfc_charlen
node created for the rejected declaration before it is ever attached to
any surviving symbol. Keep shared charlen nodes intact so other
invalid-code diagnostics still see the state they expect. Also add a
regression test that uses MALLOC_PERTURB_ to make the old crash
reproducible.
gcc/fortran/ChangeLog:
PR fortran/82721
* decl.cc (discard_pending_charlen): New helper.
(build_sym): Discard unattached CHARACTER length nodes when
gfc_add_type rejects the declaration.
gcc/testsuite/ChangeLog:
PR fortran/82721
* gfortran.dg/pr82721.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
Andrew Pinski [Wed, 11 Mar 2026 05:28:43 +0000 (22:28 -0700)]
riscv/docs: Increment the required binutils to 2.40 [PR124409]
GCC has not able to build with binutils 2.30 due to the requirement
of needing zmull support. This changes the documentation to tbe
first binutils release that supported zmull.
PR target/124409
gcc/ChangeLog:
* doc/install.texi: Increment the required binutils for
riscv to 2.40.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Fortran: Fix ICE on invalid CLASS component in derived type [PR106946]
When a CLASS component declaration inside a derived type has a syntax
error (for example, a missing comma), gfc_build_class_symbol creates a
CLASS container symbol outside the undo mechanism. Error recovery then
frees the referenced type but leaves the CLASS container orphaned with
dangling pointers, leading to an ICE during later resolution.
Fix this by removing CLASS components created during a failed data
declaration from the derived type component chain, deleting their
namespace symtree entries only when they are still present, releasing
the CLASS container symbol, and freeing the component itself. Also
expand the regression coverage to exercise allocatable and pointer CLASS
declarations, including a valid component followed by a bad one.
gcc/fortran/ChangeLog:
PR fortran/106946
* decl.cc (gfc_match_data_decl): Remove CLASS components added by a
failed declaration in a derived type, and guard symtree deletion.
* gfortran.h (gfc_free_component, gfc_delete_symtree): Declare.
* symbol.cc (gfc_free_component): New function.
(free_components): Use it.
(gfc_delete_symtree): Make non-static.
gcc/testsuite/ChangeLog:
PR fortran/106946
* gfortran.dg/pr106946.f90: Cover allocatable and pointer CLASS
declarations, including a valid component followed by a bad one.
Signed-off-by: Christopher Albert <albert@tugraz.at>
David Malcolm [Thu, 12 Mar 2026 00:45:29 +0000 (20:45 -0400)]
analyzer: fix false +ves when testing <stdbool.h>/_Bool values [PR124451]
PR analyzer/124451 reports false positives from -Wanalyzer-malloc-leak
when using inverted "bool" values to track whether an allocation
happened.
The root cause is that with _Bool, the inversion is a bitwise not,
and this leads to the test of the condition against 0 to not be
recognized by malloc_state_machine::on_condition. Hence on_condition
fails to transition the state machine for the pointer from "unchecked"
to "null" or "nonnull", leaving it in the "unchecked" state.
This patch generalizes the folding logic in the analyzer that folds
"!(x CMP y)" => "x !CMP y"
so that it also folds
"~(x CMP y)" => "x !CMP y"
when the bitwise not is on a boolean type, fixing the false positives.
gcc/analyzer/ChangeLog:
PR analyzer/124451
* region-model-manager.cc
(region_model_manager::maybe_invert_comparison_in_unaryop): New,
adapted from...
(region_model_manager::maybe_fold_unaryop): ...here, splitting out
the comparison inversion case for TRUTH_NOT_EXPR. Add a case for
BIT_NOT_EXPR, reusing the inversion logic when dealing with
boolean types.
* region-model-manager.h
(region_model_manager::maybe_invert_comparison_in_unaryop): New decl.
gcc/testsuite/ChangeLog:
PR analyzer/124451
* gcc.dg/analyzer/conditionals-pr124451-_Bool.c: New test.
* gcc.dg/analyzer/conditionals-pr124451-enum.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Thu, 12 Mar 2026 00:45:29 +0000 (20:45 -0400)]
analyzer: fix ICE on computed goto [PR124375]
gcc/analyzer/ChangeLog:
PR analyzer/124375
* ops.cc (ggoto_edge_op::apply_constraints): Ensure that we write
back a rejected_constraint if the edge is infeasible.
* region-model.cc (region_model::add_constraint): Convert
rejected_op_constraint from tree to const svalue *.
(rejected_op_constraint::dump_to_pp): Likewise.
* region-model.h (class rejected_op_constraint): Likewise.
gcc/testsuite/ChangeLog:
PR analyzer/124375
* gcc.dg/analyzer/ice-pr124375-1.c: New test.
* gcc.dg/analyzer/ice-pr124375-2.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Thu, 12 Mar 2026 00:45:29 +0000 (20:45 -0400)]
analyzer: fix ICE on effective modulo by zero [PR124433]
gcc/analyzer/ChangeLog:
PR analyzer/124433
* region-model-manager.cc
(region_model_manager::maybe_fold_binop): When checking for
division by zero, use the value range of the divisor, rather
than merely checking for constant 0.
* region-model.cc (region_model::get_gassign_result): Likewise.
gcc/testsuite/ChangeLog:
PR analyzer/124433
* gcc.dg/analyzer/divide-by-zero-ice-pr124433.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Marek Polacek [Sun, 8 Mar 2026 16:34:30 +0000 (12:34 -0400)]
c++: error routines re-entered with uneval lambda [PR124397]
As discussed in
<https://gcc.gnu.org/pipermail/gcc-patches/2026-March/710075.html>
we shouldn't override complain with tf_warning_or_error when we are
emitting cp_printer diagnostics. We had no way to check that so
this patch adds emitting_diagnostic_p.
PR c++/124397
gcc/cp/ChangeLog:
* pt.cc (tsubst_lambda_expr): Don't override complain when emitting
diagnostics.
fortran: Fix mixed ENTRY union ABI under -ff2c [PR95338]
Mixed ENTRY masters store each result in a shared union. Under -ff2c,
default REAL entries use the C double ABI even though their Fortran result
symbols remain default REAL. Building the union directly from the Fortran
result symbols therefore gives the entry wrapper a real(kind=8) return type
but leaves the master union field at real(kind=4), which later trips the
GIMPLE verifier with a non-trivial conversion in COMPONENT_REF.
Build the mixed ENTRY union fields from the ABI return type instead, so
default REAL entries under -ff2c contribute a real(kind=8) field. Add a
regression test for the original mixed INTEGER/REAL ENTRY reproducer.
gcc/fortran/ChangeLog:
PR fortran/95338
* trans-types.cc (gfc_get_entry_result_type): New helper to use the
ABI return type for mixed ENTRY union fields.
(gfc_get_mixed_entry_union): Use it for each entry result field.
gcc/testsuite/ChangeLog:
PR fortran/95338
* gfortran.dg/pr95338.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
Marek Polacek [Mon, 9 Mar 2026 15:40:54 +0000 (11:40 -0400)]
c++: ICE with structured bindings and arrays [PR120285]
In r15-3933 I started using a CONSTRUCTOR to signal direct-init
to build_vec_init rather than a TREE_LIST. That broke
struct S {
int a = 1;
};
void foo() {
S arr[2];
auto [x, y](arr);
}
because we pass that new CONSTRUCTOR not to build_vec_init but to
build_aggr_init which then crashes in digest_init_r because the
new CONSTRUCTOR wasn't reshaped. It should work to reshape it if
its type is CP_AGGREGATE_TYPE_P but it might be safer to resort
back to building up a list if we're not going to go to build_vec_init.
PR c++/120285
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Only build up a CONSTRUCTOR for
arrays, otherwise use a TREE_LIST like prior to r15-3933.
Jakub Jelinek [Wed, 11 Mar 2026 16:28:58 +0000 (17:28 +0100)]
genautomata: Support INSN_UIDs up to INT_MAX-1 [PR124436]
With --param=min-nondebug-insn-uid= parameter one can force really large
INSN_UIDs even in moderately large functions.
Obviously the compiler will break badly if INSN_UID (which is host int)
wraps around, but in dfa_insn_code_enlarge it actually breaks already
when INSN_UID reaches INT_MAX / 2 + 1, because it tries to resize
vector to twice the max INSN_UID and overflows (UB on the compiler side
and then trying to allocate 0xfffffffe00000001-ish bytes).
The following patch fixes it by making sure not to overflow and cap
the allocation size at INT_MAX (that means even maximum INSN_UID INT_MAX
will not work properly, but just reaching that is highly undesirable
anyway). Alternatively dfa_insn_codes_length could be e.g. HOST_WIDE_INT
and we could just use HOST_WIDE_INT_C (2) * uid, but then we'd allocate
parts of vector for something that we really won't use anyway.
Of course, it is really bad idea to use
--param=min-nondebug-insn-uid=1073741824
or even huge numbers several times smaller than that, because the compiler
often allocates arrays sized by maximum INSN_UID, so e.g. compiling empty
function on cross to mips64-linux with that argument needed around 38GiB
of RAM.
2026-03-11 Jakub Jelinek <jakub@redhat.com>
PR target/124436
* genautomata.cc (output_dfa_insn_code_func): Use
MIN (INT_MAX, 2U * uid) instead of 2 * uid in dfa_insn_code_enlarge.
This commit adds three variants of this test case with options that
introduce more predictability to code generation. This will make it less
probable that these tests will break with any other future change. The
options used are:
1. -fno-section-anchors
2. -mcmodel=tiny
3. -mcmodel=small.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/mingw/variadic_hva.c: Deleted and created
three variants.
* gcc.target/aarch64/mingw/variadic_hva1.c: Derived from
variadic_hva.c and compiled with option -fno-section-anchors.
* gcc.target/aarch64/mingw/variadic_hva2.c: Derived from
variadic_hva.c and compiled with option -mcmodel=tiny.
* gcc.target/aarch64/mingw/variadic_hva3.c: Derived from
variadic_hva.c and compiled with option -mcmodel=small.
Marek Polacek [Mon, 9 Mar 2026 21:30:26 +0000 (17:30 -0400)]
c++/reflection: fix for substituting ^^T::mem [PR124331]
In compare11.C, the static_assert was wrongly failing because
compare_reflections got a FIELD_DECL and COMPONENT_REF for ^^S::mem.
We shouldn't have created the COMPONENT_REF. So this patch avoids
creating the COMPONENT_REF by avoiding the finish_qualified_id_expr
call in tsubst_qualified_id when processing a REFLECT_EXPR.
Happily, it fixed some other issues too.
Unfortunately, I found another issue (PR124440) while trying to test
this patch more extensively. I plan to fix that separately next.
PR c++/124331
gcc/cp/ChangeLog:
* pt.cc (tsubst_qualified_id): New name_lookup_p parameter. Don't
call adjust_result_of_qualified_name_lookup and
finish_qualified_id_expr if name_lookup_p is false.
(tsubst_expr) <case REFLECT_EXPR>: Handle SCOPE_REF specially by
calling tsubst_qualified_id with name_lookup_p=false.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/expr13.C: Uncomment the commented out assert.
* g++.dg/reflect/serialize2.C: Replace #if 0 with #ifdef.
* g++.dg/reflect/compare11.C: New test.
* g++.dg/reflect/member21.C: New test.
* g++.dg/reflect/serialize3.C: New test.
When splitting out store_field_updates_msb_p, r16-7265-ga9e48eca3a6eef
accidentally replaced GET_MODE_BITSIZE with GET_MODE_SIZE.
A matching rename of to_size to to_bitsize would have overflowed a line,
so it seemed worth breaking the endian cases apart.
gcc/
PR middle-end/124435
* expr.cc (store_field_updates_msb_p): Use GET_MODE_BITSIZE
instead of GET_MODE_SIZE. Handle the two endiannesses separately.
gcc/testsuite/
PR middle-end/124435
* gcc.dg/torture/pr124435.c: New test.
projects / thirdparty / gcc.git / log
