Iain Buclaw [Mon, 20 Jan 2025 19:01:03 +0000 (20:01 +0100)]
d: Fix failing test with 32-bit compiler [PR114434]
Since the introduction of gdc.test/runnable/test23514.d, it's exposed an
incorrect compilation when adding a 64-bit constant to a link-time
address. The current cast to size_t causes a loss of precision, which
can result in incorrect compilation.
PR d/114434
gcc/d/ChangeLog:
* expr.cc (ExprVisitor::visit (PtrExp *)): Get the offset as a
dinteger_t rather than a size_t.
(ExprVisitor::visit (SymOffExp *)): Likewise.
Harald Anlauf [Sun, 19 Jan 2025 20:06:56 +0000 (21:06 +0100)]
Fortran: do not copy back for parameter actual arguments [PR81978]
When an array is packed for passing as an actual argument, and the array
has the PARAMETER attribute (i.e., it is a named constant that can reside
in read-only memory), do not copy back (unpack) from the temporary.
PR fortran/81978
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_conv_array_parameter): Do not copy back data
if actual array parameter has the PARAMETER attribute.
* trans-expr.cc (gfc_conv_subref_array_arg): Likewise.
Jakub Jelinek [Mon, 20 Jan 2025 17:00:43 +0000 (18:00 +0100)]
c++: Handle RAW_DATA_CST in make_tree_vector_from_ctor [PR118528]
This is the first bug discovered today with the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html
hack but then turned into proper testcases where embed-21.C FAILed
since introduction of optimized #embed support and the other when
optimizing large C++ initializers using RAW_DATA_CST.
The problem is that the C++ FE calls make_tree_vector_from_ctor
and uses that as arguments vector for deduction guide handling.
The call.cc code isn't prepared to handle RAW_DATA_CST just about
everywhere, so I think it is safer to make sure RAW_DATA_CST only
appears in CONSTRUCTOR_ELTS and nowhere else.
Thus, the following patch expands the RAW_DATA_CSTs from initializers
into multiple INTEGER_CSTs in the returned vector.
2025-01-20 Jakub Jelinek <jakub@redhat.com>
PR c++/118528
* c-common.cc (make_tree_vector_from_ctor): Expand RAW_DATA_CST
elements from the CONSTRUCTOR to individual INTEGER_CSTs.
* g++.dg/cpp/embed-21.C: New test.
* g++.dg/cpp2a/class-deduction-aggr16.C: New test.
Andrew Pinski [Mon, 20 Jan 2025 00:07:10 +0000 (16:07 -0800)]
inline: Purge the abnormal edges as needed in fold_marked_statements [PR118077]
While fixing PR target/117665, I had noticed that fold_marked_statements
would not purge the abnormal edges which could not be taken any more due
to folding a call (devirtualization or simplification of a [target] builtin).
Devirutalization could also cause a call that used to be able to have an
abornal edge become one not needing one too so this was needed for GCC 15.
As reported in PR118185, std::ranges::clamp does not correctly forward
the projected value to the comparator. Add the missing forward.
libstdc++-v3/ChangeLog:
PR libstdc++/118185
PR libstdc++/100249
* include/bits/ranges_algo.h (__clamp_fn): Correctly forward the
projected value to the comparator.
* testsuite/25_algorithms/clamp/118185.cc: New test.
Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
There's a discrepancy in SLP vs non-SLP vectorization that SLP build
does not handle plain SSA copies (which should have been elimiated
earlier). But this now bites back since non-SLP happily handles them,
causing a regression with --param vect-force-slp=1 which is now default,
resulting in a big performance regression in 456.hmmer.
So the following restores parity between SLP and non-SLP here, defering
the missed copy elimination to later (PR118565).
Xi Ruoyao [Tue, 14 Jan 2025 09:26:04 +0000 (17:26 +0800)]
LoongArch: Improve reassociation for bitwise operation and left shift [PR 115921]
For things like
(x | 0x101) << 11
It's obvious to write:
ori $r4,$r4,257
slli.d $r4,$r4,11
But we are actually generating something insane:
lu12i.w $r12,524288>>12 # 0x80000
ori $r12,$r12,2048
slli.d $r4,$r4,11
or $r4,$r4,$r12
jr $r1
It's because the target-independent canonicalization was written before
we have all the RISC targets where loading an immediate may need
multiple instructions. So for these targets we need to handle this in
the target code.
We do the reassociation on our own (i.e. reverting the
target-independent reassociation) if "(reg [&|^] mask) << shamt" does
not need to load mask into an register, and either:
- (mask << shamt) needs to be loaded into an register, or
- shamt is a const_immalsl_operand, so the outer shift may be further
combined with an add.
gcc/ChangeLog:
PR target/115921
* config/loongarch/loongarch-protos.h
(loongarch_reassoc_shift_bitwise): New function prototype.
* config/loongarch/loongarch.cc
(loongarch_reassoc_shift_bitwise): Implement.
* config/loongarch/loongarch.md
(*alslsi3_extend_subreg): New define_insn_and_split.
(<any_bitwise:optab>_shift_reverse<X:mode>): New
define_insn_and_split.
(<any_bitwise:optab>_alsl_reversesi_extended): New
define_insn_and_split.
(zero_extend_ashift): Remove as it's just a special case of
and_shift_reversedi, and it does not make too much sense to
write "alsl.d rd,rs,r0,shamt" instead of "slli.d rd,rs,shamt".
(bstrpick_alsl_paired): Remove as it is already done by
splitting and_shift_reversedi into and + ashift first, then
late combining the ashift and a further add.
gcc/testsuite/ChangeLog:
PR target/115921
* gcc.target/loongarch/bstrpick_alsl_paired.c (scan-rtl-dump):
Scan for and_shift_reversedi instead of the removed
bstrpick_alsl_paired.
* gcc.target/loongarch/bitwise-shift-reassoc.c: New test.
Xi Ruoyao [Thu, 5 Sep 2024 09:53:41 +0000 (17:53 +0800)]
LoongArch: Simplify using bstr{ins,pick} instructions for and
For bstrins, we can merge it into and<mode>3 instead of having a
separate define_insn.
For bstrpick, we can use the constraints to ensure the first source
register and the destination register are the same hardware register,
instead of emitting a move manually.
This will simplify the next commit where we'll reassociate bitwise
and left shift for better code generation.
gcc/ChangeLog:
* config/loongarch/constraints.md (Yy): New define_constriant.
* config/loongarch/loongarch.cc (loongarch_print_operand):
For "%M", output the index of bits to be used with
bstrins/bstrpick.
* config/loongarch/predicates.md (ins_zero_bitmask_operand):
Exclude low_bitmask_operand as for low_bitmask_operand it's
always better to use bstrpick instead of bstrins.
(and_operand): New define_predicate.
* config/loongarch/loongarch.md (any_or): New
define_code_iterator.
(bitwise_operand): New define_code_attr.
(*<optab:any_or><mode:GPR>3): New define_insn.
(*and<mode:GPR>3): New define_insn.
(<optab:any_bitwise><mode:X>3): New define_expand.
(and<mode>3_extended): Remove, replaced by the 3rd alternative
of *and<mode:GPR>3.
(bstrins_<mode>_for_mask): Remove, replaced by the 4th
alternative of *and<mode:GPR>3.
(*<optab:any_bitwise>si3_internal): Remove, already covered by
the *<optab:any_or><mode:GPR>3 and *and<mode:GPR>3 templates.
Richard Biener [Mon, 20 Jan 2025 10:50:53 +0000 (11:50 +0100)]
tree-optimization/118552 - failed LC SSA update after unrolling
When unrolling changes nesting relationship of loops we fail to
mark blocks as in need to change for LC SSA update. Specifically
the LC SSA PHI on a former inner loop exit might be misplaced
if that loop becomes a sibling of its outer loop.
PR tree-optimization/118552
* cfgloopmanip.cc (fix_loop_placement): Properly mark
exit source blocks as to be scanned for LC SSA update when
the loops nesting relationship changed.
(fix_loop_placements): Adjust.
(fix_bb_placements): Likewise.
Thomas Schwinge [Fri, 17 Jan 2025 20:45:42 +0000 (21:45 +0100)]
nvptx: Gracefully handle '-mptx=3.1' if neither sm_30 nor sm_35 multilib variant is built
For example, for GCC/nvptx built with '--with-arch=sm_52' (current default)
and '--without-multilib-list', neither a sm_30 nor a sm_35 multilib variant
is built, and thus no '-mptx=3.1' sub-variant either. Such a configuration
is possible as of commit 86b3a7532d56f74fcd1c362f2da7f95e8cc4e4a6
"nvptx: Support '--with-multilib-list'", but currently results in the
following bogus behavior:
The latter two '.' are unexpected; linking OpenMP/nvptx offloading code
like this fails with: 'unresolved symbol __nvptx_uni', for example.
Instead of '.', the latter two should print 'mgomp', too. To achieve that,
we must not set up the '-mptx=3.1' multilib axis if no '-mptx=3.1'
sub-variant is built.
gcc/
* config/nvptx/t-nvptx (MULTILIB_OPTIONS): Don't add 'mptx=3.1' if
neither sm_30 nor sm_35 multilib variant is built.
Jakub Jelinek [Mon, 20 Jan 2025 09:26:49 +0000 (10:26 +0100)]
tree, c++: Consider TARGET_EXPR invariant like SAVE_EXPR [PR118509]
My October PR117259 fix to get_member_function_from_ptrfunc to use a
TARGET_EXPR rather than SAVE_EXPR unfortunately caused some regressions as
well as the following testcase shows.
What happens is that
get_member_function_from_ptrfunc -> build_base_path calls save_expr,
so since the PR117259 change in mnay cases it will call save_expr on
a TARGET_EXPR. And, for some strange reason a TARGET_EXPR is not considered
an invariant, so we get a SAVE_EXPR wrapped around the TARGET_EXPR.
That SAVE_EXPR <TARGET_EXPR <...>> gets initially added only to the second
operand of ?:, so at that point it would still work fine during expansion.
But unfortunately an expression with that subexpression is handed to the
caller also through *instance_ptrptr = instance_ptr; and gets evaluated
once again when computing the first argument to the method.
So, essentially, we end up with
(TARGET_EXPR <D.2907, ...>, (... ? ... SAVE_EXPR <TARGET_EXPR <D.2907, ...>
... : ...)) (... SAVE_EXPR <TARGET_EXPR <D.2907, ...> ..., ...);
and while D.2907 is initialized during gimplification in the code dominating
everything that uses it, the extra temporary created for the SAVE_EXPR
is initialized only conditionally (if the ?: condition is true) but then
used unconditionally, so we get
pmf-4.C: In function ‘void foo(C, B*)’:
pmf-4.C:12:11: warning: ‘<anonymous>’ may be used uninitialized [-Wmaybe-uninitialized]
12 | (y->*x) ();
| ~~~~~~~~^~
pmf-4.C:12:11: note: ‘<anonymous>’ was declared here
12 | (y->*x) ();
| ~~~~~~~~^~
diagnostic and wrong-code issue too.
The following patch fixes it by considering a TARGET_EXPR invariant
for SAVE_EXPR purposes the same as SAVE_EXPR is. Really creating another
temporary for it is just a waste of the IL.
Unfortunately I had to tweak the omp matching code to be able to accept
TARGET_EXPR the same as SAVE_EXPR.
2025-01-20 Jakub Jelinek <jakub@redhat.com>
PR c++/118509
gcc/
* tree.cc (tree_invariant_p_1): Return true for TARGET_EXPR too.
gcc/c-family/
* c-omp.cc (c_finish_omp_for): Handle TARGET_EXPR in first operand
of COMPOUND_EXPR incr the same as SAVE_EXPR.
gcc/testsuite/
* g++.dg/expr/pmf-4.C: New test.
Jakub Jelinek [Mon, 20 Jan 2025 09:24:18 +0000 (10:24 +0100)]
tree-ssa-dce: Fix calloc handling [PR118224]
As reported by Dimitar, this should have been a multiplication, but wasn't
caught because in the test (~(__SIZE_TYPE__) 0) / 2 is the largest accepted
size and so adding 3 to it also resulted in "overflow".
The following patch adds one subtest to really verify it is a multiplication
and fixes the operation.
2025-01-20 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/118224
* tree-ssa-dce.cc (is_removable_allocation_p): Multiply a1 by a2
instead of adding it.
* gcc.target/s390/vector/vec-shift-10.c: New test.
* gcc.target/s390/vector/vec-shift-11.c: New test.
* gcc.target/s390/vector/vec-shift-12.c: New test.
* gcc.target/s390/vector/vec-shift-3.c: New test.
* gcc.target/s390/vector/vec-shift-4.c: New test.
* gcc.target/s390/vector/vec-shift-5.c: New test.
* gcc.target/s390/vector/vec-shift-6.c: New test.
* gcc.target/s390/vector/vec-shift-7.c: New test.
* gcc.target/s390/vector/vec-shift-8.c: New test.
* gcc.target/s390/vector/vec-shift-9.c: New test.
s390: arch15: Vector maximum/minimum: Add 128-bit integer support
For previous architectures emulate operation max/min.
gcc/ChangeLog:
* config/s390/s390-builtins.def: Add 128-bit variants and remove
bool variants.
* config/s390/s390-builtin-types.def: Update accordinly.
* config/s390/s390.md: Emulate min/max for GPR.
* config/s390/vector.md: Add min/max patterns and emulate in
case of no VXE3.
gcc/testsuite/ChangeLog:
* gcc.target/s390/vector/vec-max-emu.c: New test.
* gcc.target/s390/vector/vec-min-emu.c: New test.
* gcc.target/s390/vxe3/vd-1.c: New test.
* gcc.target/s390/vxe3/vd-2.c: New test.
* gcc.target/s390/vxe3/vdl-1.c: New test.
* gcc.target/s390/vxe3/vdl-2.c: New test.
* gcc.target/s390/vxe3/vr-1.c: New test.
* gcc.target/s390/vxe3/vr-2.c: New test.
* gcc.target/s390/vxe3/vrl-1.c: New test.
* gcc.target/s390/vxe3/vrl-2.c: New test.
Add vector single element 128-bit integer support utilizing new
instructions vclzq and vctzq. Furthermore, add scalar 64-bit integer
support utilizing new instructions clzg and ctzg. For ctzg, also define
the resulting value if the input operand equals zero.
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_vec_cntlz): Add 128-bit
integer overloads.
(s390_vclzq): Add.
(s390_vec_cnttz): Add 128-bit integer overloads.
(s390_vctzq): Add.
* config/s390/s390-builtin-types.def: Update accordingly.
* config/s390/s390.h (CTZ_DEFINED_VALUE_AT_ZERO): Define.
* config/s390/s390.md (*clzg): New insn.
(clztidi2): Exploit new insn for target arch15.
(ctzdi2): New insn.
* config/s390/vector.md (clz<mode>2): Extend modes including
128-bit integer.
(ctz<mode>2): Likewise.
* gcc.target/s390/vxe3/veval-1.c: New test.
* gcc.target/s390/vxe3/veval-2.c: New test.
* gcc.target/s390/vxe3/veval-3.c: New test.
* gcc.target/s390/vxe3/veval-4.c: New test.
* gcc.target/s390/vxe3/veval-5.c: New test.
* gcc.target/s390/vxe3/veval-6.c: New test.
* gcc.target/s390/vxe3/veval-7.c: New test.
* gcc.target/s390/vxe3/veval-8.c: New test.
* gcc.target/s390/vxe3/veval-9.c: New test.
* gcc.target/s390/llxa-1.c: New test.
* gcc.target/s390/llxa-2.c: New test.
* gcc.target/s390/llxa-3.c: New test.
* gcc.target/s390/lxa-1.c: New test.
* gcc.target/s390/lxa-2.c: New test.
* gcc.target/s390/lxa-3.c: New test.
* gcc.target/s390/lxa-4.c: New test.
Currently TOINTVEC maps scalar mode TI/TF to vector mode V1TI/V1TF,
respectively. As a consequence we may end up with patterns with a
mixture of scalar and vector modes as e.g. for
This is cumbersome since gen_vec_sel0ti() and gen_vec_sel0tf() require
that operands 3 and 4 are of vector mode whereas the remainder of
operands must be of scalar mode. Likewise for tointvec.
Fixed by staying scalar.
gcc/ChangeLog:
* config/s390/vector.md: Stay scalar for TOINTVEC/tointvec.
Kito Cheng [Wed, 15 Jan 2025 08:13:05 +0000 (16:13 +0800)]
RISC-V: Add sifive_vector.h
sifive_vector.h is a vendor specfic header, it should include before
using sifive vector intrinsic, it's just include riscv_vector.h for now,
we will separate the implementation by adding new pragma in future.
Hongyu Wang [Fri, 17 Jan 2025 01:04:17 +0000 (09:04 +0800)]
i386: Fix wrong insn generated by shld/shrd ndd split [PR118510]
For shld/shrd_ndd_2 insn, the spiltter outputs wrong pattern that
mixed parallel for clobber and set. Use register_operand as dest
and ajdust output template to fix.
gcc/ChangeLog:
PR target/118510
* config/i386/i386.md (*x86_64_shld_ndd_2): Use register_operand
for operand[0] and adjust the output template to directly
generate ndd form shld pattern.
(*x86_shld_ndd_2): Likewise.
(*x86_64_shrd_ndd_2): Likewise.
(*x86_shrd_ndd_2): Likewise.
gcc/testsuite/ChangeLog:
PR target/118510
* gcc.target/i386/pr118510.c: New test.
Dimitar Dimitrov [Sat, 18 Jan 2025 18:19:43 +0000 (20:19 +0200)]
testsuite: Fixes for test case pr117546.c
This test fails on AVR.
Debugging the test on x86 host, I noticed that u in function s sometimes
has value 16128. The "t <= 3 * u" expression in the same function
results in signed integer overflow for targets with sizeof(int)=2.
Jakub Jelinek [Sat, 18 Jan 2025 20:50:23 +0000 (21:50 +0100)]
c++: Copy over further 2 flags for !TREE_PUBLIC in copy_linkage [PR118513]
The following testcase ICEs in import_export_decl.
When cp_finish_decomp handles std::tuple* using structural binding,
it calls copy_linkage to copy various VAR_DECL flags from the structured
binding base to the individual sb variables.
In this case the base variable is in anonymous union, so we call
constrain_visibility (..., VISIBILITY_ANON, ...) on it which e.g.
clears TREE_PUBLIC etc. (flags which copy_linkage copies) but doesn't
copy over DECL_INTERFACE_KNOWN/DECL_NOT_REALLY_EXTERN.
When cp_finish_decl calls determine_visibility on the individual sb
variables, those have !TREE_PUBLIC since copy_linkage and so nothing tries
to determine visibility and nothing sets DECL_INTERFACE_KNOWN and
DECL_NOT_REALLY_EXTERN.
Now, this isn't a big deal without modules, the individual variables are
var_finalized_p and so nothing really cares about missing
DECL_INTERFACE_KNOWN. But in the module case the variables are streamed
out and in and care about those bits.
The following patch is an attempt to copy over also those flags (but I've
limited it to the !TREE_PUBLIC case just in case). Other option would be
to call it unconditionally, or call constrain_visibility with
VISIBILITY_ANON for !TREE_PUBLIC (but are all !TREE_PUBLIC constrained
visibility) or do it only in the cp_finish_decomp case
after the copy_linkage call there.
2025-01-18 Jakub Jelinek <jakub@redhat.com>
PR c++/118513
* decl2.cc (copy_linkage): If not TREE_PUBLIC, also set
DECL_INTERFACE_KNOWN, assert it was set on decl and copy
DECL_NOT_REALLY_EXTERN flags.
* g++.dg/modules/decomp-3_a.H: New test.
* g++.dg/modules/decomp-3_b.C: New test.
Jeff Law [Sat, 18 Jan 2025 20:44:33 +0000 (13:44 -0700)]
[RISC-V][PR target/116308] Fix generation of initial RTL for atomics
While this wasn't originally marked as a regression, it almost certainly is
given that older versions of GCC would have used libatomic and would not have
ICE'd on this code.
Basically this is another case where we directly used simplify_gen_subreg when
we should have used gen_lowpart.
When I fixed a similar bug a while back I noted the code in question as needing
another looksie. I think at that time my brain saw the mixed modes (SI & QI)
and locked up. But the QI stuff is just the shift count, not some deeper
issue. So fixing is trivial.
We just replace the simplify_gen_subreg with a gen_lowpart and get on with our
lives.
Tested on rv64 and rv32 in my tester. Waiting on pre-commit testing for final
verdict.
PR target/116308
gcc/
* config/riscv/riscv.cc (riscv_lshift_subword): Use gen_lowpart
rather than simplify_gen_subreg.
Michal Jires [Thu, 16 Jan 2025 13:42:59 +0000 (14:42 +0100)]
Fix uniqueness of symtab_node::get_dump_name.
symtab_node::get_dump_name uses node order to identify nodes.
Order is no longer unique because of Incremental LTO patches.
This patch moves uid from cgraph_node node to symtab_node,
so get_dump_name can use uid instead and get back unique dump names.
In inlining passes, uid is replaced with more appropriate (more compact
for indexing) summary id.
Bootstrapped/regtested on x86_64-linux.
Ok for trunk?
gcc/ChangeLog:
* cgraph.cc (symbol_table::create_empty):
Move uid to symtab_node.
(test_symbol_table_test): Change expected dump id.
* cgraph.h (struct cgraph_node):
Move uid to symtab_node.
(symbol_table::register_symbol): Likewise.
* dumpfile.cc (test_capture_of_dump_calls):
Change expected dump id.
* ipa-inline.cc (update_caller_keys):
Use summary id instead of uid.
(update_callee_keys): Likewise.
* symtab.cc (symtab_node::get_dump_name):
Use uid instead of order.
Eric Botcazou [Sat, 18 Jan 2025 17:58:02 +0000 (18:58 +0100)]
Fix bootstrap failure on SPARC with -O3 -mcpu=niagara4
This is a regression present on the mainline only, but the underlying issue
has been latent for years: the compiler and the assembler disagree on the
support of the VIS 3B SIMD ISA, the former bundling it with VIS 3 but not
the latter. IMO the documentation is not very clear, so this patch just
aligns the compiler with the assembler.
Jin Ma [Sat, 18 Jan 2025 14:43:17 +0000 (07:43 -0700)]
[PR target/118357] RISC-V: Disable fusing vsetvl instructions by VSETVL_VTYPE_CHANGE_ONLY for XTheadVector.
In RVV 1.0, the instruction "vsetvli zero,zero,*" indicates that the
available vector length (avl) does not change. However, in XTheadVector,
this same instruction signifies that the avl should take the maximum value.
Consequently, when fusing vsetvl instructions, the optimization labeled
"VSETVL_VTYPE_CHANGE_ONLY" is disabled for XTheadVector.
PR target/118357
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc: Function change_vtype_only_p always
returns false for XTheadVector.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/pr118357.c: New test.
Richard Biener [Fri, 17 Jan 2025 14:41:19 +0000 (15:41 +0100)]
tree-optimization/118529 - ICE with condition vectorization
On sparc we end up choosing vector(8) <signed-boolean:1> for the
condition but vector(2) int for the value of a COND_EXPR but we
fail to verify their shapes match and thus things go downhill.
This is a missed-optimization on the pattern recognition side
as well as unhandled vector decomposition in vectorizable_condition.
The following plugs just the observed ICE for now.
PR tree-optimization/118529
* tree-vect-stmts.cc (vectorizable_condition): Check the
shape of the vector and condition vector type are compatible.
Akram Ahmad [Fri, 17 Jan 2025 17:43:49 +0000 (17:43 +0000)]
AArch64: Use standard names for saturating arithmetic
This renames the existing {s,u}q{add,sub} instructions to use the
standard names {s,u}s{add,sub}3 which are used by IFN_SAT_ADD and
IFN_SAT_SUB.
The NEON intrinsics for saturating arithmetic and their corresponding
builtins are changed to use these standard names too.
Using the standard names for the instructions causes 32 and 64-bit
unsigned scalar saturating arithmetic to use the NEON instructions,
resulting in an additional (and inefficient) FMOV to be generated when
the original operands are in GP registers. This patch therefore also
restores the original behaviour of using the adds/subs instructions
in this circumstance.
Additional tests are written for the scalar and Adv. SIMD cases to
ensure that the correct instructions are used. The NEON intrinsics are
already tested elsewhere.
gcc/ChangeLog:
* config/aarch64/aarch64-builtins.cc: Expand iterators.
* config/aarch64/aarch64-simd-builtins.def: Use standard names
* config/aarch64/aarch64-simd.md: Use standard names, split insn
definitions on signedness of operator and type of operands.
* config/aarch64/arm_neon.h: Use standard builtin names.
* config/aarch64/iterators.md: Add VSDQ_I_QI_HI iterator to
simplify splitting of insn for unsigned scalar arithmetic.
Jakub Jelinek [Sat, 18 Jan 2025 08:14:27 +0000 (09:14 +0100)]
c++: Fix up find_array_ctor_elt RAW_DATA_CST handling [PR118534]
This is the third bug discovered today with the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html
hack but then turned into proper testcases where embed-24.C FAILed
since introduction of optimized #embed support and the others when
optimizing large C++ initializers using RAW_DATA_CST.
find_array_ctor_elt already has RAW_DATA_CST support, but on the
following testcases it misses one case I've missed.
The CONSTRUCTORs in question went through the braced_list_to_string
optimization which can turn INTEGER_CST RAW_DATA_CST INTEGER_CST
into just larger RAW_DATA_CST covering even those 2 bytes around it
(if they appear there in the underlying RAW_DATA_OWNER).
With this optimization, RAW_DATA_CST can be the last CONSTRUCTOR_ELTS
elt in a CONSTRUCTOR, either the sole one or say preceeded by some
unrelated other elements. Now, if RAW_DATA_CST is the only one or
if there are no RAW_DATA_CSTs earlier in CONSTRUCTOR_ELTS, we can
trigger a bug in find_array_ctor_elt.
It has a smart optimization for the very common case where
CONSTRUCTOR_ELTS have indexes and index of the last elt is equal
to CONSTRUCTOR_NELTS (ary) - 1, then obviously we know there are
no RAW_DATA_CSTs before it and the indexes just go from 0 to nelts-1,
so when we care about any of those earlier indexes, we can just return i;
and not worry about anything.
Except it uses if (i < end) return i; rather than if (i < end - 1) return i;
For the latter cases, i.e. anything before the last elt, we know there
are no surprises and return i; is right. But for the if (i == end - 1)
case, return i; is only correct if the last elt is not RAW_DATA_CST, if it
is RAW_DATA_CST, we still need to split it, which is handled by the code
later in the function. So, for that we need begin = end - 1, so that the
binary search will just care about that last element.
2025-01-18 Jakub Jelinek <jakub@redhat.com>
PR c++/118534
* constexpr.cc (find_array_ctor_elt): Don't return i early if
i == end - 1 and the last elt's value is RAW_DATA_CST.
* g++.dg/cpp/embed-24.C: New test.
* g++.dg/cpp1y/pr118534.C: New test.
Xi Ruoyao [Thu, 5 Sep 2024 16:34:55 +0000 (00:34 +0800)]
LoongArch: Fix cost model for alsl
Our cost model for alsl was wrong: it matches (a + b * imm) where imm is
1, 2, 3, or 4 (should be 2, 4, 8, or 16), and it does not match
(a + (b << imm)) at all. For the test case:
a += c << 3;
b += c << 3;
it caused the compiler to perform a CSE and make one slli and two add,
but we just want two alsl.
Also add a "code == PLUS" check to prevent matching a - (b << imm) as we
don't have any "slsl" instruction.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_rtx_costs): Fix the
cost for (a + b * imm) and (a + (b << imm)) which can be
implemented with a single alsl instruction.
[PR118067][LRA]: Check secondary memory mode for the reg class
This is the second patch for the PR for the new test. The patch
solves problem in the case when secondary memory mode (SImode in the
PR test) returned by hook secondary_memory_needed_mode can not be used
for reg class (ALL_MASK_REGS) involved in secondary memory moves. The
patch uses reg mode instead of one returned by
secondary_memory_needed_mode in this case.
gcc/ChangeLog:
PR rtl-optimization/118067
* lra-constraints.cc (invalid_mode_reg_p): New function.
(curr_insn_transform): Use it to check mode returned by target
secondary_memory_needed_mode.
Jakub Jelinek [Fri, 17 Jan 2025 20:00:50 +0000 (21:00 +0100)]
testsuite: Make embed-10.c test more robust
With the https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html
hack we get slightly different error wording in one of the errors, given that
the test actually does use #embed, I think both wordings are just fine and
we should accept them.
2025-01-17 Jakub Jelinek <jakub@redhat.com>
* c-c++-common/cpp/embed-10.c: Allow a different error wording for
C++.
Jakub Jelinek [Fri, 17 Jan 2025 18:27:59 +0000 (19:27 +0100)]
s390: Replace some checking assertions with output_operand_lossage [PR118511]
r15-2002 s390: Fully exploit vgm, vgbm, vrepi change added
some code to print_operand and added gcc_checking_asserts in there.
But print_operand ideally should have no assertions in it, as most
of the assumptions can be easily violated by people using it in
inline asm.
This issue in particular was seen by failure to compile s390-tools,
which had in its extended inline asm uses of %r1 and %r2.
I really don't know if they meant %%r1 and %%r2 or %1 and %2 and
will leave that decision to the maintainers, but the thing is that
%r1 and %r2 used to expand like %1 and %2 in GCC 14 and earlier,
now in checking build it ICEs and in --enable-checking=release build
fails to assemble (the checking assert is ignored and the compiler just uses
some uninitialized variables to emit something arbitrary).
With the following patch it is diagnosed as error consistently
regardless if it is release checking or no checking or checking compiler.
Note, I see also
else if (GET_CODE (x) == UNSPEC && XINT (x, 1) == UNSPEC_TLSLDM)
{
fprintf (file, "%s", ":tls_ldcall:");
const char *name = get_some_local_dynamic_name ();
gcc_assert (name);
assemble_name (file, name);
}
in print_operand, maybe that isn't a big deal because it might be
impossible to construct inline asm argument which is UNSPEC_TLSLDM.
And then there is
case 'e': case 'f':
case 's': case 't':
{
int start, end;
int len;
bool ok;
len = (code == 's' || code == 'e' ? 64 : 32);
ok = s390_contiguous_bitmask_p (ival, true, len, &start, &end);
gcc_assert (ok);
if (code == 's' || code == 't')
ival = start;
else
ival = end;
}
break;
which likely should be also output_operand_lossage but I haven't tried
to reproduce that.
2025-01-17 Jakub Jelinek <jakub@redhat.com>
PR target/118511
* config/s390/s390.cc (print_operand) <case 'p'>: Use
output_operand_lossage instead of gcc_checking_assert.
(print_operand) <case 'q'>: Likewise.
(print_operand) <case 'r'>: Likewise.
Tamar Christina [Fri, 17 Jan 2025 17:43:49 +0000 (17:43 +0000)]
AArch64: Use standard names for saturating arithmetic
This renames the existing {s,u}q{add,sub} instructions to use the
standard names {s,u}s{add,sub}3 which are used by IFN_SAT_ADD and
IFN_SAT_SUB.
The NEON intrinsics for saturating arithmetic and their corresponding
builtins are changed to use these standard names too.
Using the standard names for the instructions causes 32 and 64-bit
unsigned scalar saturating arithmetic to use the NEON instructions,
resulting in an additional (and inefficient) FMOV to be generated when
the original operands are in GP registers. This patch therefore also
restores the original behaviour of using the adds/subs instructions
in this circumstance.
Additional tests are written for the scalar and Adv. SIMD cases to
ensure that the correct instructions are used. The NEON intrinsics are
already tested elsewhere.
gcc/ChangeLog:
* config/aarch64/aarch64-builtins.cc: Expand iterators.
* config/aarch64/aarch64-simd-builtins.def: Use standard names
* config/aarch64/aarch64-simd.md: Use standard names, split insn
definitions on signedness of operator and type of operands.
* config/aarch64/arm_neon.h: Use standard builtin names.
* config/aarch64/iterators.md: Add VSDQ_I_QI_HI iterator to
simplify splitting of insn for unsigned scalar arithmetic.
The built-in __builtin_vsx_xvcvuxwdp can be covered with PVIPR
function vec_doubleo on LE and vec_doublee on BE. There are no test
cases or documentation for __builtin_vsx_xvcvuxwdp. This patch
removes the redundant built-in.
Carl Love [Wed, 31 Jul 2024 20:40:34 +0000 (16:40 -0400)]
rs6000, remove built-ins __builtin_vsx_vperm_8hi and __builtin_vsx_vperm_8hi_uns
The two built-ins __builtin_vsx_vperm_8hi and __builtin_vsx_vperm_8hi_uns
are redundant. The are covered by the overloaded vec_perm built-in. The
built-ins are not documented and do not have test cases.
The removal of these built-ins was missed in commit gcc r15-1923 on
7/9/2024.
Carl Love [Wed, 31 Jul 2024 20:31:34 +0000 (16:31 -0400)]
rs6000, add testcases to the overloaded vec_perm built-in
The overloaded vec_perm built-in supports permuting signed and unsigned
vectors of char, bool char, short int, short bool, int, bool, long long
int, long long bool, int128, float and double. However, not all of the
supported arguments are included in the test cases. This patch adds
the missing test cases.
Additionally, in the 128-bit debug print statements the expected result and
the result need to be cast to unsigned long long to print correctly. The
patch makes this additional change to the print statements.
gcc/ChangeLog:
* doc/extend.texi: Fix spelling mistake in description of the
vec_sel built-in. Add documentation of the 128-bit vec_perm
instance.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/vsx-builtin-3.c: Add vec_perm test cases for
arguments of type vector signed long long int, long long bool,
bool, bool short, bool char and pixel, vector unsigned long long
int, unsigned int, unsigned short int, unsigned char. Cast
arguments for debug prints to unsigned long long.
* gcc.target/powerpc/builtins-4-int128-runnable.c: Add vec_perm
test cases for signed and unsigned int128 arguments.
Carl Love [Thu, 3 Oct 2024 01:05:08 +0000 (21:05 -0400)]
rs6000, fix test builtins-1-p10-runnable.c
The test has two issues:
1) The test should generate execute abort() if an error is found.
However, the test contains a #define 0 which actually enables the
error prints not exectuting void() because the debug code is protected
by an #ifdef not #if. The #define DEBUG needs to be removed to so the
test will abort on an error.
2) The vec_i_expected output was tweeked to test that it would fail.
The test value was not removed.
By removing the #define DEBUG, the test fails and reports 1 failure.
Removing the intentionally wrong expected value results in the test
passing with no errors as expected.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/builtins-1-p10-runnable.c: Remove #define
DEBUG. Replace vec_i_expected value with correct value.
Georg-Johann Lay [Fri, 17 Jan 2025 12:14:51 +0000 (13:14 +0100)]
AVR: Add "const" attribute to avr built-in functions if possible.
gcc/
* config/avr/avr-c.cc (DEF_BUILTIN): Add ATTRS argument to macro
definition.
* config/avr/avr.cc: Same.
(avr_init_builtins) <attr_const>: New variable that can be used
as ATTRS argument in DEF_BUILTIN.
* config/avr/builtins.def (DEF_BUILTIN): Add ATTRS parameter
to all definitions.
Nathaniel Shead [Fri, 17 Jan 2025 10:29:08 +0000 (21:29 +1100)]
c++/modules: Propagate FNDECL_USED_AUTO when propagating deduced return types [PR118049]
In the linked testcase, we're erroring because the declared return types
of the functions do not appear to match. This is because when merging
the deduced return types for 'foo' in 'auto-5_b.C', we overwrote the
return type for the declaration with the deduced return type from
'auto-5_a.C' but neglected to track that we were originally declared
with 'auto'.
As a drive-by improvement to QOI, also add checks for if the deduced
return types do not match; this is currently useful because we do not
check the equivalence of the bodies of functions yet.
PR c++/118049
gcc/cp/ChangeLog:
* module.cc (trees_in::is_matching_decl): Propagate
FNDECL_USED_AUTO as well.
gcc/testsuite/ChangeLog:
* g++.dg/modules/auto-5_a.C: New test.
* g++.dg/modules/auto-5_b.C: New test.
* g++.dg/modules/auto-5_c.C: New test.
* g++.dg/modules/auto-6_a.H: New test.
* g++.dg/modules/auto-6_b.C: New test.
Tobias Burnus [Fri, 17 Jan 2025 13:25:18 +0000 (14:25 +0100)]
OpenMP/C++: Fix declare_variant's 'adjust_args' if there is a 'this' pointer [PR118321]
The adjust_args clause is internally store as the i-th argument to the function,
which fails if hidden arguments come before. This commit handles the C++ 'this'
pointer by shifting the internal arg index by one.
PR fortran/118321
gcc/cp/ChangeLog:
* decl.cc (omp_declare_variant_finalize_one): Shift adjust_args index
by one for non-static class function's 'this' pointer.
Nathaniel Shead [Fri, 20 Dec 2024 11:09:39 +0000 (22:09 +1100)]
c++: Allow pragmas in NSDMIs [PR118147]
This patch removes the (unnecessary) CPP_PRAGMA_EOL case from
cp_parser_cache_defarg, which currently has the result that any pragmas
in the NSDMI cause an error.
PR c++/118147
gcc/cp/ChangeLog:
* parser.cc (cp_parser_cache_defarg): Don't error when
CPP_PRAGMA_EOL.
Richard Biener [Fri, 17 Jan 2025 12:18:11 +0000 (13:18 +0100)]
testsuite/117958 - ifcombine differences on aarch64 vs rest
ifcombine depends on BRANCH_COST and the testcase relies on ifcombine
to fully optimize the function. But the important parts are optimized
everywhere, so the following delectively XFAILs the less important part.
PR testsuite/117958
* g++.dg/tree-ssa/pr117123.C: XFAIL parts on aarch64-*-*.
Jakub Jelinek [Fri, 17 Jan 2025 10:30:07 +0000 (11:30 +0100)]
match.pd: Fix (FTYPE) N CMP (FTYPE) M optimization for GENERIC [PR118522]
The last case of this optimization assumes that if 2 integral types
have same precision and TYPE_UNSIGNED, then they are uselessly convertible.
While that is very likely the case for GIMPLE, it is not the case for
GENERIC, so the following patch adds there a convert so that the
optimization produces also valid GENERIC. Without it we got
(int) p == b where b had _BitInt(32) type, so incompatible types.
2025-01-17 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/118522
* match.pd ((FTYPE) N CMP (FTYPE) M): Add convert, as in GENERIC
integral types with the same precision and sign might actually not
be compatible types.
Simon Martin [Sun, 5 Jan 2025 09:36:47 +0000 (10:36 +0100)]
c++: Friend classes don't shadow enclosing template class paramater [PR118255]
We currently reject the following code
=== code here ===
template <int non_template> struct S { friend class non_template; };
class non_template {};
S<0> s;
=== code here ===
While EDG agrees with the current behaviour, clang and MSVC don't (see
https://godbolt.org/z/69TGaabhd), and I believe that this code is valid,
since the friend clause does not actually declare a type, so it cannot
shadow anything. The fact that we didn't error out if the non_template
class was declared before S backs this up as well.
This patch fixes this by skipping the call to check_template_shadow for
hidden bindings.
PR c++/118255
gcc/cp/ChangeLog:
* name-lookup.cc (pushdecl): Don't call check_template_shadow
for hidden bindings.
gcc/testsuite/ChangeLog:
* g++.dg/lookup/pr99116-1.C: Adjust test expectation.
* g++.dg/template/friend84.C: New test.
Richard Biener [Mon, 13 Jan 2025 12:24:06 +0000 (13:24 +0100)]
tree-optimization/92539 - missed optimization leads to bogus -Warray-bounds
The following makes niter analysis recognize a loop with an exit
condition scanning over a STRING_CST. This is done via enhancing
the force evaluation code rather than recognizing for example
strlen (s) as number of iterations because it allows to handle
some more cases.
STRING_CSTs are easy to handle since nothing can write to them, also
processing those should be cheap. I've refrained from handling
anything besides char8_t.
Note to avoid the -Warray-bound dianostic we have to either early unroll
the loop (there's no final value replacement done, there's a PR
for doing this as part of CD-DCE when possibly eliding a loop),
or create a canonical IV so we can DCE the loads. The latter is what
the patch does, also avoiding to repeatedly force-evaluate niters.
This also makes final value replacement work again since now ivcanon
is after it.
There are some testsuite adjustments needed, in particular we now
unroll some loops early, causing messages to appear in different
passes but also vectorization to now no longer happening on
outer loops. The changes mitigate that.
PR tree-optimization/92539
* tree-ssa-loop-ivcanon.cc (tree_unroll_loops_completely_1):
Also try force-evaluation if ivcanon did not yet run.
(canonicalize_loop_induction_variables):
When niter was computed constant by force evaluation add a
canonical IV if we didn't unroll.
* tree-ssa-loop-niter.cc (loop_niter_by_eval): When we
don't find a proper PHI try if the exit condition scans
over a STRING_CST and simulate that.
* g++.dg/warn/Warray-bounds-pr92539.C: New testcase.
* gcc.dg/tree-ssa/sccp-16.c: New testcase.
* g++.dg/vect/pr87621.cc: Use larger power to avoid
inner loop unrolling.
* gcc.dg/vect/pr89440.c: Use larger loop bound to avoid
inner loop unrolling.
* gcc.dg/pr77975.c: Scan cunrolli dump and adjust.
Monk Chiang [Fri, 15 Nov 2024 05:38:48 +0000 (13:38 +0800)]
RISC-V: Add Zicfiss ISA extension.
This patch is implemented according to the RISC-V CFI specification.
It supports the generation of shadow stack instructions in the prologue,
epilogue, non-local gotos, and unwinding.
Iain Buclaw [Thu, 16 Jan 2025 23:23:45 +0000 (00:23 +0100)]
d: Fix record layout of compiler-generated TypeInfo_Class [PR115249]
In r14-8766, the layout of TypeInfo_Class changed in the runtime
library, but didn't get reflected in the compiler-generated data,
causing a corruption of runtime type introspection on BigEndian targets.
This adjusts the size of the `ClassFlags' field from uint to ushort, and
adds a new ushort `depth' field in the space where ClassFlags used to
occupy.
After surgically replacing RESULT_DECL within a constexpr call result
(for sake of RVO), we can in some cases simplify the call result
further.
In the below testcase the result of get() during evaluation of a's
initializer is the self-referential CONSTRUCTOR:
{._M_p=(char *) &<retval>._M_local_buf}
which after replacing RESULT_DECL with ctx->object (aka *D.2603, where
the D.2603 temporary points to the current element of _M_elems under
construction) becomes:
{._M_p=(char *) &D.2603->_M_local_buf}
but what we really want is:
{._M_p=(char *) &a._M_elems[0]._M_local_buf}.
so that the value of _M_p is independent of the value of the mutable
D.2603 temporary.
So to that end, it seems we should constexpr evaluate the result again
after RESULT_DECL replacement, which is what this patch implements.
PR c++/105440
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_call_expression): If any RESULT_DECLs get
replaced in the call result, try further evaluating the result.
Since the machine-independent widening multiply logic was improved
PR113560, ARM's wmul-[567].c fail. AFAICT the logic takes advantage
of the fact that, after zero-extending a narrow integral type to a
wider type, further zero- or sign-extending is equivalent, which
enables different instructions to be used for equivalent effect.
Adjust the tests to accept all the equivalent instructions that can be
used.
Alexandre Oliva [Thu, 16 Jan 2025 23:19:41 +0000 (20:19 -0300)]
[testsuite] [arm] multilibs.exp: adjust float abi opt matching
The regexp that matches options that mess with multilibs matches
-mfloat=abi=, but that's probably a typo for -mfloat-abi=. Fix that,
and add -msoft-float and -mhard-float.
for gcc/testsuite/ChangeLog
* gcc.target/arm/multilib.exp: Skip if -mfloat-abi=* or any of
its aliases are used.
Alexandre Oliva [Thu, 16 Jan 2025 23:19:28 +0000 (20:19 -0300)]
[testsuite] rearrange requirements for dfp bitint run tests
dfp.exp sets the default to compile when dfprt is not available, but
some dfp bitint tests override the default without that requirement,
and try to run even when dfprt is not available.
Instead of overriding the default, rewrite the requirements so that
they apply even when compiling, since the absence of bitint or of
int128 would presumably cause compile failures.
Tobias Burnus [Thu, 16 Jan 2025 21:39:03 +0000 (22:39 +0100)]
Fortran/OpenMP: Fix declare_variant's 'adjust_args' mishandling with return by reference [PR118321]
declare_variant's 'adjust_args' clause references the arguments in the
middle end by the argument position; this has to account for hidden
arguments that are inserted before due to return by reference,
as done in this commit.
PR fortran/118321
gcc/fortran/ChangeLog:
* trans-openmp.cc (gfc_trans_omp_declare_variant): Honor hidden
arguments for append_arg's need_device_ptr.
Patrick Palka [Thu, 16 Jan 2025 21:40:08 +0000 (16:40 -0500)]
c++: explicit spec of constrained member tmpl [PR107522]
When defining a explicit specialization of a constrained member template
(of a class template) such as f and g in the below testcase, the
DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are partially
instantiated, whereas its associated constraints are carried over
from the original template and thus are in terms of the original
DECL_TEMPLATE_PARMS. So during normalization for such an explicit
specialization we need to consider the (parameters of) the most general
template, since that's what the constraints are in terms of and since we
always use the full set of template arguments during satisfaction.
PR c++/107522
gcc/cp/ChangeLog:
* constraint.cc (get_normalized_constraints_from_decl): Use the
most general template for an explicit specialization of a
member template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-explicit-spec7.C: New test.
Patrick Palka [Thu, 16 Jan 2025 21:08:25 +0000 (16:08 -0500)]
c++: pack expansion arg vs non-pack parm checking ICE [PR118454]
During ahead of time template argument coercion, we handle the case of
passing a pack expansion to a non-pack parameter by breaking out early
and using the original unconverted arguments, deferring coercion until
instantiation time where we have concrete arguments.
This PR illustrates we still need to strip typedefs from the original
arguments in this case as in the ordinary case, for sake of our template
argument hashing/equivalence routines which assume template arguments
went through strip_typedefs.
Since we're using the unconverted arguments we need to preserve
injected-class-name typedefs because we use them to distinguish passing
an injected-class-name vs the corresponding specialization as the
argument to a template template parameter (the former is valid, the
latter isn't).
PR c++/118454
gcc/cp/ChangeLog:
* cp-tree.h (STF_KEEP_INJ_CLASS_NAME): Define.
* pt.cc (iterative_hash_template_argument) <case tcc_type>:
Clarify comment for when we'd see an alias template
specialization here.
(coerce_template_parms): Strip typedefs (except for
injected-class-names) in the pack expansion early break cases
that defer coercion.
* tree.cc (strip_typedefs): Don't strip an injected-class-name
if STF_KEEP_INJ_CLASS_NAME is set.
projects / thirdparty / gcc.git / log
