For a pointer array reference that is annotated with counted_by attribute,
such as:
struct annotated {
int *c __attribute__ ((counted_by (b)));
int b;
};
struct annotated *p = setup (10);
p->c[12] = 2; //out of bound access
the IR for p->c[12] is:
(.ACCESS_WITH_SIZE (p->c, &p->b, 0B, 4) + 48) = 2;
The current routine get_index_from_offset in c-family/c-ubsan.cc cannot
handle the integer constant offset "48" correctly.
The fix is to enhance "get_index_from_offset" to correctly handle the constant
offset.
PR c/124230
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_index_from_offset): Handle the special case when
the offset is an integer constant.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/pointer-counted-by-bounds-124230-char.c: New test.
* gcc.dg/ubsan/pointer-counted-by-bounds-124230-float.c: New test.
* gcc.dg/ubsan/pointer-counted-by-bounds-124230-struct.c: New test.
* gcc.dg/ubsan/pointer-counted-by-bounds-124230-union.c: New test.
* gcc.dg/ubsan/pointer-counted-by-bounds-124230.c: New test.
After r0-72806-gbc4071dd66fd4d, c_parser_consume_token will
assert if we get a pragma inside c_parser_consume_token but
pragma processing will call pragma_lex which then calls
c_parser_consume_token. In the case of pragma with expansion
(redefine_extname, message and sometimes pack [and some target
specific pragmas]) we get the expanded tokens that includes
CPP_PRAGMA. We should just allow it instead of doing an assert.
This follows what the C++ front-end does even and we no longer
have an ICE.
Bootstrapped and tested on x86_64-linux-gnu.
PR c/97991
gcc/c/ChangeLog:
* c-parser.cc (c_parser_consume_token): Allow
CPP_PRAGMA if inside a pragma.
gcc/testsuite/ChangeLog:
* c-c++-common/cpp/pr97991-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Fixes regression in C++ support without exception handling by:
1. Moving Makefile fragment config/i386/t-seh-eh to
config/mingw/t-seh-eh that handles C++ exception handling. This is
sufficient to fix the regression even if the exception handling
itself is not implemented yet.
2. Changing existing references of t-seh-eh in libgcc/config.host and
add it for aarch64-*-mingw*.
With these changes, the compiler can now be built with C and C++.
This doesn't add support for Structured Exception Handling (SEH)
which will be done separately.
libgcc/ChangeLog:
* config.host: Set tmake_eh_file for aarch64-*-mingw* and update
it for x86_64-*-mingw* and x86_64-*-cygwin*.
* config/i386/t-seh-eh: Move to...
* config/mingw/t-seh-eh: ...here.
* config/aarch64/t-no-eh: Removed.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/mingw/mingw.exp: Add support for C++ files.
* gcc.target/aarch64/mingw/minimal_new_del.C: New test.
Co-Authored-By: Evgeny Karpov <evgeny.karpov@arm.com>
This testcase started to be miscompiled with my r15-9131 change
on arm with -march=armv7-a -mfpu=vfpv4 -mfloat-abi=hard -O and got
fixed with r16-6548 PR121773 change.
2026-03-06 Jakub Jelinek <jakub@redhat.com>
PR target/122000
* gcc.c-torture/execute/pr122000.c: New test.
C++11 forbids a compound statement, as seen in the definition
of __glibcxx_assert(), in a constexpr function. This patch
open-codes the assertion in `bitset<>::operator[] const` for
C++11 to fix a failure in `g++.old-deja/g++.martin/bitset1.C`.
Also, it adds `{ dg-do compile }` in another test to suppress
a spurious UNRESOLVED complaint.
libstdc++-v3/ChangeLog:
* include/std/bitset (operator[]() const): Customize bounds
check for C++11 case.
* testsuite/20_util/bitset/access/subscript_const_neg.cc:
Suppress UNRESOLVED complaint.
Code size tests on Arm are notoriously flaky because there are
numerous ISA variants (Arm, Thumb-1 and Thumb-2) to consider in
addition to a number of other variants from multiple sub-architecture
and micro-architectural tuning options. In combination this means
that we have continuous testsuite churn if the constraints are tight
enough to detect real regressions.
So this patch eliminates most of these checks, except where the code
size test is the only test that is done (other than the compilation
itself). Where that is the case I've tightened the compiler options
to limit the test to one set of architecture flags, thereby
eliminating most of the sources of variation.
In some cases I've replaced a code-size check with some other test of
the output, based on the intent of the original patch that motivated
the test. For example, the max-insns-skipped test now checks that an
IT instruction is not generated rather than checking the size of the
binary (which was a side-effect of not generating IT).
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Add arm_arch_v7a_thumb.
* gcc.target/arm/ifcvt-size-check.c: Add options to force thumb1.
* gcc.target/arm/ivopts-2.c: Remove object size check.
* gcc.target/arm/ivopts-3.c: Likewise.
* gcc.target/arm/ivopts-4.c: Likewise.
* gcc.target/arm/ivopts-5.c: Likewise.
* gcc.target/arm/ivopts.c: Likewise.
* gcc.target/arm/max-insns-skipped.c: Scan for absence of an IT
instruction. Remove object size check. Use arm_arch_v7a_thumb.
* gcc.target/arm/pr43597.c: Remove object size check and use
arm_arch_v7a_thumb.
* gcc.target/arm/pr63210.c: Use arm_arch_v5t_thumb options.
* gcc.target/arm/split-live-ranges-for-shrink-wrap.c: Remove
object size check and use arm_arch_v5t_thumb options.
When testing the effective target these tests were using the wrong
name since they omitted the trailing _ok. This was causing some tests
to fail to execute correclty.
gcc/testsuite/ChangeLog:
* gcc.target/arm/aes-fuse-1.c: Add _ok to the effective_target.
* gcc.target/arm/aes-fuse-2.c: Likewise.
libstdc++-v3/ChangeLog:
* include/bits/fs_path.h (std::formatter<filesystem::path, _CharT>):
Format _Utf_view directly via __formatter_str::_M_format_range.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
libgfortran/ChangeLog:
PR libfortran/124371
* caf/shmem/supervisor.c (startWorker): Use defined(HAVE_FORK)
instead of !defined(WIN32) for preprocessor conditional.
As Bug 122300 shows, we have at least one target where the
static_assert added by r16-4422-g1b18a9e53960f3 fails. This patch
resurrects the original proposal for using aligned new that I posted in
https://gcc.gnu.org/pipermail/libstdc++/2025-October/063904.html
Instead of just asserting that the memory from operator new will be
sufficiently aligned, check whether it will be and use aligned new if
needed. We don't just use aligned new unconditionally, because that can
add overhead on targets where malloc already meets the requirements.
libstdc++-v3/ChangeLog:
PR libstdc++/122300
* src/c++17/fs_path.cc (path::_List::_Impl): Remove
static_asserts.
(path::_List::_Impl::required_alignment)
(path::_List::_Impl::use_aligned_new): New static data members.
(path::_List::_Impl::create_unchecked): Check use_aligned_new
and use aligned new if needed.
(path::_List::_Impl::alloc_size): New static member function.
(path::_List::_Impl_deleter::operator): Check use_aligned_new
and use aligned delete if needed.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
The first testcase below ICEs e.g. with -O2 on s390x-linux, the
second with -O2 -m32 on x86_64-linux. We have
<bb 2> [local count: 1073741824]:
if (x_4(D) != 0)
goto <bb 3>; [33.00%]
else
goto <bb 4>; [67.00%]
<bb 3> [local count: 354334800]:
_7 = qux (42);
foo (0, &<retval>, _7);
<bb 4> [local count: 1073741824]:
return <retval>;
on a target where <retval> has gimple reg type but is
aggregate_value_p and TREE_ADDRESSABLE too.
fnsplit splits this into
<bb 2> [local count: 354334800]:
_1 = qux (42);
foo (0, &<retval>, _1);
<bb 3> [local count: 354334800]:
return <retval>;
in the *.part.0 function and
if (x_4(D) != 0)
goto <bb 3>; [33.00%]
else
goto <bb 4>; [67.00%]
<bb 3> [local count: 354334800]:
<retval> = _Z3bari.part.0 ();
<bb 4> [local count: 1073741824]:
return <retval>;
in the original function. Now, dunno if already that isn't
invalid because <retval> has TREE_ADDRESSABLE set in the latter, but
at least it is accepted by tree-cfg.cc verification.
tree lhs = gimple_call_lhs (stmt);
if (lhs
&& (!is_gimple_reg (lhs)
&& (!is_gimple_lvalue (lhs)
|| verify_types_in_gimple_reference
(TREE_CODE (lhs) == WITH_SIZE_EXPR
? TREE_OPERAND (lhs, 0) : lhs, true))))
{
error ("invalid LHS in gimple call");
return true;
}
While lhs is not is_gimple_reg, it is is_gimple_lvalue here.
Now, inlining of the *.part.0 fn back into the original results
in
<retval> = a;
statement which already is diagnosed by verify_gimple_assign_single:
case VAR_DECL:
case PARM_DECL:
if (!is_gimple_reg (lhs)
&& !is_gimple_reg (rhs1)
&& is_gimple_reg_type (TREE_TYPE (lhs)))
{
error ("invalid RHS for gimple memory store: %qs", code_name);
debug_generic_stmt (lhs);
debug_generic_stmt (rhs1);
return true;
}
__float128/long double are is_gimple_reg_type, but both operands
aren't is_gimple_reg.
The following patch fixes it by doing separate load and store, i.e.
_42 = a;
<retval> = 42;
in this case. If we want to change verify_gimple_assign to disallow
!is_gimple_reg (lhs) for is_gimple_reg_type (TREE_TYPE (lhs)), we'd
need to change fnsplit instead, but I'd be afraid such a change would
be more stage1 material (and certainly nothing that should be
even backported to release branches).
2026-03-05 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/124135
* tree-inline.cc (expand_call_inline): If both gimple_call_lhs (stmt)
and use_retvar aren't gimple regs but have gimple reg type, use
separate load of use_retva into SSA_NAME and then store of it
into gimple_call_lhs (stmt).
* g++.dg/torture/pr124135-1.C: New test.
* g++.dg/torture/pr124135-2.C: New test.
The following testcase is miscompiled since my r12-6382 change, because
it doesn't play well with the gimple_fold_indirect_ref function which uses
STRIP_NOPS and then has
/* *(foo *)fooarrptr => (*fooarrptr)[0] */
if (TREE_CODE (TREE_TYPE (subtype)) == ARRAY_TYPE
&& TREE_CODE (TYPE_SIZE (TREE_TYPE (TREE_TYPE (subtype)))) == INTEGER_CST
&& useless_type_conversion_p (type, TREE_TYPE (TREE_TYPE (subtype))))
{
tree type_domain;
tree min_val = size_zero_node;
tree osub = sub;
sub = gimple_fold_indirect_ref (sub);
if (! sub)
sub = build1 (INDIRECT_REF, TREE_TYPE (subtype), osub);
type_domain = TYPE_DOMAIN (TREE_TYPE (sub));
if (type_domain && TYPE_MIN_VALUE (type_domain))
min_val = TYPE_MIN_VALUE (type_domain);
if (TREE_CODE (min_val) == INTEGER_CST)
return build4 (ARRAY_REF, type, sub, min_val, NULL_TREE, NULL_TREE);
}
Without the GENERIC
#if GENERIC
(simplify
(pointer_plus (convert:s (pointer_plus:s @0 @1)) @3)
(convert:type (pointer_plus @0 (plus @1 @3))))
#endif
we have INDIRECT_REF of POINTER_PLUS_EXPR with int * type of NOP_EXPR
to that type of POINTER_PLUS_EXPR with pointer to int[4] ARRAY_TYPE, so
gimple_fold_indirect_ref doesn't create the ARRAY_REF.
But with it, it is simplified to NOP_EXPR to int * type from
POINTER_PLUS_EXPR with pointer to int[4] ARRAY_TYPE, the NOP_EXPR is
skipped over by STRIP_NOPS and the above code triggers.
The following patch fixes it by swapping the order, do NOP_EXPR
inside of POINTER_PLUS_EXPR first argument instead of NOP_EXPR with
POINTER_PLUS_EXPR.
2026-03-06 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/124358
* match.pd ((ptr) (x p+ y) p+ z -> (ptr) (x p+ (y + z))): Simplify
into (ptr) x p+ (y + z) instead.
* gcc.c-torture/execute/pr124358.c: New test.
This big-endian testcase started to ICE with r16-7464-g560766f6e239a8
and then started to work r16-7506-g498983d9619351.
So it seems like a good idea to add the testcase for this
so it does not break again.
Pushed as obvious after a quick test to make sure it ICEd
before and it is passing now on aarch64-linux-gnu.
PR rtl-optimization/124078
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr124078-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
The following testcase is miscompiled, we throw exception only during
the first bar () call and not during the second and in that case reach
the inline asm.
The problem is that the TARGET_EXPR handling calls
ctx->global->put_value (new_ctx.object, new_ctx.ctor);
first for aggregate/vectors, then
if (is_complex)
/* In case no initialization actually happens, clear out any
void_node from a previous evaluation. */
ctx->global->put_value (slot, NULL_TREE);
and then recurses on TARGET_EXPR_INITIAL.
Even for is_complex it can actually store partially the result in the
slot before throwing.
When TARGET_EXPR_INITIAL doesn't throw, we do
if (ctx->save_expr)
ctx->save_expr->safe_push (slot);
and that arranges for the value in slot be invalidated at the end of
surrounding CLEANUP_POINT_EXPR.
But in case when it does throw this isn't done.
The following patch fixes it by moving that push to save_expr
before the if (*jump_target) return NULL_TREE; check.
2026-03-05 Jakub Jelinek <jakub@redhat.com>
PR c++/124145
* constexpr.cc (cxx_eval_constant_expression) <case TARGET_EXPR>: Move
ctx->save_expr->safe_push (slot) call before if (*jump_target) test.
Use TARGET_EXPR_INITIAL instead of TREE_OPERAND.
* g++.dg/cpp26/constexpr-eh18.C: New test.
In _Safe_unordered_container the _M_invalidate_all and _M_invalidate_all_if
are made public to be used in nested struct _UContMergeGuard.
Thanks to friend declaration we can avoid those method to be accessible from
user code.
libstdc++-v3/ChangeLog:
* include/debug/safe_unordered_container.h
(_Safe_unordered_container::_UContInvalidatePred): Move outside class, at
namespace scope. Declare friend.
(_Safe_unordered_container::_UMContInvalidatePred): Likewise.
(_Safe_unordered_container::_UContMergeGuard): Likewise.
(_Safe_unordered_container::_M_invalidate_all): Make protected.
(_Safe_unordered_container::_M_invalidate_all_if): Likewise.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
This patch fixes a68_wrap_formal_proc_hole so it doesn't assume that
wrapped C functions returning void return Algol 68 void values, which
are empty records.
Tested in i686-linux-gnu and x86_64-linux-gnu.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
PR algol68/124322
* a68-low-holes.cc (a68_wrap_formal_proc_hole): Wrap functions
returning void properly.
Make __aarch64_cpu_features unconditionally available. This permits the
unconditional use of this global inside __arm_get_current_vg, which was
introduced in r16-7637-g41b4a73f370116.
For now this global is only initialised when <sys/auxv.h> is available,
but we can extend this in future to support other ways of initialising
the bits used for SME support, and use this remove __aarch64_have_sme.
This approach was recently adopted by LLVM.
This patch does introduce an inconsistency with __aarch64_have_sme when
<sys/auxv.h> is unavailable. However, this doesn't introduce any
regressions, because one of the following conditions will hold:
1. SVE is enabled at compile time whenever we use a streaming or
streaming compatible function. In this case the compiler won't need to
use __arm_get_current_vg, so it doesn't matter if it gives the wrong
answer.
2. There is a use of a streaming or streaming compatible function when
we don't know whether SVE is enabled. In order to get correct DWARF
unwind information, we then have to be able to test for SVE availability
at runtime. This isn't possible until a working __arm_get_current_vg
implementation is available, so the configuration has never (yet) been
supported.
libgcc/ChangeLog:
PR target/124333
* config/aarch64/cpuinfo.c: Define __aarch64_cpu_features
unconditionally.
For the vectorization of non-contiguous memory accesses such as the
vectorization of loads from a particular struct member, specifically
when vectorizing with unknown bounds (thus using a pointer and not an
array) it is observed that inadequate alignment checking allows for
the crossing of a page boundary within a single vectorized loop
iteration. This leads to potential segmentation faults in the
resulting binaries.
For example, for the given datatype:
typedef struct {
uint64_t a;
uint64_t b;
uint32_t flag;
uint32_t pad;
} Data;
and a loop such as:
int
foo (Data *ptr) {
if (ptr == NULL)
return -1;
int cnt;
for (cnt = 0; cnt < MAX; cnt++) {
if (ptr->flag == 0)
break;
ptr++;
}
return cnt;
}
the vectorizer yields the following cfg on armhf:
<bb 1>:
_41 = ptr_4(D) + 16;
<bb 2>:
_44 = MEM[(unsigned int *)ivtmp_42];
ivtmp_45 = ivtmp_42 + 24;
_46 = MEM[(unsigned int *)ivtmp_45];
ivtmp_47 = ivtmp_45 + 24;
_48 = MEM[(unsigned int *)ivtmp_47];
ivtmp_49 = ivtmp_47 + 24;
_50 = MEM[(unsigned int *)ivtmp_49];
vect_cst__51 = {_44, _46, _48, _50};
mask_patt_6.17_52 = vect_cst__51 == { 0, 0, 0, 0 };
if (mask_patt_6.17_52 != { 0, 0, 0, 0 })
goto <bb 4>;
else
ivtmp_43 = ivtmp_42 + 96;
goto <bb 2>;
<bb4>
...
without any proper address alignment checks on the starting address
or on whether alignment is preserved across iterations. We therefore
fix the handling of such cases.
To correct this, we modify the logic in `get_load_store_type',
particularly the logic responsible for ensuring we don't read more
than the scalar code would in the context of early breaks, extending
it from handling not only gather-scatter and strided SLP accesses but
also allowing it to properly handle element-wise accesses, wherein we
specify that these need correct block alignment, thus promoting their
`alignment_support_scheme' from `dr_unaligned_supported' to
`dr_aligned'.
gcc/ChangeLog:
PR tree-optimization/124037
* tree-vect-stmts.cc (get_load_store_type): Fix
alignment_support_scheme categorization for early
break VMAT_ELEMENTWISE accesses.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-pr124037.c: New.
* g++.dg/vect/vect-pr124037.cc: New.
The following fixes a regression introduced by r11-5542 which
restricts replacing uses of live original defs of now vectorized
stmts to when that does not require new loop-closed PHIs to be
inserted. That restriction keeps the original scalar definition
live which is sub-optimal and also not reflected in costing.
The particular case the following fixes can be seen in
gcc.dg/vect/bb-slp-57.c is the case where we are replacing an
existing loop closed PHI argument.
PR tree-optimization/98064
* tree-vect-loop.cc (vectorizable_live_operation): Do
not restrict replacing uses in a LC PHI.
* gcc.dg/vect/bb-slp-57.c: Verify we do not keep original
stmts live.
If gcc is configured on aarch64-linux against new binutils, such as
2.46, it doesn't emit into assembly markings like
.section .note.gnu.property,"a"
.align 3
.word 4
.word 16
.word 5
.string "GNU"
.word 0xc0000000
.word 4
.word 0x7
.align 3
but instead emits
.aeabi_subsection aeabi_feature_and_bits, optional, ULEB128
.aeabi_attribute Tag_Feature_BTI, 1
.aeabi_attribute Tag_Feature_PAC, 1
.aeabi_attribute Tag_Feature_GCS, 1
The former goes into .note.gnu.propery section, the latter goes into
.ARM.attributes section.
Now, when linking without LTO or with LTO but without -g, all behaves
for the linked binaries the same, say for test.c
int main () {}
$ gcc -g -mbranch-protection=standard test.c -o test; readelf -j .note.gnu.property test
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI, PAC, GCS
$ gcc -flto -mbranch-protection=standard test.c -o test; readelf -j .note.gnu.property test
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI, PAC, GCS
$ gcc -flto -g -mbranch-protection=standard test.c -o test; readelf -j .note.gnu.property test
readelf: Warning: Section '.note.gnu.property' was not dumped because it does not exist
The problem is that the *.debug.temp.o object files created by lto-wrapper
don't have these markings. The function copies over .note.GNU-stack section
(so that it doesn't similarly on most arches break PT_GNU_STACK segment
flags), and .note.gnu.property (which used to hold this stuff e.g. on
aarch64 or x86, added in PR93966). But it doesn't copy the new
.ARM.attributes section.
The following patch fixes it by copying that section too. The function
unfortunately only works on names, doesn't know if it is copying ELF or some
other format (PE, Mach-O) or if it is copying ELF, whether it is EM_AARCH64
or some other arch. The following patch just copies the section always,
I think it is very unlikely people would use .ARM.attributes section for
some random unrelated stuff. If we'd want to limit it to just EM_AARCH64,
guess it would need to be done in
libiberty/simple-object-elf.c (simple_object_elf_copy_lto_debug_sections)
instead as an exception for the (*pfn) callback results (and there it could
e.g. verify SHT_AARCH64_ATTRIBUTES type but even there dunno if it has
access to the Ehdr stuff).
No testcase from me, dunno if e.g. the linker can flag the lack of those
during linking with some option rather than using readelf after link and
what kind of effective targets we'd need for such a test.
2026-03-05 Jakub Jelinek <jakub@redhat.com>
PR target/124365
* simple-object.c (handle_lto_debug_sections): Also copy over
.ARM.attributes section.
The test uses dg-require-atomic-cmpxchg-word that checks if atomic compare
exchange is available for pointer sized integers, and then test types that
are eight bytes in size. This causes issue for targets for which pointers
are four byte and libatomic is not present, like arm-none-eabi.
This patch addresses by using short member in TailPadding and MidPadding,
instead of int. This reduces the size of types to four bytes, while keeping
padding bytes present.
PR libstdc++/124124
libstdc++-v3/ChangeLog:
* testsuite/29_atomics/atomic/cons/zero_padding.cc: Limit size of
test types to four bytes.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
The _Arg_value::_M_set method, initialized the union member, by
assigning to reference to that member produced by _M_get(*this).
However, per language rules, such assignment has undefined behavior,
if alternative was not already active, same as for any object not
within its lifetime.
To address above, we modify _M_set to use placement new for the class
types, and invoke _S_access with two arguments for all other types.
The _S_access (rename of _S_get) is modified to assign the value of
the second parameter (if provided) to the union member. Such direct
assignments are treated specially in the language (see N5032
[class.union.general] p5), and will start lifetime of trivially default
constructible alternative.
libstdc++-v3/ChangeLog:
* include/std/format (_Arg_value::_M_get): Rename to...
(_Arg_value::_M_access): Modified to accept optional
second parameter that is assigned to value.
(_Arg_value::_M_get): Handle rename.
(_Arg_value::_M_set): Use construct_at for basic_string_view,
handle, and two-argument _S_access for other types.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Signed-off-by: Ivan Lazaric <ivan.lazaric1@gmail.com>
Co-authored-by: Ivan Lazaric <ivan.lazaric1@gmail.com>
While in this case it is not an assemble failure nor wrong-code,
because say xchgl %eax, %edx and xchg eax, edx do the same thing,
they are encoded differently, so if we want consistency between
-masm=att and -masm=intel emitted code (my understanding is that
is what is Zdenek testing right now, fuzzing code, compiling
with both -masm=att and -masm=intel and making sure if the former
assembles, the latter does too and they result in identical
*.o files), we should use different order of the operands
even here (and it doesn't matter which order we pick).
I've grepped the *.md files with
grep '\\t%[0-9], %[0-9]' *.md | grep -v '%0, %0'
i386.md: "xchg{<imodesuffix>}\t%1, %0"
i386.md: xchg{<imodesuffix>}\t%1, %0
i386.md: "wrss<mskmodesuffix>\t%0, %1"
i386.md: "wruss<mskmodesuffix>\t%0, %1"
(before this and PR124366 fix) and later on also with
grep '\\t%[a-z0-9_<>]*[0-9], %[a-z0-9_<>]*[0-9]' *.md | grep -v '%0, %0'
and checked all the output and haven't found anything else problematic.
2026-03-05 Jakub Jelinek <jakub@redhat.com>
* config/i386/i386.md (swap<mode>): Swap operand order for
-masm=intel.
This patch changes the type of _M_handle member of __format::_Arg_value
from __format::_HandleBase union member to basic_format_arg<_Context>::handle.
This allows handle to be stored (using placement new) inside _Arg_value at
compile time, as type _M_handle member now matches stored object.
In addition to above, to make handle usable at compile time, we adjust
the _M_func signature to match the stored function, avoiding the need
for reinterpret cast.
To avoid a cycling dependency, where basic_format_arg<_Context> requires
instantiating _Arg_value<_Context> for its _M_val member, that in turn
requires basic_format_arg<_Context>::handle, we define handle as nested
class inside _Arg_value and change basic_format_arg<_Context>::handle
to alias for it.
Finally, the handle(_Tp&) constructor is now constrained to not accept
handle itself, as otherwise it would be used instead of copy-constructor
when constructing from handle&.
As _Arg_value is already templated on _Context, this change should not lead
to additional template instantiations.
libstdc++-v3/ChangeLog:
* include/std/format (__Arg_value::handle): Define, extracted
with modification from basic_format_arg::handle.
(_Arg_value::_Handle_base): Remove.
(_Arg_value::_M_handle): Change type to handle.
(_Arg_value::_M_get, _Arg_value::_M_set): Check for handle
type directly, and return result unmodified.
(basic_format_arg::__formattable): Remove.
(basic_format_arg::handle): Replace with alias to
_Arg_value::handle.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
This reverts the loongarch.cc change of the commit
4df77a2542.
PR 123807 turns out to be a special case of the middle-end PR 124250.
The previous ad-hoc fix is unneeded now since the underlying middle-end
issue is fixed, so revert it but keep the test case.
gcc/
PR target/123807
PR middle-end/124250
* config/loongarch/loongarch.cc
(loongarch_expand_vector_init_same): Revert r16-7163 change.
gas expects for this instruction
vcvthf82ph xmm30, QWORD PTR [r9]
vcvthf82ph ymm30, XMMWORD PTR [r9]
vcvthf82ph zmm30, YMMWORD PTR [r9]
i.e. the memory size is half of the dest register size.
We currently emit it for the last 2 forms but emit XMMWORD PTR
for the first one too. So, we need %q1 for V8HF and for V16HF/V32HF
can either use just %1 or %x1/%t1. There is no define_mode_attr
that would provide those, so I've added one just for this insn.
2026-03-05 Jakub Jelinek <jakub@redhat.com>
PR target/124349
* config/i386/sse.md (iptrssebvec_2): New define_mode_attr.
(cvthf82ph<mode><mask_name>): Use it for -masm=intel input
operand.
* gcc.target/i386/avx10_2-pr124349-2.c: New test.
The immediate operand 0x44 in this insn was incorrectly emitted as
$0x44 even in -masm=intel syntax.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
approved by Uros in the PR, committed to trunk.
2026-03-05 Jakub Jelinek <jakub@redhat.com>
PR target/124367
* config/i386/sse.md (*andnot<mode>3): Use 0x44 rather than $0x44
for -masm=intel.
* gcc.target/i386/avx512vl-pr124367.c: New test.
These two insns were using the same operand order for both -masm=att
and -masm=intel, which is ok if using the same operand for both, but not
when they are different.
2026-03-05 Jakub Jelinek <jakub@redhat.com>
PR target/124366
* config/i386/i386.md (@wrss<mode>, @wruss<mode>): Swap operand
order for -masm=intel.
* gcc.target/i386/cet-pr124366.c: New test.
As mentioned on the PR, we ICE on the following testcase and if members_of
isn't called on a class with e.g. typedef struct { int d; } D;, we don't
handle it correctly, e.g. we say ^^C::D is not an type alias or for
members_of in a namespace that there aren't two entities, the struct itself
and the type alias for it.
This is because name_unnamed_type handles the naming of an unnamed type
through typedef for linkage purposes (where we originally have
a TYPE_DECL with IDENTIFIER_ANON_P DECL_NAME for the type) by replacing
all occurrences of TYPE_NAME on the type from the old TYPE_DECL to the new
TYPE_DECL with the user provided name.
The ICE for members_of (^^C, uctx) is then because we see two TYPE_DECLs
(one with IDENTIFIER_ANON_P, one with user name) with the same TREE_TYPE
and enter the same thing twice into what we want to return and ICE in the
comparison routine. Anyway, for is_type_alias purposes, there is no
is_typedef_decl and can't be because the same TYPE_DECL is used as TYPE_NAME
of both the type proper and its alias. Without reflection we didn't care
about the difference.
So, the following patch changes name_unnamed_type to do things differently,
but only for -freflection, because 1) I don't want to break stuff late in
stage4 2) without reflection we don't really need it and don't need to
pay the extra memory cost by having another type which is the type alias.
The change is that instead of
TYPE_DECL .anon_NN
| TREE_TYPE
v
type <----------+
| TYPE_NAME |
v |
TYPE_DECL D |
| TREE_TYPE |
+-------------+
where for class context both TYPE_DECLs are in TYPE_FIELDS and for
namespace context only the latter one is (as pushdecl ignores the
IDENTIFIER_ANON_P one) we have
TYPE_DECL D TYPE_DECL D --- DECL_ORIGINAL_TYPE
| TREE_TYPE | TREE_TYPE |
v v |
type variant_type |
^-------------------------------+
which is except for the same DECL_NAME on both TYPE_DECLs exactly what
is used for typedef struct D_ { int d; } D;
Various spots have been testing for the typedef name for linkage purposes
cases and were using tests like:
OVERLOAD_TYPE_P (TREE_TYPE (value))
&& value == TYPE_NAME (TYPE_MAIN_VARIANT (TREE_TYPE (value)))
So that this can be tested, this patch introduces a new decl_flag on
the TYPE_DECLs and marks for -freflection both of these TYPE_DECLs
(and for -fno-reflection the one without IDENTIFIER_ANON_P name).
It is easy to differentiate between the two, the first one is also
DECL_IMPLICIT_TYPEDEF_P, the latter is not (and on the other side
has DECL_ORIGINAL_TYPE non-NULL).
For name lookup in namespaces, nothing special needs to be done,
because the originally IDENTIFIER_ANON_P TYPE_DECL wasn't added
to the bindings, at block scope I had to deal with it in pop_local_binding
because it was unhappy that it got renamed. And finally for class
scopes, we need to arrange for the latter TYPE_DECL to be found, but
currently it is the second one. The patch currently skips the first one for
name lookup in fields_linear_search and arranges for count_class_fields
and member_vec_append_class_fields to also ignore the first one. Wonder if
the latter two shouldn't also ignore any other IDENTIFIER_ANON_P TYPE_FIELDS
chain decls, or do we ever perform name lookup for the anon identifiers?
Another option for fields_linear_search would be try to swap the order of
the two TYPE_DECLs in TYPE_FIELDS chain somewhere in grokfield.
Anyway, the changes result in minor emitted DWARF changes, say for
g++.dg/debug/dwarf2/typedef1.C without -freflection there is
.uleb128 0x4 # (DIE (0x46) DW_TAG_enumeration_type)
.long .LASF6 # DW_AT_name: "typedef foo<1>::type type"
.byte 0x7 # DW_AT_encoding
.byte 0x4 # DW_AT_byte_size
.long 0x70 # DW_AT_type
.byte 0x1 # DW_AT_decl_file (typedef1.C)
.byte 0x18 # DW_AT_decl_line
.byte 0x12 # DW_AT_decl_column
.long .LASF7 # DW_AT_MIPS_linkage_name: "N3fooILj1EE4typeE"
...
and no typedef, while with -freflection there is
.uleb128 0x3 # (DIE (0x3a) DW_TAG_enumeration_type)
.long .LASF5 # DW_AT_name: "type"
.byte 0x7 # DW_AT_encoding
.byte 0x4 # DW_AT_byte_size
.long 0x6c # DW_AT_type
.byte 0x1 # DW_AT_decl_file (typedef1.C)
.byte 0x18 # DW_AT_decl_line
.byte 0x12 # DW_AT_decl_column
...
.uleb128 0x5 # (DIE (0x57) DW_TAG_typedef)
.long .LASF5 # DW_AT_name: "type"
.byte 0x1 # DW_AT_decl_file (typedef1.C)
.byte 0x18 # DW_AT_decl_line
.byte 0x1d # DW_AT_decl_column
.long 0x3a # DW_AT_type
so, different DW_AT_name on the DW_TAG_enumeration_type, missing
DW_AT_MIPS_linkage_name and an extra DW_TAG_typedef. While in theory
I could work harder to hide that detail, I actually think it is a good
thing to have it the latter way because it represents more exactly
what is going on.
Another slight change is different locations in some diagnostics
on g++.dg/lto/odr-3 test (location of the unnamed struct vs. locations
of the typedef name given to it without -freflection), and a module
issue which Nathan has some WIP patch for in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123810#c11
In any case, none of those differences show up in normal testsuite runs
currently (as those tests aren't compiled with -freflection), if/when
-freflection becomes the default for -std=c++26 we can deal with the
DWARF one as well as different locations in odr-3 and for modules I was
hoping it could be handled incrementally. I'm not even sure what should
happen if one TU has struct D { int d; }; and another one has
typedef struct { int d; } D;, shall that be some kind of error? Though
right now typedef struct { int d; } D; in both results in an error too
and that definitely needs to be handled.
2026-03-05 Jakub Jelinek <jakub@redhat.com>
PR c++/123810
* cp-tree.h (TYPE_DECL_FOR_LINKAGE_PURPOSES_P): Define.
(TYPE_DECL_WAS_UNNAMED): Likewise.
(TYPE_WAS_UNNAMED): Also check TYPE_DECL_WAS_UNNAMED.
* decl.cc (start_decl): Use TYPE_DECL_FOR_LINKAGE_PURPOSES_P.
(maybe_diagnose_non_c_class_typedef_for_l): If t == type, use
DECL_SOURCE_LOCATION (orig) instead of
DECL_SOURCE_LOCATION (TYPE_NAME (t)).
(name_unnamed_type): Set TYPE_DECL_FOR_LINKAGE_PURPOSES_P
on decl. For -freflection don't change TYPE_NAME from
orig to decl, but instead change DECL_NAME (orig) to
DECL_NAME (decl) and set TYPE_DECL_FOR_LINKAGE_PURPOSES_P on
orig too.
* decl2.cc (grokfield): Use TYPE_DECL_FOR_LINKAGE_PURPOSES_P.
* name-lookup.cc (fields_linear_search): Ignore
TYPE_DECL_WAS_UNNAMED decls.
(count_class_fields): Likewise.
(member_vec_append_class_fields): Likewise.
(pop_local_binding): Likewise.
* reflect.cc (namespace_members_of): For TYPE_DECL with
TYPE_DECL_FOR_LINKAGE_PURPOSES_P set also append
reflection of strip_typedefs (m).
* class.cc (find_flexarrays): Handle TYPE_DECLs with
TYPE_DECL_WAS_UNNAMED like the ones with IDENTIFIER_ANON_P
name.
* g++.dg/reflect/members_of10.C: New test.
* g++.dg/cpp2a/typedef1.C: Expect one message on a different line.
std::meta::extent returns a size_t, but eval_extent returns either
size_zero_node or size_binop(), both of which are of type sizetype,
which is not the C/C++ size_t and so we don't pass the check in
cxx_eval_outermost_constant_expr:
/* Check we are not trying to return the wrong type. */
if (!same_type_ignoring_top_level_qualifiers_p (type, TREE_TYPE (r)))
We should convert to size_type_node which represents the C/C++ size_t,
like for instance fold_sizeof_expr does.
PR c++/124368
gcc/cp/ChangeLog:
* reflect.cc (eval_extent): Convert the result to size_type_node.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/extent1.C: New test.
Reviewed-by: Jakub Jelinek <jakub@redhat.com>
As Andrew Pinski noted in PR60674:
devirt-23.C started to pass with r16-101-g132d01d96ea9d6.
So just need to update the testcase removing the xfail and close this
bug as fixed.
The reason why this was not fixed until r16-101-g132d01d96ea9d6 is
because the call is from main which is known to be called once and was
not a candidate for IPA-CP until then.
In fact renaming the function from main to f (and adding a `return 0`
so not invoking undefined behavior), the scan-ipa-dump works all the
way back to GCC 5.
Tested on aarch64-linux-gnu and arm-linux-gnueabihf.
gcc/testsuite/ChangeLog:
PR ipa/60674
* g++.dg/ipa/devirt-23.C: Remove xfail.
This is a crash on code like:
template for (constexpr auto val : define_static_array (enumerators_of (^^E)))
{
constexpr auto a = annotations_of(val)[0];
using U = [:type_of(a):];
constexpr auto m1 = extract<U>(a);
}
because the template arg to extract wasn't substituted to "info".
Once I dug deeper I realized this problem isn't tied to Reflection:
we also crash here:
template for (constexpr auto val : { 42 })
{
using U = decltype(val);
foo<U>();
}
because we emit code for foo() that still has a DECLTYPE_TYPE in it.
The problem is in tsubst and reusing typedefs. Normally, for code like
template<typename T> void foo () {
using U = T;
U u;
}
we do the DECL_FUNCTION_SCOPE_P -> retrieve_local_specialization call.
This call only happens in function templates (that are not explicit
specializations), but the "template for" above are both in non-template
functions. So we end up returning the original tree:
/* The typedef is from a non-template context. */
return t;
It seems clear that this is the wrong thing to do, and that the
DECL_FUNCTION_SCOPE_P code should happen in this scenario as well.
[temp.decls.general] tells me that "For the purpose of name lookup and
instantiation, the compound-statement of an expansion-statement is
considered a template definition." so I'm guessing that we want to
check for an expansion-statement as well. As decl_dependent_p says,
in_expansion_stmt is false when instantiating, so I'm looking for
sk_template_for.
PR c++/124229
gcc/cp/ChangeLog:
* pt.cc (in_expansion_stmt_p): New.
(tsubst): When reusing typedefs, do retrieve_local_specialization also
when in_expansion_stmt_p is true.
gcc/testsuite/ChangeLog:
* g++.dg/cpp26/expansion-stmt32.C: New test.
* g++.dg/reflect/expansion-stmt2.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
On Wed, Feb 25, 2026 at 08:50:40PM +0100, Jakub Jelinek wrote:
> > Sounds like the maybe_strip_typedefs is wrong, since reflection in general
> > tries to preserve aliases.
>
> Actually the maybe_strip_typedefs call is correct, that is for the type
> argument (so when it is std::meta::annotations_with_type) and the standard
> says that dealias should be used
> - https://eel.is/c++draft/meta.reflection#annotation-6.2
> But we probably shouldn't use TYPE_ATTRIBUTES but DECL_ATTRIBUTES (TYPE_NAME (r))
> if r is a type alias.
> I'll test a patch for that separately.
Here it is.
2026-03-04 Jakub Jelinek <jakub@redhat.com>
PR c++/123866
* reflect.cc (eval_annotations_of): For type aliases look for
annotations in DECL_ATTRIBUTES (TYPE_NAME (r)).
* g++.dg/reflect/annotations11.C: New test.
I don't have access to HP/UX, but at least on other OSes and what Linux as
well as POSIX documents is that when you call putenv with some argument,
what that argument points to becomes part of the environment and when
it is changed, the environment changes. I believe ENOMEM from putenv is
about reallocating of the __environ (or similar) pointed array of pointers
(e.g. if the particular env var name isn't there already), it still
shouldn't allocate any memory for the NAME=VALUE string and just use
the user provided. So, padding address of automatic array will be UB
as soon as the scope of that var is left.
One can either malloc the buffer, or use static vars, then nothing leaks
and in the unlikely case putenv would be called twice for the same env var,
it would second time only register the same buffer.
2026-03-04 Jakub Jelinek <jakub@redhat.com>
PR libfortran/124330
* caf/shmem/shared_memory.c (shared_memory_set_env): Make buffer
used by putenv static.
(shared_memory_init): Likewise.
Without this patch, the following failure can be seen in the logs:
gcc.target/arm/simd/vextQp64_1.c: vext.64[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+, #[0-9]+!?(?:[ \t]+@[a-zA-Z0-9 ]+)?\n found 2 times
FAIL: gcc.target/arm/simd/vextQp64_1.c scan-assembler-times vext.64[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+, #[0-9]+!?(?:[ \t]+@[a-zA-Z0-9 ]+)?\n 1
gcc/testsuite/ChangeLog:
* gcc.target/arm/simd/vextQp64_1.c: Compile with -fno-ipa-cp.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
The problem here is we try calling find_widening_optab_handler_and_mode
with to_mode=E_USAmode and from_mode=E_UHQmode. This causes an ICE (with checking only).
The fix is to reject the case where the mode classes are different in convert_plusminus_to_widen
before even trying to deal with the modes.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/119568
gcc/ChangeLog:
* tree-ssa-math-opts.cc (convert_plusminus_to_widen): Reject different
mode classes.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
I changed the #if in r8-3123-gc6888c62577671 but didn't make the
corresponding change to the #endif.
libstdc++-v3/ChangeLog:
PR libstdc++/124363
* include/std/string_view: Adjust comment on #endif to match #if
condition.
We can perform equivalence substitution in subreg context:
(insn 34 32 36 3 (set (reg:SI 103 [ _7 ])
(subreg:SI (reg/f:DI 119) 0)) "bla.c":7:41 104 {*movsi_aarch64}
becomes
(insn 34 32 36 3 (set (reg:SI 103 [ _7 ])
(subreg:SI (reg/f:DI 64 sfp) 0)) "bla.c":7:41 104 {*movsi_aarch64}
(nil))
but aarch64_hard_regno_mode_ok doesn't like that:
if (regno == FRAME_POINTER_REGNUM || regno == ARG_POINTER_REGNUM)
return mode == Pmode;
and ICEs further on.
Therefore, this patch checks hard_regno_mode_ok if we substitute a hard
reg in subreg context.
PR rtl-optimization/124041
gcc/ChangeLog:
* lra-constraints.cc (curr_insn_transform): Check if hardreg is
valid in subreg context.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr124041.c: New test.
Signed-off-by: Robin Dapp <rdapp@oss.qualcomm.com>
Implements P2353R5 "Extending associative containers with the
remaining heterogeneous overloads". Adds overloads templated on
heterogeneous key types for several members of associative
containers, particularly insertions:
/-- unordered --\
set map mset mmap set map mset mmap
@ . . . @ . . . insert
. @ . . . @ . . op[], at, try_emplace,
insert_or_assign
. . . . @ @ @ @ bucket
(Nothing is added to the multiset or multimap tree containers.)
All the insert*() and try_emplace() members also get a hinted
overload. The at() members get const and non-const overloads.
The new overloads enforce concept __heterogeneous_tree_key or
__heterogeneous_hash_key, as in P2077, to enforce that the
function objects provided meet requirements, and that the key
supplied is not an iterator or the native key. Insertions
implicitly construct the required key_type object from the
argument, by move where permitted.
libstdc++-v3/ChangeLog:
PR libstdc++/117402
* include/bits/stl_map.h (operator[], at (2x), try_emplace (2x),
insert_or_assign (2x)): Add overloads.
* include/bits/unordered_map.h (operator[], at (2x),
try_emplace (2x), insert_or_assign (2x), bucket (2x)): Add overloads.
* include/bits/stl_set.h (insert (2x)): Add overloads.
* include/bits/unordered_set.h (insert (2x), bucket (2x)): Add overloads.
* include/bits/hashtable.h (_M_bucket_tr, _M_insert_tr): Define.
* include/bits/hashtable_policy.h (_M_at_tr (2x)): Define.
* include/bits/stl_tree.h (_M_emplace_here, _M_get_insert_unique_pos_tr,
_M_get_insert_hint_unique_pos_tr): Define new heterogeneous insertion
code path for set and map.
* include/bits/version.def (associative_heterogeneous_insertion):
Define.
* include/bits/version.h: Regenerate.
* include/std/map (__glibcxx_want_associative_heterogeneous_insertion):
Define macro.
* include/std/set: Same.
* include/std/unordered_map: Same.
* include/std/unordered_set: Same.
* testsuite/23_containers/map/modifiers/hetero/insert.cc: New tests.
* testsuite/23_containers/set/modifiers/hetero/insert.cc: Same.
* testsuite/23_containers/unordered_map/modifiers/hetero/insert.cc:
Same.
* testsuite/23_containers/unordered_multimap/modifiers/hetero/insert.cc:
Same.
* testsuite/23_containers/unordered_multiset/modifiers/hetero/insert.cc:
Same.
* testsuite/23_containers/unordered_set/modifiers/hetero/insert.cc:
Same.
The forwarded_bytes sbitmap needs to be zeroed after allocation,
as sbitmaps are not implicitly initialized. This caused valgrind
warnings about conditional jumps depending on uninitialised values.
gcc/ChangeLog:
PR rtl-optimization/124351
* avoid-store-forwarding.cc (process_store_forwarding): Add
bitmap_clear after allocating forwarded_bytes.
The vcvt<convertfp8_pack><mode><mask_name> pattern uses wrong <mask_operand?>
for -masm=intel, so the testcase fails to assemble, it emits something
like {ymm1} instead of {k1}.
2026-03-04 Jakub Jelinek <jakub@redhat.com>
PR target/124341
* config/i386/sse.md (vcvt<convertfp8_pack><mode><mask_name>): Use
<mask_operand3> rather than <mask_operand2> for -masm=intel.
* gcc.target/i386/avx10_2-pr124341.c: New test.
gas expects the second operand if in memory WORD PTR rather than XMMWORD PTR.
The following patch fixes it by using %w1 instead of %1, if the operand is
a register, it is printed as xmm1 in both cases.
2026-03-04 Jakub Jelinek <jakub@redhat.com>
PR target/124349
* config/i386/sse.md (avx10_2_comisbf16_v8bf): Use %w1 instead of %1
for -masm=intel.
* gcc.target/i386/avx10_2-pr124349.c: New test.
A failure on sparc shows that the dump scan for dot-prod is fragile
enough. The following simply removes it given it serves no actual
purpose and adds comments in place.
* gcc.dg/vect/vect-reduc-dot-s8b.c: Remove scan for
dot_prod pattern matching.
