unadjusted_ptr_and_unit_offset accidentally throws away the offset computed by
get_addr_base_and_unit_offset. Instead of passing extra_offset it passes offset.
PR ipa/114207
gcc/ChangeLog:
* ipa-prop.cc (unadjusted_ptr_and_unit_offset): Fix accounting of offsets in ADDR_EXPR.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/pr114207.c: New test.
(cherry picked from commit 391f46f10b0586c074014de82efe76787739bb0c)
Hi,
this testcase shows another poblem with missing comparators for metadata
in ICF. With value ranges available to loop optimizations during early
opts we can estimate number of iterations based on guarding condition that
can be split away by the fnsplit pass. This patch disables ICF when
number of iteraitons does not match.
Bootstrapped/regtesed x86_64-linux, will commit it shortly
gcc/ChangeLog:
PR ipa/115277
* ipa-icf-gimple.cc (func_checker::compare_loops): compare loop
bounds.
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/pr115277.c: New test.
(cherry picked from commit 0d19fbc7b0760ce665fa6a88cd40cfa0311358d7)
this patch tames down inliner on (mutiply) self-recursive always_inline functions.
While we already have caps on recursive inlning, the testcase combines early inliner
and late inliner to get very wide recursive inlining tree. The basic idea is to
ignore DISREGARD_INLINE_LIMITS when deciding on inlining self recursive functions
(so we cut on function being large) and clear the flag once it is detected.
I did not include the testcase since it still produces a lot of code and would
slow down testing. It also outputs many inlining failed messages that is not
very nice, but it is hard to detect self recursin cycles in full generality
when indirect calls and other tricks may happen.
gcc/ChangeLog:
PR ipa/113291
* ipa-inline.cc (enum can_inline_edge_by_limits_flags): New enum.
(can_inline_edge_by_limits_p): Take flags instead of multiple bools; add flag
for forcing inlinie limits.
(can_early_inline_edge_p): Update.
(want_inline_self_recursive_call_p): Update; use FORCE_LIMITS mode.
(check_callers): Update.
(update_caller_keys): Update.
(update_callee_keys): Update.
(recursive_inlining): Update.
(add_new_edges_to_heap): Update.
(speculation_useful_p): Update.
(inline_small_functions): Clear DECL_DISREGARD_INLINE_LIMITS on self recursion.
(flatten_function): Update.
(inline_to_all_callers_1): Update.
(cherry picked from commit 1ec49897253e093e1ef6261eb104ac0c111bac83)
Use INT_MIN rather than -1 in `comparison_qty' where a comparison is not
with a register, because the value of -1 is actually a valid reference
to register 0 in the case where it has not been assigned a quantity.
Using -1 makes `REG_QTY (REGNO (folded_arg1)) == ent->comparison_qty'
comparison in `fold_rtx' to incorrectly trigger in rare circumstances
and return true for a memory reference, making CSE consider a comparison
operation to evaluate to a constant expression and consequently make the
resulting code incorrectly execute or fail to execute conditional
blocks.
This has caused a miscompilation of rwlock.c from LinuxThreads for the
`alpha-linux-gnu' target, where `rwlock->__rw_writer != thread_self ()'
expression (where `thread_self' returns the thread pointer via a PALcode
call) has been decided to be always true (with `ent->comparison_qty'
using -1 for a reference to to `rwlock->__rw_writer', while register 0
holding the thread pointer retrieved by `thread_self') and code for the
false case has been optimized away where it mustn't have, causing
program lockups.
The issue has been observed as a regression from commit 08a692679f
("Undefined cse.c behaviour causes 3.4 regression on HPUX"),
<https://gcc.gnu.org/ml/gcc-patches/2004-10/msg02027.html>, and up to
commit 932ad4d9b5 ("Make CSE path following use the CFG"),
<https://gcc.gnu.org/ml/gcc-patches/2006-12/msg00431.html>, where CSE
has been restructured sufficiently for the issue not to trigger with the
original reproducer anymore. However the original bug remains and can
trigger, because `comparison_qty' will still be assigned -1 for a memory
reference and the `reg_qty' member of a `cse_reg_info_table' entry will
still be assigned -1 for register 0 where the entry has not been
assigned a quantity, e.g. at initialization.
Use INT_MIN then as noted above, so that the value remains negative, for
consistency with the REGNO_QTY_VALID_P macro (even though not used on
`comparison_qty'), and then so that it should not ever match a valid
negated register number, fixing the regression with commit 08a692679f.
gcc/
PR rtl-optimization/115565
* cse.cc (record_jump_cond): Use INT_MIN rather than -1 for
`comparison_qty' if !REG_P.
(cherry picked from commit 69bc5fb97dc3fada81869e00fa65d39f7def6acf)
Code attribute bhfgq is missing a mapping for TF. This results in
unresolved iterators in assembler templates for *bswaptf.
With the TF mapping added the base mnemonics vlbr and vstbr are not
"used" anymore but only the extended mnemonics (vlbr<bhfgq> was
interpreted as vlbr; likewise for vstbr). Therefore, remove the base
mnemonics from the scheduling description, otherwise, genattrtab would
error about unknown mnemonics.
Likewise, for movtf_vr only the extended mnemonics for vrepi are used,
now, which means the base mnemonic is "unused" and has to be removed
from the scheduling description.
Similarly, we end up with unresolved iterators in assembler templates
for mulfprx23 since code attribute xdee is missing a mapping for FPRX2.
Note, this is basically a cherry pick of commit r15-2060-ga4abda934aa426
with the addition that vrepi is removed from the scheduling description,
too.
gcc/ChangeLog:
* config/s390/3931.md (vlbr, vstbr, vrepi): Remove.
* config/s390/s390.md (xdee): Add FPRX2 mapping.
* config/s390/vector.md (bhfgq): Add TF mapping.
The inner loop in build_option_suggestions uses OPTION to take the
address of OPTB and use it across iterations, which is undefined
behaviour since OPTB is defined within the loop. Pull it outside the
loop to make this defined.
gcc/ChangeLog:
* opt-suggestions.cc
(option_proposer::build_option_suggestions): Pull OPTB
definition out of the innermost loop.
(cherry picked from commit e0d997e913f811ecf4b3e10891e6a4aab5b38a31)
2024-05-13 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/113363
* trans-array.cc (gfc_array_init_size): Use the expr3 dtype so
that the correct element size is used.
* trans-expr.cc (gfc_conv_procedure_call): Remove restriction
that ss and ss->loop be present for the finalization of class
array function results.
(trans_class_assignment): Use free and malloc, rather than
realloc, for character expressions assigned to unlimited poly
entities.
* trans-stmt.cc (gfc_trans_allocate): Build a correct rhs for
the assignment of an unlimited polymorphic 'source'.
gcc/testsuite/
PR fortran/113363
* gfortran.dg/pr113363.f90: New test.
(cherry picked from commit 2d0eeb529d400e61197a09c56011be976dd81ef0)
2024-06-20 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/59104
* dependency.cc (dependency_fcn, gfc_function_dependency): New
functions to detect dependency in array bounds and character
lengths on old style function results.
* dependency.h : Add prototype for gfc_function_dependency.
* error.cc (error_print): Remove trailing space.
* gfortran.h : Remove dummy_order and add fn_result_spec.
* symbol.cc : Remove declaration of next_dummy_order..
(gfc_set_sym_referenced): remove setting of symbol dummy order.
* trans-array.cc (gfc_trans_auto_array_allocation): Detect
non-dummy symbols with function dependencies and put the
allocation at the end of the initialization code.
* trans-decl.cc : Include dependency.h.
(decl_order): New function that determines uses the location
field of the symbol 'declared_at' to determine the order of two
declarations.
(gfc_defer_symbol_init): Call gfc_function_dependency to put
dependent symbols in the right part of the tlink chain. Use
the location field of the symbol declared_at to determine the
order of declarations.
(gfc_trans_auto_character_variable): Put character length
initialization of dependent symbols at the end of the chain.
* trans.cc (gfc_add_init_cleanup): Add boolean argument with
default false that determines whther an expression is placed at
the back or the front of the initialization chain.
* trans.h : Update the prototype for gfc_add_init_cleanup.
gcc/testsuite/
PR fortran/59104
* gfortran.dg/dependent_decls_2.f90: New test.
(cherry picked from commit ccaa39a268bef2a1d8880022696ff2dcaa6af941)
There are various non-IBM CPUs with altivec, so we cannot use that
flag to determine which .machine cpu to use, so ignore it.
Emit an additional ".machine altivec" if Altivec is enabled so
that the assembler doesn't require an explicit -maltivec option
to assemble any Altivec instructions for those targets where
the ".machine cpu" is insufficient to enable Altivec. For example,
-mcpu=G5 emits a ".machine power4".
2024-07-18 René Rebe <rene@exactcode.de>
Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/97367
* config/rs6000/rs6000.cc (rs6000_machine_from_flags): Do not consider
OPTION_MASK_ALTIVEC.
(emit_asm_machine): For Altivec compiles, emit a ".machine altivec".
gcc/testsuite/
PR target/97367
* gcc.target/powerpc/pr97367.c: New test.
Signed-off-by: René Rebe <rene@exactcode.de>
(cherry picked from commit 6962835bca3e6bef0f6ceae84a7814138b08b8a5)
gcc/fortran/ChangeLog:
PR fortran/103115
* trans-array.cc (gfc_trans_array_constructor_value): If the first
element of an array constructor is deferred-length character and
therefore does not have an element size known at compile time, do
not try to collect subsequent constant elements into a constructor
for optimization.
gcc/testsuite/ChangeLog:
PR fortran/103115
* gfortran.dg/string_array_constructor_4.f90: New test.
(cherry picked from commit c93be1606ecf8e0f65b96b67aa023fb456ceb3a3)
As of Xcode 16 beta 2 with the macOS 15 SDK, each re-inclusion of the
stddef.h header causes the NULL macro in C++ to be re-defined to an
integral constant (__null). This makes the workaround in d59a576b8
("Redefine NULL to nullptr") ineffective, as other headers that are
typically included after system.h (such as obstack.h) do include
stddef.h too.
This can be seen by running the sample below through `clang++ -E`
#include <stddef.h>
#define NULL nullptr
#include <stddef.h>
NULL
The relevant libc++ change is here:
2950283ddd
Filed as FB14261859 to Apple and added a comment about it on LLVM PR
86843.
This fixes the cases in --enable-languages=c,c++,objc,obj-c++,rust build
where NULL being an integral constant instead of a null pointer literal
(therefore no longer implicitly converting to a pointer when used as a
template function's argument) caused issues.
gcc/value-pointer-equiv.cc:65:43: error: no viable conversion from `pair<typename __unwrap_ref_decay<long>::type, typename __unwrap_ref_decay<long>::type>' to 'const pair<tree, tree>'
65 | const std::pair <tree, tree> m_marker = std::make_pair (NULL, NULL);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
As noted in the previous commit though, the proper solution would be to
phase out the usages of NULL in GCC's C++ source code.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (saved_diagnostic::saved_diagnostic):
Change NULL to nullptr.
(struct null_assignment_sm_context): Likewise.
* infinite-loop.cc: Likewise.
* infinite-recursion.cc: Likewise.
* varargs.cc (va_list_state_machine::on_leak): Likewise.
gcc/rust/ChangeLog:
* metadata/rust-imports.cc (Import::try_package_in_directory):
Change NULL to nullptr.
gcc/ChangeLog:
* value-pointer-equiv.cc: Change NULL to nullptr.
Signed-off-by: Daniel Bertalan <dani@danielbertalan.dev>
(cherry picked from commit 08776bef53835ff6318ecfeade8f6c6896ffd81f)
vwadd.wx and vwsub.wx have the same problem vfwadd.wf had. This patch
splits the insn pattern in the same way vfwadd.wf was split.
It also adds two patterns to recognize extended scalars. In practice
those do not provide a lot of improvement over what we already have but
in some instances we can get rid of redundant extensions.
gcc/ChangeLog:
* config/riscv/vector.md: Split vwadd.wx/vwsub.wx pattern and
add extended_scalar patterns.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr115068.c: Add vwadd.wx/vwsub.wx
tests.
* gcc.target/riscv/rvv/base/pr115068-run.c: Include pr115068.c.
* gcc.target/riscv/rvv/base/vwaddsub-1.c: New test.
(cherry picked from commit 9781885a624f3e29634d95c14cd10940cefb1a5a)
This patch splits the vfw...wf pattern so we do not emit e.g. vfwadd.wf
v0,v8,fa5,v0.t anymore.
gcc/ChangeLog:
PR target/115068
* config/riscv/vector.md: Split vfw<insn>.wf pattern.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr115068-run.c: New test.
* gcc.target/riscv/rvv/base/pr115068.c: New test.
(cherry picked from commit a2fd0812a54cf51520f15e900df4cfb5874b75ed)
--discard-locals (-X) instructs the linker to remove local .L* symbols,
which occur a lot due to label differences for linker relaxation. The
arm port has a similar need and passes -X to ld.
In contrast, the RISC-V port does not pass -X to ld and rely on the
default --discard-locals in GNU ld's riscv port. The arm way is more
conventional (compiler driver instead of the linker customizes the
default linker behavior) and works with lld.
gcc/ChangeLog:
* config/riscv/elf.h (LINK_SPEC): Add -X.
* config/riscv/freebsd.h (LINK_SPEC): Add -X.
* config/riscv/linux.h (LINK_SPEC): Add -X.
(cherry picked from commit 50c218e3ffe57860591a987ecf44fcc0abb31f2c)
The extension parsing table entries for a range of Zic* extensions
does not match the mask definition in riscv.opt.
This results in broken TARGET_ZIC* macros, because the values of
riscv_zi_subext and riscv_zicmo_subext are set wrong.
This patch fixes this by moving Zic64b into riscv_zicmo_subext
and all other affected Zic* extensions to riscv_zi_subext.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Move ziccamoa, ziccif,
zicclsm, and ziccrse into riscv_zi_subext.
* config/riscv/riscv.opt: Define MASK_ZIC64B for
riscv_ziccmo_subext.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
(cherry picked from commit 285300eb928b171236e895f28c960ad02dcb0d67)
For the vfw vx format RVV intrinsic, the scalar type _Float16 also
requires the zvfh extension. Unfortunately, we only check the
vector tree type and miss the scalar _Float16 type checking. For
example:
vfloat32mf2_t test_vfwsub_wf_f32mf2(vfloat32mf2_t vs2, _Float16 rs1, size_t vl)
{
return __riscv_vfwsub_wf_f32mf2(vs2, rs1, vl);
}
It should report some error message like zvfh extension is required
instead of ICE for unreg insn.
This patch would like to make up such kind of validation for _Float16
in the RVV intrinsic API. It will report some error like below when
there is no zvfh enabled.
error: built-in function '__riscv_vfwsub_wf_f32mf2(vs2, rs1, vl)'
requires the zvfhmin or zvfh ISA extension
Passed the rv64gcv fully regression tests, included c/c++/fortran.
PR target/114988
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc
(validate_instance_type_required_extensions): New func impl to
validate the intrinisc func type ops.
(expand_builtin): Validate instance type before expand.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr114988-1.c: New test.
* gcc.target/riscv/rvv/base/pr114988-2.c: New test.
Signed-off-by: Pan Li <pan2.li@intel.com>
(cherry picked from commit 41b3cf262e61aee9d26380f1c820e0eaae740f50)
We have vec_extract pattern which takes ZVFHMIN as the mode
iterator of the V mode. Aka VF_ZVFHMIN iterator. But it will
expand to pred_extract_first pattern which takes the ZVFH as the mode
iterator of the V mode. AKa VF. The mismatch will result in one ICE
similar as below:
insn 30 29 31 2 (set (reg:HF 156 [ _2 ])
(unspec:HF [
(vec_select:HF (reg:RVVMF2HF 134 [ _1 ])
(parallel [
(const_int 0 [0])
]))
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)) "compress_run-2.c":22:3 -1
(nil))
during RTL pass: vregs
compress_run-2.c:25:1: internal compiler error: in extract_insn, at
recog.cc:2812
0xb3bc47 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../gcc/gcc/rtl-error.cc:108
0xb3bc69 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
../../../gcc/gcc/rtl-error.cc:116
0xb3a545 extract_insn(rtx_insn*)
../../../gcc/gcc/recog.cc:2812
0x1010e9e instantiate_virtual_regs_in_insn
../../../gcc/gcc/function.cc:1612
0x1010e9e instantiate_virtual_regs
../../../gcc/gcc/function.cc:1995
0x1010e9e execute
../../../gcc/gcc/function.cc:2042
The below test suites are passed for this patch.
1. The rv64gcv fully regression test.
2. The rv64gcv build with glibc.
There may be other similar issue(s) for the mismatch, we will take care
of them by test cases one by one.
PR target/115456
gcc/ChangeLog:
* config/riscv/vector-iterators.md: Leverage V_ZVFH instead of V
which contains the VF_ZVFHMIN for alignment.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr115456-2.c: New test.
* gcc.target/riscv/rvv/base/pr115456-3.c: New test.
Signed-off-by: Pan Li <pan2.li@intel.com>
(cherry picked from commit c2c61d8902dbda017b1647252d17bce141493433)
We have vec_extract pattern which takes ZVFHMIN as the mode
iterator of the VLS mode. Aka V_VLS. But it will expand to
pred_extract_first pattern which takes the ZVFH as the mode
iterator of the VLS mode. AKa V_VLSF. The mismatch will
result in one ICE similar as below:
error: unrecognizable insn:
27 | }
| ^
(insn 19 18 20 2 (set (reg:HF 150 [ _13 ])
(unspec:HF [
(vec_select:HF (reg:V4HF 134 [ _1 ])
(parallel [
(const_int 0 [0])
]))
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)) "compress_run-2.c":24:5 -1
(nil))
during RTL pass: vregs
compress_run-2.c:27:1: internal compiler error: in extract_insn, at
recog.cc:2812
0x1a627ef _fatal_insn(char const*, rtx_def const*, char const*, int,
char const*)
../../../gcc/gcc/rtl-error.cc:108
0x1a62834 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
../../../gcc/gcc/rtl-error.cc:116
0x1a0f356 extract_insn(rtx_insn*)
../../../gcc/gcc/recog.cc:2812
0x159ee61 instantiate_virtual_regs_in_insn
../../../gcc/gcc/function.cc:1612
0x15a04aa instantiate_virtual_regs
../../../gcc/gcc/function.cc:1995
0x15a058e execute
../../../gcc/gcc/function.cc:2042
This patch would like to fix this issue by align the mode
iterator restriction to ZVFH.
The below test suites are passed for this patch.
1. The rv64gcv fully regression test.
2. The rv64gcv build with glibc.
PR target/115456
gcc/ChangeLog:
* config/riscv/autovec.md: Take ZVFH mode iterator instead of
the ZVFHMIN for the alignment.
* config/riscv/vector-iterators.md: Add 2 new iterator
V_VLS_ZVFH and VLS_ZVFH.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr115456-1.c: New test.
Signed-off-by: Pan Li <pan2.li@intel.com>
(cherry picked from commit 3dac1049c1211e6d06c2536b86445a6334c3866d)
Presently, the code fragment:
int x[5];
void
d(int a, int b, int c) {
for (int i = 0; i < 5; i++)
x[i] = (a != b) ? c : a;
}
causes an ICE when compiled with -O2 -march=rv32i_zicond:
test.c: In function 'd':
test.c: error: unrecognizable insn:
11 | }
| ^
(insn 8 5 9 2 (set (reg:SI 139 [ iftmp.0_2 ])
(if_then_else:SI (ne:SI (reg/v:SI 136 [ a ])
(reg/v:SI 137 [ b ]))
(reg/v:SI 136 [ a ])
(reg/v:SI 138 [ c ]))) -1
(nil))
during RTL pass: vregs
This happens because, as part of one of the optimizations in
riscv_expand_conditional_move(), an if_then_else is generated with both
comparands being register operands, resulting in an unmatchable insn since
Zicond patterns require constant 0 as the second comparand. Fix this by adding
a extra check before performing this optimization.
The code snippet mentioned above is also included in this patch as a new Zicond
testcase.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_conditional_move): Add a
CONST0_RTX check.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zicond-ice-5.c: New test.
(cherry picked from commit eb647daa87b466d0a71246fad302cd81bfce9be5)
This patch changes the tail policy for vmv.s.x from ta to tu.
By default the bug does not show up with qemu because qemu's
current vmv.s.x implementation always uses the tail-undisturbed
policy. With a local qemu version that overwrites the tail
with ones when the tail-agnostic policy is specified, the bug
shows.
gcc/ChangeLog:
* config/riscv/autovec.md: Add TU policy.
* config/riscv/riscv-protos.h (enum insn_type): Define
SCALAR_MOVE_MERGED_OP_TU.
gcc/testsuite/ChangeLog:
PR target/115725
* gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-1.c: Adjust
test expectation.
* gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-4.c: Ditto.
(cherry picked from commit acc3b703c05debc6276451f9daae5d0ffc797eac)
Call handle_implied_ext repeatly until there's no
new subset added into the subset list.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_subset_list::riscv_subset_list):
init m_subset_num to 0.
(riscv_subset_list::add): increase m_subset_num once a subset added.
(riscv_subset_list::finalize): call handle_implied_ext repeatly
until no change in m_subset_num.
* config/riscv/riscv-subset.h: add m_subset_num member.
Signed-off-by: Fei Gao <gaofei@eswincomputing.com>
(cherry picked from commit 682731d11f9c02b24358d1af1e2bf6fca0221ee7)
Here we ICE with -fsanitize=address on
std::initializer_list x = { 1, 2, 3 };
since r14-8681, which removed .ASAN_MARK calls on TREE_STATIC variables.
That means that lower_try_finally now instead of
try
{
.ASAN_MARK (UNPOISON, &C.0, 12);
x = {};
x._M_len = 3;
x._M_array = &C.0;
}
finally
{
.ASAN_MARK (POISON, &C.0, 12);
}
gets:
try
{
x = {};
x._M_len = 3;
x._M_array = &C.0;
}
finally
{
}
and we ICE on the empty finally in lower_try_finally_onedest while
getting get_eh_else.
PR c++/115865
gcc/ChangeLog:
* tree-eh.cc (get_eh_else): Check that the result of
gimple_seq_first_stmt is non-null.
gcc/testsuite/ChangeLog:
* g++.dg/asan/initlist2.C: New test.
Co-authored-by: Jakub Jelinek <jakub@redhat.com>
(cherry picked from commit 1e60a6abfece40c7bf55d6ca0a439078d3f5159a)
A reference to a COMDAT function may be resolved to another definition
outside the current translation unit, so it's not eligible for `-fipa-ra`.
In `decl_binds_to_current_def_p()` there is already a check for weak
symbols. This commit checks for COMDAT functions that are not implemented
as weak symbols, for example, on *-*-mingw32.
gcc/ChangeLog:
PR rtl-optimization/115049
* varasm.cc (decl_binds_to_current_def_p): Add a check for COMDAT
declarations too, like weak ones.
(cherry picked from commit 5080840d8fbf25a321dd27543a1462d393d338bc)
Here we started to ICE with r13-25: in check_trait_type, for "X[]" we
return true here:
if (kind == 1 && TREE_CODE (type) == ARRAY_TYPE && !TYPE_DOMAIN (type))
return true; // Array of unknown bound. Don't care about completeness.
and then end up crashing in record_has_unique_obj_representations:
4836 if (cur != wi::to_offset (sz))
because sz is null.
https://eel.is/c++draft/type.traits#tab:meta.unary.prop-row-47-column-3-sentence-1
says that the preconditions for __has_unique_object_representations are:
"T shall be a complete type, cv void, or an array of unknown bound" and
that "For an array type T, the same result as
has_unique_object_representations_v<remove_all_extents_t<T>>" so T[]
should be treated as T. So we should use kind==2 for the trait.
PR c++/115476
gcc/cp/ChangeLog:
* semantics.cc (finish_trait_expr)
<case CPTK_HAS_UNIQUE_OBJ_REPRESENTATIONS>: Move below to call
check_trait_type with kind==2.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/has-unique-obj-representations4.C: New test.
(cherry picked from commit fc382a373e6824bb998007d1dcb0805b0cf4b8e8)
This patch addresses PR target/115351, which is a code quality regression
on x86 when passing floating point complex numbers. The ABI considers
these arguments to have TImode, requiring interunit moves to place the
FP values (which are actually passed in SSE registers) into the upper
and lower parts of a TImode pseudo, and then similar moves back again
before they can be used.
The cause of the regression is that changes in how TImode initialization
is represented in RTL now prevents the RTL optimizers from eliminating
these redundant moves. The specific cause is that the *concatditi3
pattern, (zext(hi)<<64)|zext(lo), has an inappropriately high (default)
rtx_cost, preventing fwprop1 from propagating it. This pattern just
sets the hipart and lopart of a double-word register, typically two
instructions (less if reload can allocate things appropriately) but
the current ix86_rtx_costs actually returns INSN_COSTS(13), i.e. 52.
propagating insn 5 into insn 6, replacing:
(set (reg:TI 110)
(ior:TI (and:TI (reg:TI 110)
(const_wide_int 0x0ffffffffffffffff))
(ashift:TI (zero_extend:TI (subreg:DI (reg:DF 112 [ zD.2796+8 ]) 0))
(const_int 64 [0x40]))))
successfully matched this instruction to *concatditi3_3:
(set (reg:TI 110)
(ior:TI (ashift:TI (zero_extend:TI (subreg:DI (reg:DF 112 [ zD.2796+8 ]) 0))
(const_int 64 [0x40]))
(zero_extend:TI (subreg:DI (reg:DF 111 [ zD.2796 ]) 0))))
change not profitable (cost 50 -> cost 52)
This issue is resolved by having ix86_rtx_costs return more reasonable
values for these (place-holder) patterns.
2024-06-07 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR target/115351
* config/i386/i386.cc (ix86_rtx_costs): Provide estimates for
the *concatditi3 and *insvti_highpart patterns, about two insns.
gcc/testsuite/ChangeLog
PR target/115351
* g++.target/i386/pr115351.C: New test case.
(cherry picked from commit fb3e4c549d16d5050e10114439ad77149f33c597)
TARGET_MEM_REF can be used to offset constant base into a memory object (to
produce lea instruction). This confuses points_to_local_or_readonly_memory_p
which treats the constant address as a base of the access.
Bootstrapped/regtsted x86_64-linux, comitted.
Honza
gcc/ChangeLog:
PR ipa/113787
* ipa-fnsummary.cc (points_to_local_or_readonly_memory_p): Do not
look into TARGET_MEM_REFS with constant opreand 0.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/pr113787.c: New test.
(cherry picked from commit 96d53252aefcbc2fe419c4c3b4bcd3fc03d4d187)
This patch fixes PR tree-optimization/113673, a P2 ice-on-valid regression
caused by load merging of (ptr[0]<<8)+ptr[1] when -ftrapv has been
specified. When the operator is | or ^ this is safe, but for addition
of signed integer types, a trap may be generated/required, so merging this
idiom into a single non-trapping instruction is inappropriate, confusing
the compiler by transforming a basic block with an exception edge into one
without.
This revision implements Richard Biener's feedback to add an early check
for stmt_can_throw_internal (cfun, stmt) to prevent transforming in the
presence of any statement that could trap, not just overflow on addition.
The one other tweak included in this patch is to mark the local function
find_bswap_or_nop_load as static ensuring that it isn't called from outside
this file, and guaranteeing that it is dominated by stmt_can_throw_internal
checking.
2024-06-24 Roger Sayle <roger@nextmovesoftware.com>
Richard Biener <rguenther@suse.de>
gcc/ChangeLog
PR tree-optimization/113673
* gimple-ssa-store-merging.cc (find_bswap_or_nop_load): Make static.
(find_bswap_or_nop_1): Avoid transformations (load merging) when
stmt_can_throw_internal indicates that a statement can trap.
gcc/testsuite/ChangeLog
PR tree-optimization/113673
* g++.dg/pr113673.C: New test case.
(cherry picked from commit d8b05aef77443e1d3d8f3f5d2c56ac49a503fee3)
As reported on gcc-regression, this test FAILs on aarch64, but my
r15-2090 change didn't change anything on the generated assembly,
just added the forgotten dg-do run directive to the test, so the
test has been failing forever, just we didn't know it.
I can actually reproduce it on x86_64 with -funsigned-char too,
s2.b.a has int type and -1 is stored to it, so we should compare
it against -1 rather than (char) -1; the latter is appropriate for
testing char fields into which we've stored -1.
2024-07-18 Jakub Jelinek <jakub@redhat.com>
* c-c++-common/torture/builtin-clear-padding-3.c (main): Compare
s2.b.a against -1 rather than (char) -1.
(cherry picked from commit 958ee138748fae4371e453eb9b357f576abbe83e)
While lazy loading, instantiation of pendings can sometimes recursively
perform name lookup and begin further lazy loading. When using the
'-ftime-report' functionality this causes ICEs as we could start an
already-running timer for the importing.
This patch fixes the issue by using the 'timevar_cond*' API instead to
support such recursive calls.
PR c++/115165
gcc/cp/ChangeLog:
* module.cc (lazy_load_binding): Use 'timevar_cond*' APIs.
(lazy_load_pendings): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/modules/timevar-1_a.H: New test.
* g++.dg/modules/timevar-1_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
maybe_new_partial_specialization wasn't propagating TYPE_CONTEXT when
creating a new class type corresponding to a constrained partial spec,
which do_friend relies on via template_class_depth to distinguish a
template friend from a non-template friend, and so in the below testcase
we were incorrectly instantiating the non-template operator+ as if it
were a template leading to an ICE.
PR c++/111890
gcc/cp/ChangeLog:
* pt.cc (maybe_new_partial_specialization): Propagate TYPE_CONTEXT
to the newly created partial specialization.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-partial-spec15.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 247335823f420eb1dd56f4bf32ac78d441f5ccc2)
Here we're prematurely stripping the dependent alias template-id A<T> to
its defining-type-id T when used as a template argument, which in turn
causes us to essentially ignore A's vector_size attribute in the outer
template-id.
This has always been a problem for class template-ids it seems, and after
r14-2170 variable template-ids are affected as well.
This patch marks alias templates that have a dependent attribute as
complex (as with e.g. constrained alias templates) so that we don't look
through them prematurely.
PR c++/115897
gcc/cp/ChangeLog:
* pt.cc (complex_alias_template_p): Return true for an alias
template with attributes.
(get_underlying_template): Don't look through an alias template
with attributes.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/alias-decl-77.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 7954bb4fcb6fa80f6bb840133314885011821188)
Here we notice the 'this' conversion for the call f<void>() is bad, so
we correctly defer deduction for the template candidate, but we end up
never adding it to 'bad_cands' since missing_conversion_p for it returns
false (its only argument is 'this' which has already been determined to
be bad). This is not a huge deal, but it causes us to longer accept the
call with -fpermissive in release builds, and a tree check ICE in checking
builds.
So if we have a non-strictly viable template candidate that has not been
instantiated, then we need to add it to 'bad_cands' even if no argument
conversion is missing.
PR c++/106760
gcc/cp/ChangeLog:
* call.cc (add_candidates): Relax test for adding a candidate
to 'bad_cands' to also accept an uninstantiated template candidate
that has no missing conversions.
gcc/testsuite/ChangeLog:
* g++.dg/ext/conv3.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 50073ffae0a9b8feb9b36fdafdebd9885f6d7dc8)
Add missing "cannot_copy" attribute to instructions that have to
stay in 1-1 correspondence with another insn.
PR target/115526
gcc/ChangeLog:
* config/alpha/alpha.md (movdi_er_high_g): Add cannot_copy attribute.
(movdi_er_tlsgd): Ditto.
(movdi_er_tlsldm): Ditto.
(call_value_osf_<tls>): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/alpha/pr115526.c: New test.
(cherry picked from commit 0841fd4c42ab053be951b7418233f0478282d020)
The following testcase ICEs on x86_64-linux, because we try to
gsi_insert_on_edge_immediate a statement on an edge which already has
statements queued with gsi_insert_on_edge, and the deferral has been
intentional so that we don't need to deal with cfg changes in between.
The following patch uses the delayed insertion as well.
2024-07-17 Jakub Jelinek <jakub@redhat.com>
PR middle-end/115887
* gimple-lower-bitint.cc (gimple_lower_bitint): Use gsi_insert_on_edge
instead of gsi_insert_on_edge_immediate and set edge_insertions to
true.
* gcc.dg/bitint-108.c: New test.
(cherry picked from commit 5104fe4c7808a66ed3041a8da8e4720585cc8a1f)
The builtin-clear-padding-6.c testcase fails as clear_padding_type
doesn't correctly recompute the buf->size and buf->off members after
expanding clearing of an array using a runtime loop.
buf->size should be in that case the offset after which it should continue
with next members or padding before them modulo UNITS_PER_WORD and
buf->off that offset minus buf->size. That is what the code was doing,
but with off being the start of the loop cleared array, not its end.
So, the last hunk in gimple-fold.cc fixes that.
When adding the testcase, I've noticed that the
c-c++-common/torture/builtin-clear-padding-* tests, although clearly
written as runtime tests to test the builtins at runtime, didn't have
{ dg-do run } directive and were just compile tests because of that.
When adding that to the tests, builtin-clear-padding-1.c was already
failing without that clear_padding_type hunk too, but
builtin-clear-padding-5.c was still failing even after the change.
That is due to a bug in clear_padding_flush which the patch fixes as
well - when clear_padding_flush is called with full=true (that happens
at the end of the whole __builtin_clear_padding or on those array
padding clears done by a runtime loop), it wants to flush all the pending
padding clearings rather than just some. If it is at the end of the whole
object, it decreases wordsize when needed to make sure the code never writes
including RMW cycles to something outside of the object:
if ((unsigned HOST_WIDE_INT) (buf->off + i + wordsize)
> (unsigned HOST_WIDE_INT) buf->sz)
{
gcc_assert (wordsize > 1);
wordsize /= 2;
i -= wordsize;
continue;
}
but if it is full==true flush in the middle, this doesn't happen, but we
still process just the buffer bytes before the current end. If that end
is not on a wordsize boundary, e.g. on the builtin-clear-padding-5.c test
the last chunk is 2 bytes, '\0', '\xff', i is 16 and end is 18,
nonzero_last might be equal to the end - i, i.e. 2 here, but still all_ones
might be true, so in some spots we just didn't emit any clearing in that
last chunk.
2024-07-17 Jakub Jelinek <jakub@redhat.com>
PR middle-end/115527
* gimple-fold.cc (clear_padding_flush): Introduce endsize
variable and use it instead of wordsize when comparing it against
nonzero_last.
(clear_padding_type): Increment off by sz.
* c-c++-common/torture/builtin-clear-padding-1.c: Add dg-do run
directive.
* c-c++-common/torture/builtin-clear-padding-2.c: Likewise.
* c-c++-common/torture/builtin-clear-padding-3.c: Likewise.
* c-c++-common/torture/builtin-clear-padding-4.c: Likewise.
* c-c++-common/torture/builtin-clear-padding-5.c: Likewise.
* c-c++-common/torture/builtin-clear-padding-6.c: New test.
(cherry picked from commit 8b5919bae11754f4b65a17e63663d3143f9615ac)
C++26 is making in P2747R2 paper placement new constexpr.
While working on a patch for that, I've noticed we ICE starting with
GCC 14 on the following testcase.
The problem is that e.g. for the void * to sometype * casts checks,
we really assume the casts have their operand constant evaluated
as prvalue, but on the testcase the cast itself is evaluated with
vc_discard and that means op can end up e.g. a VAR_DECL which the
later code doesn't like and asserts on.
If the result type is void, we don't really need the cast operand
for anything, so can use vc_discard for the recursive call,
VIEW_CONVERT_EXPR can appear on the lhs, so we need to honor the
lval but otherwise the patch uses vc_prvalue.
I'd like to get this patch in before the rest of P2747R2 implementation,
so that it can be backported to 14.2 later on.
2024-07-02 Jakub Jelinek <jakub@redhat.com>
Jason Merrill <jason@redhat.com>
PR c++/115754
* constexpr.cc (cxx_eval_constant_expression) <case CONVERT_EXPR>:
For conversions to void, pass vc_discard to the recursive call
and otherwise for tcode other than VIEW_CONVERT_EXPR pass vc_prvalue.
* g++.dg/cpp26/pr115754.C: New test.
(cherry picked from commit 1250540a98e0a1dfa4d7834672d88d8543ea70b1)
Currently we discard the cond-op mask when the loop is fully masked
which causes wrong code in
gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c
when compiled with
-O3 -march=cascadelake --param vect-partial-vector-usage=2.
This patch ANDs both masks.
gcc/ChangeLog:
PR tree-optimization/115382
* tree-vect-loop.cc (vectorize_fold_left_reduction): Use
prepare_vec_mask.
* tree-vect-stmts.cc (check_load_store_for_partial_vectors):
Remove static of prepare_vec_mask.
* tree-vectorizer.h (prepare_vec_mask): Export.
(cherry picked from commit 2b438a0d2aa80f051a09b245a58f643540d4004b)
The following adjusts mask recording which didn't take into account
that we can merge call arguments from two vectors like
_50 = {vect_d_1.253_41, vect_d_1.254_43};
_51 = VIEW_CONVERT_EXPR<unsigned char>(mask__19.257_49);
_52 = (unsigned int) _51;
_53 = _Z3bazd.simdclone.7 (_50, _52);
_54 = BIT_FIELD_REF <_53, 256, 0>;
_55 = BIT_FIELD_REF <_53, 256, 256>;
The testcase g++.dg/vect/pr68762-2.cc exercises this on x86_64 with
partial vector usage enabled and AVX512 support.
PR tree-optimization/115868
* tree-vect-stmts.cc (vectorizable_simd_clone_call): Correctly
compute the number of mask copies required for vect_record_loop_mask.
(cherry picked from commit abf3964711f05b6858d9775c3595ec2b45483e14)
When importing modules, when a binding vector for a name runs out of
slots it gets reallocated with a larger size, and existing bindings are
copied across. However, the flags to indicate whether deduping needs to
occur did not: this causes ICEs, as it allows a duplicate binding to be
added which then violates assumptions later on.
PR c++/99242
gcc/cp/ChangeLog:
* name-lookup.cc (append_imported_binding_slot): Propagate dups
flags.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr99242_a.H: New test.
* g++.dg/modules/pr99242_b.H: New test.
* g++.dg/modules/pr99242_c.H: New test.
* g++.dg/modules/pr99242_d.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
(cherry picked from commit 1aa0f1627857c3e2d90982bdb07ca78ca10b26f3)
When emitting the compensation to the vectorized main loop for
a vector reduction value to be re-used in the vectorized epilogue
we fail to place it in the correct block when the main loop is
known to be entered (no loop_vinfo->main_loop_edge) but the
epilogue is not (a loop_vinfo->skip_this_loop_edge). The code
currently disregards this situation.
With the recent znver4 cost fix I couldn't trigger this situation
with the testcase but I adjusted it so it could eventually trigger
on other targets.
PR tree-optimization/115841
* tree-vect-loop.cc (vect_transform_cycle_phi): Correctly
place the partial vector reduction for the accumulator
re-use when the main loop cannot be skipped but the
epilogue can.
* gcc.dg/vect/pr115841.c: New testcase.
(cherry picked from commit 016c947b02e79a5c0c0c2d4ad5cb71aa04db3efd)
When AVX512 uses a fully masked loop and peeling we fail to create the
correct initial loop mask when the mask is composed of multiple
components in some cases. The following fixes this by properly applying
the bias for the component to the shift amount.
PR tree-optimization/115843
* tree-vect-loop-manip.cc
(vect_set_loop_condition_partial_vectors_avx512): Properly
bias the shift of the initial mask for alignment peeling.
* gcc.dg/vect/pr115843.c: New testcase.
(cherry picked from commit a177be05f6952c3f7e62186d2e138d96c475b81a)
