This test crashed until r16-7330. The errors are expected.
Let's make sure the crash doesn't come back.
PR c++/123440
gcc/testsuite/ChangeLog:
* g++.dg/reflect/extract10.C: New test.
So delete_insn_and_edges was added explicitly to solve the problem of having
to cleanup the dead eh edges when a load becomes dead (non-trapping in this case).
This moves the one call to delete_insn in cprop_hardreg over to use delete_insn_and_edges
to fix this case.
Basically we copyprop the sp register into a memory load. This memory load is normally
dead way before but with non-call eh and -fno-delete-dead-exceptions, it is alive until
cprop_hardreg. After thie copy prop of the sp register into the memory address of the load,
the load becomes non-trapping and is allowed to be deleted. Except we don't remove the eh edges
because cprop_hardreg only called delete_insn. So this updates the call to delete_insn_and_edges
which removes the eh edges.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR rtl-optimization/116053
gcc/ChangeLog:
* regcprop.cc (copyprop_hardreg_forward_1): Use delete_insn_and_edges
instead of delete_insn.
gcc/testsuite/ChangeLog:
* gcc.dg/pr116053-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
In this test case, LRA reloads arg push insn but does not move original
REG_ARGS_SIZE note to the reload insn which becomes a new arg push. The
patch fixes it.
gcc/ChangeLog:
PR rtl-optimization/120169
* lra-int.h (lra_process_new_insns): Modify the prototype.
* lra.cc (lra_process_new_insns): Add arg fixup_reg_args_size with
implicit value. Move REG_ARGS_SIZE note if necessary.
* lra-constraints.cc (curr_insn_transform): Pass the new arg value.
gcc/testsuite/ChangeLog:
PR rtl-optimization/120169
* gcc.target/m68k/pr120169.c: New.
The `amdgcn' target is not supported by GAS or LD, so disable building
in the respective subdirectories, removing configuration errors such as:
This target is no longer supported in gas
make[1]: *** [Makefile:5473: configure-gas] Error 1
and:
*** ld does not support target amdgcn-unknown-none
*** see ld/configure.tgt for supported targets
make[1]: *** [Makefile:6968: configure-ld] Error 1
in builds where no explicit `--disable-gas' and `--disable-ld' options
have been used with the top-level `configure' script. Users must not
have to disable features selected by default to get a working
configuration.
/
* configure.ac <amdgcn-*-*> (noconfigdirs): Add `ld' and `gas'.
* configure: Regenerate.
Most other spots inthe C FE which change type of some VAR_DECL
through complete_array_type call relayout_decl to fix up DECL_MODE
etc., but build_compound_literal strangely does not.
It has layout_decl (decl, 0); call later on but I think that is
quite useless given that already the build_decl call earlier
calls that and so the second layout_decl probably does nothing
most of the time.
On the following testcase, the compound literal VAR_DECL has
BLKmode from the time it had incomplete array type and isn't
changed to DImode that the completed type has and asm stmt
expansion is unhappy about that.
Fixed thusly.
2026-02-18 Jakub Jelinek <jakub@redhat.com>
PR c/123365
* c-decl.cc (build_compound_literal): Call relayout_decl
after completing the type.
* gcc.c-torture/compile/pr123365.c: New test.
When we search for a point in an inseration candidate block that has
incoming live call clobbered regs we look for REG_DEAD notes of
those and indication of FLAGS reg becoming live. But we consider
insns like
(insn 807 805 6 2 (parallel [
(set (subreg:SI (reg:HI 509) 0)
(lshiftrt:SI (reg:SI 514)
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) "/home/packages/tmp/onednn-3.9.1+ds/src/cpu/x64/brgemm/jit_brgemm_amx_uker.cpp":1891:25 1213 {*lshrsi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:SI 514)
(nil))))
making the FLAGS_REG live despite the REG_UNUSED note or the setter
being a CLOBBER. The following optimizes this by in turn honoring
REG_UNUSED for FLAGS_REG, pruning it immediately again.
This reduces required expensive iteration to other candidate BBs,
reducing compile-time for the testcase in the PR from hours to 6s.
PR target/123137
* config/i386/i386-features.cc (ix86_emit_tls_call): Improve
local FLAGS_REG liveness calculation.
* g++.dg/torture/pr124137.C: New testcase.
[bit.cast]/2: Mandates: Neither To nor From are consteval-only types
but we are not checking this, so the attached test compiled. I'm
adding the check into cp_build_bit_cast rather than <bit> so that
we detect this even for __builtin_bit_cast.
PR c++/124096
gcc/cp/ChangeLog:
* semantics.cc (cp_build_bit_cast): Check that neither argument is
consteval-only.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/bit_cast.C: New test.
Reviewed-by: Jakub Jelinek <jakub@redhat.com>
Given the release of relevant lmvec suport, the test's expected
failure is no longer satisfied as we are now able to emmit masked
calls to math functions, in this case expf.
We therefore change the xfail to a pass and, while at it, fix the
testism in the test, where temporary names had previously been
hardcoded.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-fncall-mask-math.c: Fix test.
r16-3677 extended avx_vpermilp_parallel so that it handles also V8DImode
(among others) and broke this testcase.
For V8DFmode the bug existed there already since r0-127405 which extended
avx_vpermilp_parallel to handle V8DFmode.
For V16SImode/V16SFmode I think the code is correct, in that case it can
for V4SImode/V4SFmode choose any permutation it wants and the
V8S{I,F}mode and V16S{I,F}mode cases before FALLTHRU verify the upper lanes
match those lower ones.
For V[48]D[IF]mode the function uses different checking, where it checks
each pair of ipar separately:
case E_V8DFmode:
case E_V8DImode:
/* In the 512-bit DFmode case, we can only move elements within
a 128-bit lane. First fill the second part of the mask,
then fallthru. */
for (i = 4; i < 6; ++i)
{
if (ipar[i] < 4 || ipar[i] >= 6)
return 0;
mask |= (ipar[i] - 4) << i;
}
for (i = 6; i < 8; ++i)
{
if (ipar[i] < 6)
return 0;
mask |= (ipar[i] - 6) << i;
}
/* FALLTHRU */
case E_V4DFmode:
case E_V4DImode:
/* In the 256-bit DFmode case, we can only move elements within
a 128-bit lane. */
for (i = 0; i < 2; ++i)
{
if (ipar[i] >= 2)
return 0;
mask |= ipar[i] << i;
}
for (i = 2; i < 4; ++i)
{
if (ipar[i] < 2)
return 0;
mask |= (ipar[i] - 2) << i;
}
break;
so that it directly computes corresponding mask bit.
Earlier in the function it verified ipar[i] wasn't above
nelts (nor negative), so just checking if (ipar[i] >= 2) is ok, it can't
be negative, and just checking if (ipar[i] < 6) is also fine, because
it can never be 8 or above (because nelts is 8 in that case).
Though, the if (ipar[i] < 2) case check used to be correct only when
nelts could be only 4, when it can be 8 too, it will as in the following
testcase happily accept values in the [4, 7] range which shouldn't be
accepted (it can only handle [2, 3]).
Fixed thusly.
2026-02-17 Jakub Jelinek <jakub@redhat.com>
PR target/124138
* config/i386/i386.cc (avx_vpermilp_parallel): Verify
ipar[2] and ipar[3] aren't larger than 3.
* gcc.dg/pr124138.c: New test.
* gcc.target/i386/avx512f-pr124138-1.c: New test.
* gcc.target/i386/avx512f-pr124138-2.c: New test.
The same hard register may be used for both stack and non-stack accesses.
Update ix86_find_max_used_stack_alignment to adjust stack alignment only
when a hard register used for a stack access is defined in a basic block
that dominates the block where it is used.
gcc/
PR target/124098
* config/i386/i386.cc (ix86_access_stack_p): New.
(ix86_find_max_used_stack_alignment): Update stack alignment only
if stack is used.
gcc/testsuite/
PR target/124098
* gcc.target/i386/pr124098.c: New test.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
gcc/analyzer/ChangeLog:
PR analyzer/124139
* engine.cc (exploded_node::on_throw): Bail out if we can't get
the fndecl for the call.
gcc/testsuite/ChangeLog:
PR analyzer/124139
* g++.dg/analyzer/exception-ice-pr124139.C: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Perverse combinations of options can lead to the compiler having to
work around unexpected situations. Armv8 originally specified that
complex IT sequences were deprecated for performance (it was later
rescinded). If the options restrict the floating-point unit to
one without vsel, then movMcc patterns need complex IT sequences
and we can end up with unmatched RTL patterns. Avoid this by
failing early when the target patterns are disabled.
gcc/ChangeLog:
PR target/124134
* config/arm/arm.md (movsfcc): FAIL if using restricted IT
blocks and we lack VSEL.
(movdfcc): Likewise.
gcc/testsuite/ChangeLog:
PR target/124134
* gcc.target/arm/pr124134.c: New test.
This testcase started to be miscompiled with r16-4186 and went latent
again r16-6651.
2026-02-17 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/123048
* gcc.dg/pr123048.c: New test.
The requirements introduced in previous patch r16-7548-g060d7c2a9c1fe1,
were not sufficient for types of size bigger than 64B (Ctor or long double),
as dg-add-options of libatomic, links libatomic only if it is required to
handle atomics of 64B types or pointers.
This patch addresses above, by reducing the size of Ctor struct to fit in
64 bytes, and moving long double test to separate file, that requires and
links with libatomic.
PR libstdc++/124124
libstdc++-v3/ChangeLog:
* testsuite/29_atomics/atomic/cons/zero_padding.cc: Updated
Ctor class and move test_floating to...
* testsuite/29_atomics/atomic_float/zero_padding.cc: Extracted
test_floating.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Similar to r16-7056-g22f51c0f5e62a4, here the expression within
the decltype void(Derived<T>) is non-dependent enough that we
instantiate/fold it immediately, during which however convert_to_void
tries to evaluate the concept-id, which fails. When in an
unevaluated context such as decltype I don't think convert_to_void
should be evaluating concept-ids.
PR c++/121822
gcc/cp/ChangeLog:
* cvt.cc (convert_to_void): Don't evaluate a concept-id
in an unevaluated context.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-decltype6.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
This patch makes the default case of unify accept LAMBDA_EXPR P/A pairs,
which we can legitimately hit during alias CTAD guide overload resolution.
We can also less legimitately hit this during partial specialization
matching (likely IFNDR).
I'm not totally sure if we want to handle them like any other non-deducible
expression vs handling them separately (returning success iff they're ==).
I couldn't come up with a testcase for which it mattered so I went the
simpler route.
PR c++/122318
PR c++/101670
gcc/cp/ChangeLog:
* pt.cc (unify) <default>: Accept LAMBDA_EXPR.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ20.C: New test.
* g++.dg/cpp2a/lambda-targ21.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
I know P2758R5 didn't make it into C++26, but on IRC Ville said it would be
useful anyway, so here is a quick attempt at implementing it.
Not adding anything on the libstdc++ side, because I don't know where
experimental stuff like that should go, whether it would be in the
implementation namespace etc.
Tags are currently parsed and printed in the diagnostics, but -Wconstexpr-msg=
option and being able to #pragma GCC diagnostic ignore -Wconstexpr-msg=blah
will need to wait for GCC 17.
In any case, the compiler side is just one new builtin,
__builtin_constexpr_diag, whose first argument is 0 for print,
or 1 for warning or 2 for error (or that ored with 16 if location shouldn't
be caller's location but caller's caller location - useful when adding some
wrappers around the builtin), second argument is string_view of the tag
(or "" for no tag) and third argument is string_view or u8string_view
with the message. The builtin also handles string literals.
2026-02-17 Jakub Jelinek <jakub@redhat.com>
gcc/cp/
* cp-tree.h (enum cp_built_in_function): Add
CP_BUILT_IN_CONSTEXPR_DIAG.
(cexpr_str::cexpr_str): Add new default ctor.
(cexpr_str::type_check): Add optional allow_char8_t arg.
(cexpr_str::extract): Add optional ctx, non_constant_p, overflow_p
and jump_target arguments.
* cp-gimplify.cc (cp_gimplify_expr): Throw away
__builtin_constexpr_diag calls after gimplification of
their arguments.
* decl.cc (cxx_init_decl_processing): Create __builtin_constexpr_diag
FE builtin decl.
* constexpr.cc (call_stack, call_stack_tick, last_cx_error_tick):
Moved earlier.
(cxx_eval_constexpr_diag): New function.
(cxx_eval_builtin_function_call): Handle __builtin_constexpr_diag
calls.
* tree.cc (builtin_valid_in_constant_expr_p): Return true for
CP_BUILT_IN_CONSTEXPR_DIAG.
* semantics.cc (cexpr_str::type_check): Add allow_char8_t argument,
if true, allow data to return const char8_t *.
(cexpr_str::extract): Add ctx, non_constant_p, overflow_p and
jump_target arguments, if they are non-NULL, evalute expressions
in that context rather than using cxx_constant_value and translate
back to SOURCE_CHARSET even if message_data or message_sz are NULL.
gcc/testsuite/
* g++.dg/ext/constexpr-diag1.C: New test.
* g++.dg/ext/constexpr-diag2.C: New test.
* g++.dg/ext/constexpr-diag3.C: New test.
* g++.dg/ext/constexpr-diag4.C: New test.
* g++.dg/ext/constexpr-diag5.C: New test.
* g++.dg/ext/constexpr-diag6.C: New test.
The recently added patterns for recovering good code generation of conditional
operations on RISC-V with Zicond had a nasty little bug causing this bootstrap
failure.
The main patterns are fine -- in those cases the czero produces a neutral
value. So for example a conditional IOR can use a czero to select between an
IOR's operand and zero, then we do an unconditional IOR of the common value and
the result of the czero.
For AND the neutral value is -1 rather than 0. So we need a different
sequence. We emit the AND into a temporary. Then select between the common
term and zero. Then IOR the temporary with the selected value. That sequence
requires the tense of the selection to be inverted which I failed to do in the
split RTL output of the pattern.
Those had been tested by inspection only and the tense flip was missed. Doko's
bootstrap test with zicond enabled by default was able to trip this problem.
Thankfully it was easy to reproduce and bisect and was mostly a matter of
waiting for builds to run.
I've bootstrapped this on one of my BPIs with B, V and Zicond enabled by
default. I'll be pushing it to the trunk momentarily. I never actually
compared assembly or debugged the resulting code, it was found purely by
inspection once I knew where to look. ie, I don't have a testcase for the
testsuite, but this is covered by bootstrapping with Zicond enabled.
I'd been somewhat worried about this possibility for a while -- the B, V and
Zicond extensions are not well represented by CI systems for bootstrap testing.
Given the Pioneer here is still limping along, it's a good test of rv64gc and
I've hacked things up so that the BPI will enable B, V and Zicond by default.
The baseline run is still in progress (bootstrapping and regression testing on
the BPI is up to 30 hours now), but we'll have coverage going forward.
Obviously when the K3 systems come out the hope is this cycle time will drop
meaningfully.
PR target/124048
gcc/
* config/riscv/zicond.md (conditional AND patterns): Fix missed
flipping the condition's test in RTL output.
When we are altering the ctrl state of a stmt due to adding abnormal
edges from it we also have to make sure to cleanup its noreturn state.
PR tree-optimization/124130
* tree-inline.cc (copy_edges_for_bb): Fixup noreturn calls
with abnormal edge source.
* g++.dg/torture/pr124130.C: New testcase.
The following fixes the computation of the 2nd loop IV bound after
loop splitting when only one of the split IV and the loop control
variable is a pointer.
PR tree-optimization/124132
* tree-ssa-loop-split.cc (compute_new_first_bound): Fix
bound difference computation.
* gcc.dg/torture/pr124132.c: New testcase.
This test uses atomic<T>::compare_exchange_strong and thus may require
libatomic and atomic-cmpxchg-word. The requirement on thread-fence and
non_pch were superfulous.
PR libstdc++/124124
libstdc++-v3/ChangeLog:
* testsuite/29_atomics/atomic/cons/zero_padding.cc: Adjust
dg-require.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
With r16-531 we've regressed
FAIL: gcc.target/i386/pr108938-3.c scan-assembler-times bswap[\t ]+ 3
on ia32 and also made 2 separate regressions in the same testcase
on x86_64-linux (which in scan-assembler-times cancel out; previously
we were generating one 64-bit bswap + rotate in one function and
one 32-bit bswap + rotate in another function, now we emit 2 32-bit bswaps
in the first one and really horrible code in the second one).
The following patch fixes the latter function by emitting 32-bit bswap
+ 32-bit rotate on both ia32 and x86_64. This fixes the
above FAIL (and introduces
FAIL: gcc.target/i386/pr108938-3.c scan-assembler-times bswap[\t ]+ 2
on x86_64).
The problem is that the vectorizer now uses VEC_PACK_TRUNC_EXPR and
bswap/store_merging was only able to handle vectors in a CONSTRUCTOR.
The patch adds handling of VEC_PACK_TRUNC_EXPR if its operands are
CONSTRUCTORs. Without a testcase, I wasn't confident enough to write
BYTES_BIG_ENDIAN support, for CONSTRUCTOR { A, B, C, D } we make
DCBA out of it on little endian but ABCD on big endian and that would
need to be combined with picking up the most significant halves of each
element.
I'll look incrementally at the other function.
2026-02-17 Jakub Jelinek <jakub@redhat.com>
PR target/120233
* gimple-ssa-store-merging.cc (find_bswap_or_nop_2): New function.
(find_bswap_or_nop): Move CONSTRUCTOR handling to above function,
call it instead of find_bswap_or_nop_1.
(bswap_replace): Handle VEC_PACK_TRUNC_EXPR like CONSTRUCTOR.
(maybe_optimize_vector_constructor): Likewise.
(pass_optimize_bswap::execute): Likewise.
(get_status_for_store_merging): Likewise.
(pass_store_merging::execute): Likewise.
The gcc.dg/hierarchical-discriminator-loop-version.c etc. tests FAIL on
Solaris with the native assembler:
FAIL: gcc.dg/hierarchical-discriminator-loop-version.c scan-assembler \\\\.loc 1 (9|10) [0-9]+ is_stmt 0 discriminator [0-9]+
FAIL: gcc.dg/hierarchical-discriminator-unroll.c scan-assembler \\\\.loc 1 17 7 is_stmt 0 discriminator ([1-9][0-9]*|0x[1-9a-fA-F][0-9a-fA-F]*)
FAIL: gcc.dg/hierarchical-discriminator-vect-version.c scan-assembler \\\\.loc 1 13 [0-9]+ is_stmt 0 discriminator ([1-9][0-9]*|0x[1-9a-fA-F][0-9a-fA-F]*)
When using Solaris as, the .loc directives aren't present. Their use is
guarded by dwarf2out.cc (dwarf2out_default_as_loc_support), which
ultimately depends on HAVE_AS_DWARF2_DEBUG_LINE
To avoid this, this patch restricts the scans to gas targets, which is
better than what we currently have.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (as and gas),
and x86_64-pc-linux-gnu.
2026-02-17 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
* gcc.dg/hierarchical-discriminator-loop-version.c
(scan-assembler): Require gas.
* gcc.dg/hierarchical-discriminator-unroll.c: Likewise.
* gcc.dg/hierarchical-discriminator-vect-version.c: Likewise.
The gcc.dg/asm-hard-reg-1.c test FAILs on i386-pc-solaris2.11 and
i686-pc-linux-gnu with -m64:
FAIL: gcc.dg/asm-hard-reg-1.c scan-assembler-times foo\\t%ecx 4
It turns out the target selectors of the x86 scans are badly confused:
* Using an i?86-*-* target selector is always wrong given the existance of
biarch i?86-*-* targets. They should use the x86 effective target with
ilp32 instead.
* dg directives don't heed the preprocessor, so scans were duplicated
for i?86-*-* and x86-*-*, sometimes with different target selectors.
This patch simplifies and fixes the target selectors, removing
duplication.
Tested on i386-pc-solaris2.11 with -m32/-m64 and x86_64-pc-linux-gnu
with -m64/-m32/-mx32, and i686-pc-linux-gnu with -m32/-m64.
2026-02-16 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
* gcc.dg/asm-hard-reg-1.c: Simplify x86 target selectors. Remove
duplicates.
The gcc.dg/tree-ssa/ldexp.c test FAILs on Solaris:
FAIL: gcc.dg/tree-ssa/ldexp.c (test for excess errors)
UNRESOLVED: gcc.dg/tree-ssa/ldexp.c scan-assembler-not \\tfmul\\t
Excess errors:
../builtins-config.h:53:2: error: #error forgot to set -std=c99.
Fixed by adding that option.
Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and
x86_64-pc-linux-gnu.
2026-02-16 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
* gcc.dg/tree-ssa/ldexp.c (dg-additional-options): Add -std=c99.
The testcase was only partly updated to use __SIZETYPE__, the
following fixes the remains.
* gcc.dg/torture/ssa-fre-7.c: Properly use __SIZETYPE__
where required.
The gcc.dg/ipa/pr122458.c test FAILs on Solaris with the native assembler:
FAIL: gcc.dg/ipa/pr122458.c (test for excess errors)
Excess errors:
Assembler: pr122458.c
"/var/tmp//cctINwTd.s", line 4 : Illegal mnemonic
Near line: " .dc.a foo"
"/var/tmp//cctINwTd.s", line 4 : Syntax error
Near line: " .dc.a foo"
Given that .dc.a is a gas extension, this patch xfail's the patch
without gas.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (as and gas),
and x86_64-pc-linux-gnu.
2026-02-16 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
* gcc.dg/ipa/pr122458.c: xfail without gas.
Given https://eel.is/c++draft/expr.reflect#5.1
we error on
typedef __SIZE_TYPE__ A;
namespace B {
using ::A;
typedef __SIZE_TYPE__ C;
}
using B::C;
constexpr auto a = ^^A;
constexpr auto b = ^^B::A;
constexpr auto c = ^^B::C;
constexpr auto d = ^^C;
on ^^B::A and ^^C (note, clang++ fork only errors on ^^B::A).
Now, whether size_t is
typedef __SIZE_TYPE__ size_t;
namespace std {
using ::size_t;
}
or
namespace std {
typedef __SIZE_TYPE__ size_t;
}
using std::size_t;
depends on the target and clearly is the latter on Solaris, so testing
whether ^^size_t is a type alias doesn't work there - it is found as
a using decl there.
So the following patch stops testing it for size_t and tests yet another
user alias (a typedef is already tested - ^^T).
2026-02-17 Jakub Jelinek <jakub@redhat.com>
PR c++/124119
* g++.dg/reflect/is_type_alias2.C (W): New type alias.
Assert is_type_alias (^^W). Don't assert is_type_alias (^^size_t).
The following testcase ICEs in C++ 20 and older, because during
diagnostics dump_template_bindings attempts to tsubst with tf_none
something and we try to emit a pedwarn during that.
While the pedwarn could be just guarded with if (complain & tf_warning),
I thought we shouldn't support extensions for tf_none and should
instead return error_mark_node.
The following patch does that.
2026-02-17 Jakub Jelinek <jakub@redhat.com>
PR c++/120685
* typeck2.cc (build_functional_cast_1): For C++23 auto(x)
without tf_warning or tf_error return error_mark_node instead of
emitting pedwarn and handling it.
* semantics.cc (finish_compound_literal): Similarly for C++26
auto{x}.
* g++.dg/cpp23/auto-fncast19.C: New test.
Based on discussions in the PR that C++ 26 reflection is
entity based rather than declaration based, the following patch
ensures we reflect DECL_LOCAL_DECL_ALIAS of DECL_LOCAL_DECL_P vars
or function decls.
Additionally, while default arguments are intentionally not merged
from the block scope externs to their corresponding namespace scope
function decls, for std::meta::has_default_argument the wording
requires to return true even if there is at least one block scope
extern with default argument for the particular parameter.
So, the patch also records in a new flag whether a default argument
has been present in a block scope extern and propagates it through
further duplicate_decls. eval_has_default_arguments then uses
both this new flag (for the block scope externs) and the preexisting
search for default arguments in the corresponding type.
2026-02-17 Jakub Jelinek <jakub@redhat.com>
PR c++/123612
* cp-tree.h (DECL_HAS_DEFAULT_ARGUMENT_P): Define.
* decl.cc (merge_decl_arguments): For -freflection and
extern_alias set DECL_HAS_DEFAULT_ARGUMENT_P (oldarg)
if newdecl has a default argument for that parameter,
otherwise propagate the flag.
* reflect.cc (get_reflection): For DECL_LOCAL_DECL_P
use its DECL_LOCAL_DECL_ALIAS.
(eval_has_default_argument): Return boolean_true_node
also if DECL_HAS_DEFAULT_ARGUMENT_P flag is set.
* g++.dg/reflect/pr123612.C: New test.
PR diagnostics/122001 notes that in GCC 15 we emit:
<source>: In instantiation of 'void foo(T) [with T = std::nullptr_t]':
<source>:7:8: required from here
7 | foo(nullptr);
| ~~~^~~~~~~~~
<source>:3:7: error: invalid operands of types 'int' and 'std::nullptr_t' to binary 'operator+'
3 | 1 + t;
| ~~^~~
whereas in GCC 16 we emit:
<source>: In instantiation of 'void foo(T) [with T = std::nullptr_t]':
required from here
<source>:7:8:
7 | foo(nullptr);
| ~~~^~~~~~~~~
<source>:3:7: error: invalid operands of types 'int' and 'std::nullptr_t' to binary 'operator+'
3 | 1 + t;
| ~~^~~
where the "required from line" has lost its file:line:column prefix,
with the latter appearing on a follow line.
The root cause is that in r15-5995-g339246fb9ef4ca I changed
cp/error.cc's print_instantiation_partial_context_line from using
print_location to using auto_context_line, so that the location
information would be better integrated with nested diagnostics,
and enabled this by default in r16-3092-gd3fe5a560f0bcc.
text_sink::build_indent_prefix is returning the empty string for such
lines, rather than an indented bullet point.
This patch tweaks things so that such lines print the location before
the message at the top nesting level, and on a separate line at nested
nesting levels, and always the latter with
-fno-diagnostics-show-nesting.
gcc/cp/ChangeLog:
PR diagnostics/122001
* error.cc (auto_context_line::auto_context_line): Initialize
m_nesting_level and m_location_printed. Update the condition
for printing location in ctor to also do it at top-level
nesting level. Record into m_location_printed if we did
print the location.
(auto_context_line::~auto_context_line): Don't call print_location
if we already printed it in the ctor.
(auto_context_line::m_nesting_level): New field.
(auto_context_line::m_location_printed): New field.
gcc/testsuite/ChangeLog:
PR diagnostics/122001
* g++.dg/diagnostic/instantiation-context-pr122001-1.C: New test.
* g++.dg/diagnostic/instantiation-context-pr122001-2.C: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
The function get_hole_symbol is supposed to set *addrp to either true
or false. However it was only setting it to false, causing
uninitialized memory.
This patch also removes a gcc_asser tfrom a68_make_formal_hole_decl.
If the formal hole results in an empty symbol then it may result into
invalid assembly being generated, but that is akin to use an invalid
asm template.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
PR algol68/124115
* a68-low-holes.cc (get_hole_symbol): Always set *addrp to avoid
uninitialized memory.
* a68-low.cc (a68_make_formal_hole_decl): Remove assert.
gcc/testsuite/ChangeLog
PR algol68/124115
* algol68/compile/formal-hole-2.a68: New test.
This paper implement the changes from P2438R2 basic_string::substr() &&
paper into C++26. The additional substr and constructor overload are
implemented only for SSO string, as they require mutating the content
(if reused), and thus would require copy of the string anyway for COW
strings. (In consequence allocators implicitly constructible from int
remain ambiguous for C++11 ABI strings, see r16-7497-gfa1149534d8580).
In addition to cases when the allocators are not compatible (equal),
this patch does not reuse (transfer) allocator storage, if the selected
substring fits inside the SSO buffer, so we do not risk keeping large
chunk of memory for few characters. (This also covers cases when the
source stored the content in the local buffer).
As this additional overloads are meant to be optimization, in contrast
to move constructor, the source is left unmodified if the allocation
is not transferred. This avoid introducing a write (of null terminator)
to previously untouched, heap allocated, memory.
Separate overloads for substr(size_type __pos, size_type __n) and
substr(size_type __pos == 0), that delegate to corresponding constructor,
are provided to avoid the check of __n against the length() in the later
case.
Finally, the signatures of existing substr() overload are not modified
(no longer required since C++20), which avoid any impact on the ABI.
PR libstdc++/119745
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (basic_string::_M_construct)
[__cplusplus >= 202302L]: Declare.
(basic_string::basic_string(basic_string&&, size_type, const _Alloc&))
(basic_string(basic_string&&, size_type, size_type, const _Alloc&))
(basic_string::substr(size_type, size_type) &&)
(basic_string::substr(size_type) &&) [__cplusplus >= 202302L]: Define.
* include/bits/basic_string.tcc (basic_string::_M_construct)
[__cplusplus >= 202302L]: Define.
* testsuite/21_strings/basic_string/operations/substr/rvalue.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This patch implements formatting for std::filesystem::path from P2845R8,
and defines the feature test macro __cpp_lib_format_path to 202403L,
provided only in <filesystem>.
Formatting options are performed (if applicable) in order:
'g', '?', transcoding, fill-and-align & width
The standard specifies transcoding behaviour only when literal encoding
is UTF-8, leaving all other cases implementation defined.
Current implementation of filesystem::path assumes:
* char encoding is UTF-8
* wchar_t encoding is either UTF-32 or UTF-16
libstdc++-v3/ChangeLog:
* include/bits/fs_path.h: Include bits/formatfwd.h.
(std::formatter<filesystem::path, _CharT>): Define.
* include/bits/version.def (format_path): Define.
* include/bits/version.h: Regenerate.
* include/std/filesystem: Expose __cpp_lib_format_path.
* testsuite/std/format/fs_path.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Signed-off-by: Ivan Lazaric <ivan.lazaric1@gmail.com>
Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
The following marks the loop in foo1 as to not be vectorized to
restore old -O2 behavior and restore what the testcase was supposed
to verify.
PR testsuite/103515
* gcc.target/powerpc/pr103515.c: Mark the loop in foo1
with #pramga GCC novector.
This plugs an annoying loophole, whereby the subpool indication present
in an allocator is dropped in some circumstances, most notably when the
allocator is initialized by an aggregate with defaulted components.
gcc/ada/
PR ada/124106
* exp_ch4.adb (Expand_N_Allocator): Minor fix in commentary.
(Expand_Allocator_Expression): Propagate the Subpool_Handle_Name
of the original allocator onto the newly built allocators.
* exp_ch6.adb (Make_Build_In_Place_Call_In_Allocator): Likewise.
Use Preserve_Comes_From_Source to propagate Comes_From_Source.
(Make_CPP_Constructor_Call_In_Allocator): Likewise.
gcc/testsuite/
* gnat.dg/subpools2.adb: New test.
int8_t is currently defined as char in Solaris <sys/int_types.h>
/*
* Basic / Extended integer types
*
* The following defines the basic fixed-size integer types.
*
* Implementations are free to typedef them to Standard C integer types or
* extensions that they support. If an implementation does not support one
* of the particular integer data types below, then it should not define the
* typedefs and macros corresponding to that data type. Note that int8_t
* is not defined in -Xs mode on ISAs for which the ABI specifies "char"
* as an unsigned entity because there is no way to define an eight bit
* signed integral.
*/
typedef char int8_t;
typedef signed char int8_t;
and _CHAR_IS_SIGNED defined as 1 in <sys/isa_defs.h>. As has long been
known, this violates C99, 7.18.1.1, Exact-width integer types.
While this works in general nonetheless, it creates constant trouble for
C++ code as can be seen in PRs libstdc++/113450 and recently
libstdc++/123176, but also in LLVM.
While Oracle Solaris engineering is amenable to changing int8_t to
signed char, this will take time. However, it proved easy to do so now
using fixincludes.
This works for a GCC bootstrap just fine with one exception: as
documented in PR d/123509, libdruntime has its own definition of int8_t
which is now inconsistent with GCC's. This leads to some gdc.test and
libphobos testsuite failures, which can easily be fixed with the patch
attached to that PR. I wouldn't consider this a showstopper for GCC 16
if that patch wouldn't make it to the release.
However, the failures point to another problem: with this change, the
mangling of
void func(int8_t);
changes in C++, creating an ABI break. Fortunately, this isn't seen in
libstdc++, so the impact should be reasonable compared to the constant
trouble the current definition causes for C++.
Besides, clang already uses
#define __INT8_TYPE__ signed char
apparently without problems.
In case users do run into the incompatiblity, the fixed definitions are
wrapped in #if !defined(_LEGACY_INT8_T)/#endif so there's an easy way back
to the original definition.
Bootstrapped on i386-pc-solaris2.11, amd64-pc-solaris2.11,
sparc-sun-solaris2.11, and sparcv9-sun-solaris2.11 with only the D
failure described above.
I've also run 1-stage and bootstrap builds of LLVM main using a patched
GCC 16 as bootstrap compiler on amd64-pc-solaris2.11 and
sparcv9-sun-solaris2.11 without regressions.
2026-01-07 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
fixincludes:
PR libstdc++/113450
PR libstdc++/123176
* inclhack.def (solaris_int8_t): New fix.
* fixincl.x: Regenerate.
gcc:
PR libstdc++/113450
PR libstdc++/123176
* config/sol2.h (INT8_TYPE): Change to signed char.
(INT_LEAST8_TYPE): Likewise.
(INT_FAST8_TYPE): Likewise.
