As the test case requires +-Inf and NaN to work and -ffast-math is added
by default for arm-none-eabi, re-enable non-finite math.
gcc/testsuite/ChangeLog:
PR testsuite/115826
* gcc.dg/vect/tsvc/vect-tsvc-s1281.c: Use -fno-finite-math-only.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
(cherry picked from commit 7793f5b4194253acaac0b53d8a1c95d9b5c8f4bb)
This avoids some warnings when the preprocessor conditions are not met.
libstdc++-v3/ChangeLog:
* src/c++23/print.cc (__open_terminal): Use [[maybe_unused]] on
parameter.
(cherry picked from commit b40156d69153364315e071dc968227ce1c3bd2a8)
avrlibc has an incomplete unistd.h that doesn't have isatty.
So building libstdc++ fails when compiling c++23/print.cc.
As a workaround I added a check for AVR.
libstdc++-v3/ChangeLog:
PR libstdc++/115482
* src/c++23/print.cc (__open_terminal) [__AVR__]: Do not use
isatty.
(cherry picked from commit 8439405e38c56b774cf3c65bdafae5f9e11d470a)
The folding into REALPART_EXPR is correct, used only when the mem_offset
is zero, but for IMAGPART_EXPR it didn't check the exact offset value (just
that it is not 0).
The following patch fixes that by using IMAGPART_EXPR only if the offset
is right and using BITFIELD_REF or whatever else otherwise.
2024-07-23 Jakub Jelinek <jakub@redhat.com>
Andrew Pinski <quic_apinski@quicinc.com>
PR tree-optimization/116034
* tree-ssa.cc (maybe_rewrite_mem_ref_base): Only use IMAGPART_EXPR
if MEM_REF offset is equal to element type size.
* gcc.dg/pr116034.c: New test.
(cherry picked from commit b9cefd67a2a464a3c9413e6b3f28e7dc7a9ef162)
For prefetchi instructions, RIP-relative address is explicitly mentioned
for operand and assembler obeys that rule strictly. This makes
instruction like:
prefetchit0 bar
got illegal for assembler, which should be a broad usage for prefetchi.
Change to %a to explicitly add (%rip) after function label to make it
legal in assembler so that it could pass to linker to get the real address.
gcc/ChangeLog:
* config/i386/i386.md (prefetchi): Change to %a.
gcc/testsuite/ChangeLog:
* gcc.target/i386/prefetchi-1.c: Check (%rip).
The dg-do directive appears after dg-require-effective-target in
g++.target/powerpc/pr106069.C. That doesn't work the way that was
presumably intended. Both of these directives set dg-do-what, but
dg-do does so fully and unconditionally, overriding any decisions
recorded there by earlier directives. Reorder the directives more
canonically, so that both take effect.
for gcc/testsuite/ChangeLog
PR target/106069
* g++.target/powerpc/pr106069.C: Reorder dg directives.
(cherry picked from commit ad65caa332bc7600caff6b9b5b29175b40d91e67)
When passing *this to the promise type ctor (or to its operator new)
(as per [dcl.fct.def.coroutine]/4), we add an explicit cast to lvalue
reference. But this is unnecessary since *this is already always an
lvalue. And doing so means we need to call convert_from_reference
afterward to lower the reference expression to an implicit dereference,
which we're currently neglecting to do and which causes overload
resolution to get confused when computing argument conversions.
So this patch removes this unneeded reference cast when passing *this
to the promise ctor, and removes both the cast and implicit deref when
passing *this to operator new, for consistency. While we're here, use
cp_build_fold_indirect_ref instead of directly building INDIRECT_REF.
PR c++/104981
PR c++/115550
gcc/cp/ChangeLog:
* coroutines.cc (morph_fn_to_coro): Remove unneeded calls
to convert_to_reference and convert_from_reference when
passing *this. Use cp_build_fold_indirect_ref instead
of directly building INDIRECT_REF.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/pr104981-preview-this.C: New test.
* g++.dg/coroutines/pr115550-preview-this.C: New test.
Reviewed-by: Iain Sandoe <iain@sandoe.co.uk>
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 7c5a9bf1d206fe20cb050200d4a30f11c76b1b19)
The code path for rejecting an object-less call to a non-static member
function should also consider xobj member functions (so that we correctly
reject the below calls with a "cannot call member function without object"
diagnostic).
PR c++/115783
gcc/cp/ChangeLog:
* call.cc (build_new_method_call): Generalize METHOD_TYPE
check to DECL_OBJECT_MEMBER_FUNCTION_P.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/explicit-obj-diagnostics11.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 2ee70c9f83a1033f2897a35bff9e9ffdd03cc651)
Hi,
this patch fixes wrong code in case store-merging introduces load of function
parameter that was previously write-only (which happens for bitfields).
Without this, the whole store-merged area is consdered to be killed.
PR ipa/111613
gcc/ChangeLog:
* ipa-modref.cc (analyze_parms): Do not preserve EAF_NO_DIRECT_READ and
EAF_NO_INDIRECT_READ from past flags.
gcc/testsuite/ChangeLog:
* gcc.c-torture/pr111613.c: New test.
(cherry picked from commit 14074773350ffed7efdebbc553adf0f23b572e87)
We currently silently ignore the -mrop-protect option for old CPUs we don't
support with the ROP hash insns, but we throw an error for unsupported ABIs.
This patch treats unsupported CPUs and ABIs similarly by throwing an error
both both. This matches clang behavior and allows us to simplify our tests
in the code that generates our prologue and epilogue code.
2024-06-26 Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/114759
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Disallow
CPUs and ABIs that do no support the ROP protection insns.
* config/rs6000/rs6000-logue.cc (rs6000_stack_info): Remove now
unneeded tests.
(rs6000_emit_prologue): Likewise.
Remove unneeded gcc_assert.
(rs6000_emit_epilogue): Likewise.
* config/rs6000/rs6000.md: Likewise.
gcc/testsuite/
PR target/114759
* gcc.target/powerpc/pr114759-3.c: New test.
(cherry picked from commit 6f2bab9b5d1ce1914c748b7dcd8638dafaa98df7)
We currently only emit the ROP-protect hash* insns for Power10, where the
insns were added to the architecture. We want to emit them for earlier
cpus (where they operate as NOPs), so that if those older binaries are
ever executed on a Power10, then they'll be protected from ROP attacks.
Binutils accepts hashst and hashchk back to Power8, so change GCC to emit
them for Power8 and later. This matches clang's behavior.
2024-06-19 Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/114759
* config/rs6000/rs6000-logue.cc (rs6000_stack_info): Use TARGET_POWER8.
(rs6000_emit_prologue): Likewise.
* config/rs6000/rs6000.md (hashchk): Likewise.
(hashst): Likewise.
Fix whitespace.
gcc/testsuite/
PR target/114759
* gcc.target/powerpc/pr114759-2.c: New test.
* lib/target-supports.exp (rop_ok): Use
check_effective_target_has_arch_pwr8.
(cherry picked from commit a05c3d23d1e1c8d2971b123804fc7a61a3561adb)
We currently only compute the offset for the ROP hash save location in
the stack frame for Altivec compiles. For non-Altivec compiles when we
emit ROP mitigation instructions, we use a default offset of zero which
corresponds to the backchain save location which will get clobbered on
any call. The fix is to compute the ROP hash save location for all
compiles.
2024-06-14 Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/115389
* config/rs6000/rs6000-logue.cc (rs6000_stack_info): Compute
rop_hash_save_offset for non-Altivec compiles.
gcc/testsuite
PR target/115389
* gcc.target/powerpc/pr115389.c: New test.
(cherry picked from commit c70eea0dba5f223d49c80cfb3e80e87b74330aac)
The ELFv2 stack frame layout comment in rs6000-logue.cc shows the ROP
hash save slot in the wrong location. Update the comment to show the
correct ROP hash save location in the frame.
2024-06-07 Peter Bergner <bergner@linux.ibm.com>
gcc/
* config/rs6000/rs6000-logue.cc (rs6000_stack_info): Update comment.
(cherry picked from commit e91cf26a954a5c1bf431e36f3a1e69f94e9fa4fe)
modref_eaf_analysis::analyze_ssa_name misinterprets EAF flags. If dereferenced
parameter is passed (to map_iterator in the testcase) it can be returned
indirectly which in turn makes it to escape into the next function call.
PR ipa/115033
gcc/ChangeLog:
* ipa-modref.cc (modref_eaf_analysis::analyze_ssa_name): Fix checking of
EAF flags when analysing values dereferenced as function parameters.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/pr115033.c: New test.
(cherry picked from commit cf8ffc58aad3127031c229a75cc4b99c8ace25e0)
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)
