aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-02-03libstdc++: Implement ranges::iota from P2440R1Patrick Palka2-0/+77
libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (out_value_result): Define. (iota_result): Define. (__iota_fn, iota): Define. * testsuite/25_algorithms/iota/1.cc: New test.
2023-02-03libstdc++: Implement ranges::contains/contains_subrange from P2302R4Patrick Palka3-0/+124
libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__contains_fn, contains): Define. (__contains_subrange_fn, contains_subrange): Define. * testsuite/25_algorithms/contains/1.cc: New test. * testsuite/25_algorithms/contains_subrange/1.cc: New test.
2023-02-03arm: [MVE] Add missing length=8 attributeChristophe Lyon1-5/+9
I have noticed that the "length" "8" attribute is missing in a few patterns in mve.md. gcc/ * config/arm/mve.md (mve_vabavq_p_<supf><mode>): Add length attribute. (mve_vqshluq_m_n_s<mode>): Likewise. (mve_vshlq_m_<supf><mode>): Likewise. (mve_vsriq_m_n_<supf><mode>): Likewise. (mve_vsubq_m_<supf><mode>): Likewise.
2023-02-03arm: Fix warning in libgcc/config/arm/pr-support.cChristophe Lyon1-0/+6
I have noticed some warnings when building GCC for arm-eabi: pr-support.c:110:7: warning: variable ‘set_pac_sp’ set but not used [-Wunused-but-set-variable] pr-support.c:109:7: warning: variable ‘set_pac’ set but not used [-Wunused-but-set-variable] This small patch avoids them by defining these two variables undef TARGET_HAVE_PACBTI, like the code which actually uses them. libgcc/ * config/arm/pr-support.c (__gnu_unwind_execute): Use TARGET_HAVE_PACBTI to define set_pac and set_pac_sp.
2023-02-03c++: unexpected ADDR_EXPR after overload set pruning [PR107461]Patrick Palka2-5/+36
Here the ahead-of-time overload set pruning in finish_call_expr is unintentionally returning a CALL_EXPR whose (pruned) callee is wrapped in an ADDR_EXPR, despite the original callee not being wrapped in an ADDR_EXPR. This ends up causing a bogus declaration mismatch error in the below testcase because the call to min in #1 gets expressed as a CALL_EXPR of ADDR_EXPR of FUNCTION_DECL, whereas the level-lowered call to min in #2 gets expressed instead as a CALL_EXPR of FUNCTION_DECL. This patch fixes this by stripping the spurious ADDR_EXPR appropriately. Thus the first call to min now also gets expressed as a CALL_EXPR of FUNCTION_DECL, matching the behavior before r12-6075-g2decd2cabe5a4f. PR c++/107461 gcc/cp/ChangeLog: * semantics.cc (finish_call_expr): Strip ADDR_EXPR from the selected callee during overload set pruning. gcc/testsuite/ChangeLog: * g++.dg/template/call9.C: New test.
2023-02-03c++: ICE on unviable/ambiguous constrained dtors [PR96745]Patrick Palka2-3/+37
Here we're crashing from check_bases_and_members due to CLASSTYPE_DESTRUCTOR being an OVERLOAD which, due to the pruning performed by add_method, should only happen if there is no viable destructor or the destructor is ambiguous because of unsatisfied or ambiguous constraints. This patch fixes this by making check_bases_and_members naturally handle CLASSTYPE_DESTRUCTOR being an OVERLOAD. It's then convenient to prune the OVERLOAD after effectively diagnosing the overload resolution failure in check_methods. PR c++/96745 gcc/cp/ChangeLog: * class.cc (check_methods): Diagnose an unviable OVERLOAD set for CLASSTYPE_DESTRUCTOR differently from an ambiguous one. Then prune the OVERLOAD to a single function. (check_bases_and_members): Handle CLASSTYPE_DESTRUCTOR being an OVERLOAD when calling deduce_noexcept_on_destructor. Document why it has to be called before check_methods. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-dtor1.C: New test.
2023-02-03c++: excessive satisfaction in check_methods [PR108579]Patrick Palka2-8/+22
In check_methods we're unnecessarily checking satisfaction for all constructors and assignment operators, even those that don't look like copy/move special members. In the testcase below this manifests as an unstable satisfaction error because the satisfaction result is first determined to be false during check_methods (since A<int> is incomplete at this point) and later true after completion of A<int>. This patch fixes this simply by swapping the order of the constraint_satisfied_p and copy/move_fn_p tests. PR c++/108579 gcc/cp/ChangeLog: * class.cc (check_methods): Swap order of constraints_satisfied_p and copy/move_fn_p tests. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-pr108579.C: New test.
2023-02-03ipa: Avoid invalid gimple when IPA-CP and IPA-SRA disagree on types (108384)Martin Jambor3-19/+76
When the compiled program contains type mismatches between callers and callees when it comes to a parameter, IPA-CP can try to propagate one constant from callers while IPA-SRA may try to split a parameter expecting a value of a different size on the same offset. This then currently leads to creation of a VIEW_CONVERT_EXPR with mismatching type sizes of LHS and RHS which is correctly flagged by the GIMPLE verifier as invalid. It seems that the best course of action is to try and avoid the situation altogether and so this patch adds a check to IPA-SRA that peeks into the result of IPA-CP and when it sees a value on the same offset but with a mismatching size, it just decides to leave that particular parameter be. gcc/ChangeLog: 2023-02-02 Martin Jambor <mjambor@suse.cz> PR ipa/108384 * ipa-sra.cc (push_param_adjustments_for_index): Remove a size check when comparing to an IPA-CP value. (dump_list_of_param_indices): New function. (adjust_parameter_descriptions): Check for mismatching IPA-CP values. Dump removed candidates using dump_list_of_param_indices. * ipa-param-manipulation.cc (ipa_param_body_adjustments::modify_expression): Add assert checking sizes of a VIEW_CONVERT_EXPR will match. (ipa_param_body_adjustments::modify_assignment): Likewise. gcc/testsuite/ChangeLog: 2023-02-02 Martin Jambor <mjambor@suse.cz> PR ipa/108384 * gcc.dg/ipa/pr108384.c: New test.
2023-02-03libgomp: Fix reverse offload issuesTobias Burnus2-4/+36
If there is nothing to map, skip the mapping and avoid attempting to copy 0 bytes from addrs, sizes and kinds. Additionally, it could happen that a non-allocated address was deallocated, such as a pointer set, leading to a free for the actual data. libgomp/ * target.c (gomp_target_rev): Handle mapnum == 0 and avoid freeing not allocated memory. * testsuite/libgomp.fortran/reverse-offload-6.f90: New test.
2023-02-03libgomp: enable reverse offload for AMDGCNTobias Burnus2-6/+10
libgomp/ChangeLog: * libgomp.texi (5.0 Impl. Status, gcn specifics): Update for reverse offload. * plugin/plugin-gcn.c (GOMP_OFFLOAD_get_num_devices): Accept reverse-offload requirement.
2023-02-03RISC-V: Remove unnecessary register class.Monk Chiang2-14/+2
Avoid VL_REGS, VTYPE_REGS join register allocation. gcc/ChangeLog: * config/riscv/riscv.h: Remove VL_REGS, VTYPE_REGS class. * config/riscv/riscv.cc: Ditto.
2023-02-03RISC-V: Fix constraint bug for binary operationJu-Zhe Zhong4-69/+75
Current constraint configuration will generate: vadd.vv v0,v24,v25,v0.t vsll.vx v0,v24,a5,v0.t They are incorrect according to RVV ISA. This patch fix this obvious issue. gcc/ChangeLog: * config/riscv/vector-iterators.md (sll.vi): Fix constraint bug. (sll.vv): Ditto. (%3,%4): Ditto. (%3,%v4): Ditto. * config/riscv/vector.md: Ditto. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/binop_vv_constraint-1.c: * gcc.target/riscv/rvv/base/shift_vx_constraint-1.c:
2023-02-03RISC-V: Add vsll.vx C++ API testsJu-Zhe Zhong15-0/+5238
gcc/testsuite/ChangeLog: * g++.target/riscv/rvv/base/vsll_vx-1.C: New test. * g++.target/riscv/rvv/base/vsll_vx-2.C: New test. * g++.target/riscv/rvv/base/vsll_vx-3.C: New test. * g++.target/riscv/rvv/base/vsll_vx_mu-1.C: New test. * g++.target/riscv/rvv/base/vsll_vx_mu-2.C: New test. * g++.target/riscv/rvv/base/vsll_vx_mu-3.C: New test. * g++.target/riscv/rvv/base/vsll_vx_tu-1.C: New test. * g++.target/riscv/rvv/base/vsll_vx_tu-2.C: New test. * g++.target/riscv/rvv/base/vsll_vx_tu-3.C: New test. * g++.target/riscv/rvv/base/vsll_vx_tum-1.C: New test. * g++.target/riscv/rvv/base/vsll_vx_tum-2.C: New test. * g++.target/riscv/rvv/base/vsll_vx_tum-3.C: New test. * g++.target/riscv/rvv/base/vsll_vx_tumu-1.C: New test. * g++.target/riscv/rvv/base/vsll_vx_tumu-2.C: New test. * g++.target/riscv/rvv/base/vsll_vx_tumu-3.C: New test.
2023-02-03RISC-V: Add vsra.vx C++ API testsJu-Zhe Zhong15-0/+2862
gcc/testsuite/ChangeLog: * g++.target/riscv/rvv/base/vsra_vx-1.C: New test. * g++.target/riscv/rvv/base/vsra_vx-2.C: New test. * g++.target/riscv/rvv/base/vsra_vx-3.C: New test. * g++.target/riscv/rvv/base/vsra_vx_mu-1.C: New test. * g++.target/riscv/rvv/base/vsra_vx_mu-2.C: New test. * g++.target/riscv/rvv/base/vsra_vx_mu-3.C: New test. * g++.target/riscv/rvv/base/vsra_vx_tu-1.C: New test. * g++.target/riscv/rvv/base/vsra_vx_tu-2.C: New test. * g++.target/riscv/rvv/base/vsra_vx_tu-3.C: New test. * g++.target/riscv/rvv/base/vsra_vx_tum-1.C: New test. * g++.target/riscv/rvv/base/vsra_vx_tum-2.C: New test. * g++.target/riscv/rvv/base/vsra_vx_tum-3.C: New test. * g++.target/riscv/rvv/base/vsra_vx_tumu-1.C: New test. * g++.target/riscv/rvv/base/vsra_vx_tumu-2.C: New test. * g++.target/riscv/rvv/base/vsra_vx_tumu-3.C: New test.
2023-02-03RISC-V: Add vsrl.vx C++ API testsJu-Zhe Zhong15-0/+2862
gcc/testsuite/ChangeLog: * g++.target/riscv/rvv/base/vsrl_vx-1.C: New test. * g++.target/riscv/rvv/base/vsrl_vx-2.C: New test. * g++.target/riscv/rvv/base/vsrl_vx-3.C: New test. * g++.target/riscv/rvv/base/vsrl_vx_mu-1.C: New test. * g++.target/riscv/rvv/base/vsrl_vx_mu-2.C: New test. * g++.target/riscv/rvv/base/vsrl_vx_mu-3.C: New test. * g++.target/riscv/rvv/base/vsrl_vx_tu-1.C: New test. * g++.target/riscv/rvv/base/vsrl_vx_tu-2.C: New test. * g++.target/riscv/rvv/base/vsrl_vx_tu-3.C: New test. * g++.target/riscv/rvv/base/vsrl_vx_tum-1.C: New test. * g++.target/riscv/rvv/base/vsrl_vx_tum-2.C: New test. * g++.target/riscv/rvv/base/vsrl_vx_tum-3.C: New test. * g++.target/riscv/rvv/base/vsrl_vx_tumu-1.C: New test. * g++.target/riscv/rvv/base/vsrl_vx_tumu-2.C: New test. * g++.target/riscv/rvv/base/vsrl_vx_tumu-3.C: New test.
2023-02-03RISC-V: Add shift constraint testsJu-Zhe Zhong1-0/+133
gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/shift_vx_constraint-1.c: New test.
2023-02-03RISC-V: Add vsll.vx C++ API testsJu-Zhe Zhong18-0/+5256
gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/vsll_vx-1.c: New test. * gcc.target/riscv/rvv/base/vsll_vx-2.c: New test. * gcc.target/riscv/rvv/base/vsll_vx-3.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_m-1.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_m-2.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_m-3.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_mu-1.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_mu-2.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_mu-3.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_tu-1.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_tu-2.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_tu-3.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_tum-1.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_tum-2.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_tum-3.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_tumu-1.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_tumu-2.c: New test. * gcc.target/riscv/rvv/base/vsll_vx_tumu-3.c: New test.
2023-02-03RISC-V: Add vsra.vx C API testsJu-Zhe Zhong18-0/+2880
gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/vsra_vx-1.c: New test. * gcc.target/riscv/rvv/base/vsra_vx-2.c: New test. * gcc.target/riscv/rvv/base/vsra_vx-3.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_m-1.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_m-2.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_m-3.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_mu-1.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_mu-2.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_mu-3.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_tu-1.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_tu-2.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_tu-3.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_tum-1.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_tum-2.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_tum-3.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_tumu-1.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_tumu-2.c: New test. * gcc.target/riscv/rvv/base/vsra_vx_tumu-3.c: New test.
2023-02-03RISC-V: Add vsrl.vx C API testsJu-Zhe Zhong18-0/+2880
gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/vsrl_vx-1.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx-2.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx-3.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_m-1.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_m-2.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_m-3.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_mu-1.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_mu-2.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_mu-3.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_tu-1.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_tu-2.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_tu-3.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_tum-1.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_tum-2.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_tum-3.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_tumu-1.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_tumu-2.c: New test. * gcc.target/riscv/rvv/base/vsrl_vx_tumu-3.c: New test.
2023-02-03RISC-V: Add RVV shift.vx C/C++ API supportJu-Zhe Zhong5-1/+59
gcc/ChangeLog: * config/riscv/predicates.md (pmode_reg_or_uimm5_operand): New predicate. * config/riscv/riscv-vector-builtins-bases.cc: New class. * config/riscv/riscv-vector-builtins-functions.def (vsll): Ditto. (vsra): Ditto. (vsrl): Ditto. * config/riscv/riscv-vector-builtins.cc: Ditto. * config/riscv/vector.md (@pred_<optab><mode>_scalar): New pattern.
2023-02-03Daily bump.GCC Administrator8-1/+430
2023-02-02c: Update nullptr_t comparison checksJoseph Myers4-18/+23
WG14 has agreed to allow equality comparisons between pointers and nullptr_t values that are not null pointer constants (this was previously an exceptional case where such nullptr_t values were handled differently from null pointer constants; other places in the standard allowed nullptr_t values, whether or not those values are null pointer constants, in the same contexts as null pointer constants); see the wording at the end of N3077. Update GCC's implementation to match this change. There are also changes to allow null pointer constants of integer or pointer type to be converted to nullptr_t (by assignment, cast or conversion as if by assignment), which I'll deal with separately. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-typeck.cc (build_binary_op): Allow comparisons between pointers and nullptr_t values that are not null pointer constants. gcc/testsuite/ * gcc.dg/c2x-constexpr-3.c: Do not expect comparison of nullptr_t and pointer to be disallowed. * gcc.dg/c2x-nullptr-1.c: Test comparisons of nullptr_t and pointers are allowed. * gcc.dg/c2x-nullptr-3.c: Do not test that comparisons of nullptr_t and pointers are disallowed.
2023-02-02libstdc++: Tweak link to ABIcheck projectGerald Pfeifer2-2/+2
libstdc++-v3/ChangeLog: * doc/xml/manual/abi.xml: Tweak link to ABIcheck project. * doc/html/manual/abi.html: Regenerate.
2023-02-02c: Update checks on constexpr floating-point initializersJoseph Myers7-52/+98
WG14 has agreed some changes (detailed at the end of N3082) to the rules on constexpr initializers for floating types. Update GCC's implementation to match: binary initializers are now allowed for decimal types, and real initializers for complex types, but signaling NaN initializers can't be used for a different type with the same mode. There are also changes to the constexpr rules for pointer types (allowing null pointer address constants that aren't null pointer constants), which I'll deal with separately. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-typeck.cc: Include "realmpfr.h". (constexpr_init_fits_real_type): Do not allow signaling NaN conversions to different types with the same mode. Handle conversions from binary to decimal types. (check_constexpr_init): Do not disallow real initializers for complex types. Do not disallow binary initializers for decimal floating types. gcc/testsuite/ * gcc.dg/c2x-constexpr-1.c: Test constexpr initializers of complex types with real initializers are allowed. * gcc.dg/c2x-constexpr-3.c: Do not test for constexpr initializers of complex types with real initializers being disallowed. * gcc.dg/c2x-constexpr-8.c: Add tests of signaling NaN complex initializers. * gcc.dg/c2x-constexpr-9.c: Add more tests. * gcc.dg/dfp/c2x-constexpr-dfp-1.c: Add tests of binary floating initializers for decimal types. * gcc.dg/dfp/c2x-constexpr-dfp-2.c: Change tests of binary initializers for decimal types. Add more tests of decimal initializers for binary types.
2023-02-02libstdc++: Use ENOSYS for unsupported filesystem ops on AVRJonathan Wakely1-1/+6
Because avr-libc <errno.h> defines most error numbers with duplicate values it's not sufficient to check #ifdef ENOTSUP when deciding which std::errc constant to use for the filesystem library's __unsupported() helper. Add a special case for AVR to always use the ENOSYS value. libstdc++-v3/ChangeLog: * src/filesystem/ops-common.h [AVR] (__unsupported): Always use errc::function_not_supported instead of errc::not_supported.
2023-02-02libstdc++: Define std::basic_stringbuf::view() for old std::string ABIJonathan Wakely9-15/+25
Unlike the new str()&& members in <sstream>, there is no real difficulty in supporting the new view() members for the old std::string ABI. Enabling it fixes errors in <chrono> where std::ostringstream::view() is used by ostream insertion operators for calendar types. We just need to use [[gnu::always_inline]] on the view() members for the old ABI, because the library doesn't contain instantiations of them for the old ABI. Making them always inline avoids needing to add those instantiations and export them. libstdc++-v3/ChangeLog: * include/std/sstream (basic_stringbuf::view): Define for old std::string ABI. (basic_istringstream::view, basic_0stringstream::view) (basic_stringstream::view): Likewise. * testsuite/27_io/basic_istringstream/view/char/1.cc: Remove { dg-require-effective-target cxx11_abi }. * testsuite/27_io/basic_istringstream/view/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_ostringstream/view/char/1.cc: Likewise. * testsuite/27_io/basic_ostringstream/view/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_stringbuf/view/char/1.cc: Likewise. * testsuite/27_io/basic_stringbuf/view/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_stringstream/view/char/1.cc: Likewise. * testsuite/27_io/basic_stringstream/view/wchar_t/1.cc: Likewise.
2023-02-02libstdc++: Fix std::filesystem errors with -fkeep-inline-functions [PR108636]Jonathan Wakely4-8/+30
With -fkeep-inline-functions there are linker errors when including <filesystem>. This happens because there are some filesystem::path constructors defined inline which call non-exported functions defined in the library. That's usually not a problem, because those constructors are only called by code that's also inside the library. But when the header is compiled with -fkeep-inline-functions those inline functions are emitted even though they aren't called. That then creates an undefined reference to the other library internsl. The fix is to just move the private constructors into the library where they are called. That way they are never even seen by users, and so not compiled even if -fkeep-inline-functions is used. On trunk there is a second problem, which is that the new equality operators for comparing directory iterators with default_sentinel use the shared_ptr::operator bool() conversion operator. The shared_ptr specializations used by directory iterators are explicitly instantiated in the library, but the bool conversion operators are not exported. This causes linker errors at -O0 or with -fkeep-inline-functions. That just requires the conversion operators to be exported. libstdc++-v3/ChangeLog: PR libstdc++/108636 * config/abi/pre/gnu.ver (GLIBCXX_3.4.31): Export shared_ptr conversion operators for directory iterator comparisons with std::default_sentinel_t. * include/bits/fs_path.h (path::path(string_view, _Type)) (path::_Cmpt::_Cmpt(string_view, _Type, size_t)): Move inline definitions to ... * src/c++17/fs_path.cc: ... here. * testsuite/27_io/filesystem/path/108636.cc: New test.
2023-02-02libstdc++: Use emplace in std::variant::operator=(T&&) as per LWG 3585Jonathan Wakely2-1/+19
This was approved at the October 2021 plenary. libstdc++-v3/ChangeLog: * include/std/variant (variant::operator=): Implement resolution of LWG 3585. * testsuite/20_util/variant/lwg3585.cc: New test.
2023-02-02driver, toplevel: Avoid emitting the version information twice.Iain Sandoe1-1/+1
For a regular compile job, with -v we emit the GCC version information twice - once from main() and once from process_options(). We do not need to output the second header. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/ChangeLog: * toplev.cc (toplev::main): Only print the version information header from toplevel main().
2023-02-02amdgcn: Add instruction pattern for conditional shift operationsPaul-Antoine Arras9-0/+279
gcc/ChangeLog: * config/gcn/gcn-valu.md (cond_<expander><mode>): Add cond_{ashl|ashr|lshr} gcc/testsuite/ChangeLog: * gcc.target/gcn/cond_shift_3.c: New test. * gcc.target/gcn/cond_shift_3_run.c: New test. * gcc.target/gcn/cond_shift_4.c: New test. * gcc.target/gcn/cond_shift_4_run.c: New test. * gcc.target/gcn/cond_shift_8.c: New test. * gcc.target/gcn/cond_shift_8_run.c: New test. * gcc.target/gcn/cond_shift_9.c: New test. * gcc.target/gcn/cond_shift_9_run.c: New test.
2023-02-02rtl-ssa: Extend m_num_defs to a full unsigned int [PR108086]Richard Sandiford1-5/+9
insn_info tried to save space by storing the number of definitions in a 16-bit bitfield. The justification was: // ... FIRST_PSEUDO_REGISTER + 1 // is the maximum number of accesses to hard registers and memory, and // MAX_RECOG_OPERANDS is the maximum number of pseudos that can be // defined by an instruction, so the number of definitions should fit // easily in 16 bits. But while that reasoning holds (I think) for real instructions, it doesn't hold for artificial instructions. I don't think there's any sensible higher limit we can use, so this patch goes for a full unsigned int. gcc/ PR rtl-optimization/108086 * rtl-ssa/insns.h (insn_info): Make m_num_defs a full unsigned int. Adjust size-related commentary accordingly.
2023-02-02rtl-ssa: Fix splitting of clobber groups [PR108508]Richard Sandiford2-4/+38
Since rtl-ssa isn't a real/native SSA representation, it has to honour the constraints of the underlying rtl representation. Part of this involves maintaining an rpo list of definitions for each rtl register, backed by a splay tree where necessary for quick lookup/insertion. However, clobbers of a register don't act as barriers to other clobbers of a register. E.g. it's possible to move one flag-clobbering instruction across an arbitrary number of other flag-clobbering instructions. In order to allow passes to do that without quadratic complexity, the splay tree groups all consecutive clobbers into groups, with only the group being entered into the splay tree. These groups in turn have an internal splay tree of clobbers where necessary. This means that, if we insert a new definition and use into the middle of a sea of clobbers, we need to split the clobber group into two groups. This was quite a difficult condition to trigger during development, and the PR shows that the code to handle it had (at least) two bugs. First, the process involves searching the clobber tree for the split point. This search can give either the previous clobber (which will belong to the first of the split groups) or the next clobber (which will belong to the second of the split groups). The code for the former case handled the split correctly but the code for the latter case didn't. Second, I'd forgotten to add the second clobber group to the main splay tree. :-( gcc/ PR rtl-optimization/108508 * rtl-ssa/accesses.cc (function_info::split_clobber_group): When the splay tree search gives the first clobber in the second group, make sure that the root of the first clobber group is updated correctly. Enter the new clobber group into the definition splay tree. gcc/testsuite/ PR rtl-optimization/108508 * gcc.target/aarch64/pr108508.c: New test.
2023-02-02testsuite: Add case-values-threshold to pr107876.CRichard Sandiford1-1/+1
This test was failing on aarch64 because aarch64 overrides TARGET_CASE_VALUES_THRESHOLD. The maximum value that allows the test to pass appears to be 6, but the default threshold is 4 or 5 (depending on whether casesi is provided). Going for 4 seemed safest, in case any target-specific features force the maximum passing threshold to be lower on some targets. gcc/testsuite/ * g++.dg/tree-ssa/pr107876.C: Add --param case-values-threshold=4.
2023-02-02analyzer: fix -Wanalyzer-fd-type-mismatch false +ve on "listen" [PR108633]David Malcolm2-2/+85
gcc/analyzer/ChangeLog: PR analyzer/108633 * sm-fd.cc (fd_state_machine::check_for_fd_attrs): Add missing "continue". (fd_state_machine::on_listen): Don't issue phase-mismatch or type-mismatch warnings for the "invalid" state. gcc/testsuite/ChangeLog: PR analyzer/108633 * gcc.dg/analyzer/fd-pr108633.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2023-02-02analyzer: add deref-before-check-qemu-qtest_rsp_args.c test caseDavid Malcolm1-0/+73
gcc/testsuite/ChangeLog: * gcc.dg/analyzer/deref-before-check-qemu-qtest_rsp_args.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2023-02-02RISC-V: Fix bug of TARGET_COMPUTE_MULTILIB implemented in riscv.Jin Ma1-1/+4
MAX_MATCH_SCORE is not assigned anywhere except initialized to 0, causing BEST_MATCH_MULTI_LIB to always be 0 or -1, which will cause the result of TARGET_COMPUTE_MULTILIB hook to fail. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_compute_multilib): Fix finding best match score.
2023-02-02sched-deps, cselib: Fix up some -fcompare-debug issues and regressions ↵Jakub Jelinek3-8/+42
[PR108463] On Sat, Jan 14, 2023 at 08:26:00AM -0300, Alexandre Oliva via Gcc-patches wrote: > The testcase used to get scheduled differently depending on the > presence of debug insns with MEMs. It's not clear to me why those > MEMs affected scheduling, but the cselib pre-canonicalization of the > MEM address is not used at all when analyzing debug insns, so the > memory allocation and lookup are pure waste. Somehow, avoiding that > waste fixes the problem, or makes it go latent. Unfortunately, this patch breaks the following testcase. The code in sched_analyze_2 did 2 things: 1) cselib_lookup_from_insn 2) shallow_copy_rtx + cselib_subst_to_values_from_insn Now, 1) is precondition of 2), we can only subst the VALUEs if we have actually looked the address up, but as can be seen on that testcase, we are relying on at least the 1) to be done because we subst the values later on even on DEBUG_INSNs and actually use those when needed. cselib_subst_to_values_from_insn mostly just replaces stuff in the returned rtx, except for: /* This used to happen for autoincrements, but we deal with them properly now. Remove the if stmt for the next release. */ if (! e) { /* Assign a value that doesn't match any other. */ e = new_cselib_val (next_uid, GET_MODE (x), x); } which is like that since 2011, I hope it is never reachable and we should in stage1 replace that with gcc_assert or just remove (then it will segfault on following return e->val_rtx; ). So, I (as done in the patch below) reinstalled the 1) and not 2) for DEBUG_INSNs. This fixed the new testcase, but broke again the PR106746 testcases. I've spent a day debugging that and found the problem is that as documented in a large comment in cselib.cc above n_useless_values variable definition, we spend quite a few effort on making sure that VALUEs created on DEBUG_INSNs don't affect the cselib decisions for non-DEBUG_INSNs such as pruning of useless values etc., but if a VALUE created that way is then looked up/needed from non-DEBUG_INSNs, we promote it to non-debug. The reason for -fcompare-debug failure is that there is one large DEBUG_INSN with 16 MEMs in it mostly with addresses that so far didn't appear in the IL otherwise. Later on, we see an instruction storing into MEM destination and invalidate that MEM. Unfortunately, there is a bug caused by the introduction of SP_DERIVED_VALUE_P where alias.cc isn't able to disambiguate MEMs with sp + optional offset in address vs. MEMs with address being a VALUE having SP_DERIVED_VALUE_P + constant (or the SP_DERIVED_VALUE_P itself), which ought to be possible when REG_VALUES (REGNO (stack_pointer_rtx)) has SP_DERIVED_VALUE_P + constant location. Not sure if I should try to fix that in stage4 or defer for stage1. Anyway, the cselib_invalidate_mem call because of this invalidates basically all MEMs with the exception of 5 which have MEM_EXPRs that guarantee non-aliasing with the sp based store. Unfortunately, n_useless_values which in my understanding should be always the same between -g and -g0 compilations diverges, has 3 more useless values for -g. Now, these were initially VALUEs created for DEBUG_INSN lookups. As I said, cselib.cc has code to promote such VALUEs (well, their location elements) to non-debug if they are looked up from non-DEBUG_INSNs. The problem is that when looking some completely unrelated MEM from a non-DEBUG_INSN we run into a hash collision and so call cselib_hasher::equal to check if the unrelated MEM is equal to the one from DEBUG_INSN only element. The equal static member function calls rtx_equal_for_cselib_1 and if that returns true, promotes the location to non-DEBUG, otherwise returns false. So far so good. But rtx_equal_for_cselib_1 internally performs various other cselib lookups, all done with the non-DEBUG_INSN cselib_current_insn, so they all promote to non-debug. And that is wrong, because if it was -g0 compilation, such hashtable entry wouldn't be there at all (or would be but wouldn't contain that locs element), so with -g0 we wouldn't call that rtx_equal_for_cselib_1 at all. So, I think we need to pretend that such lookup which only happens with -g and not -g0 actually comes from some DEBUG_INSN (note, the lookups rtx_equal_for_cselib_1 does are always with create = 0). The cselib.cc part of the patch does that. BTW, I'm not really sure how: if (num_mems < param_max_cselib_memory_locations && ! canon_anti_dependence (x, false, mem_rtx, GET_MODE (mem_rtx), mem_addr)) { has_mem = true; num_mems++; p = &(*p)->next; continue; } num_mems cap can actually work correctly for -fcompare-debug, I'd think we would need to differentiate between num_debug_mems and num_mems depending on if setting_insn is non-NULL DEBUG_INSN or not. That was one of my suspicions on this testcase, but the number of MEMs was small enough for the param in either case (especially because of the above mentioned missed non-aliasings). But as implemented, I think if we have tons of non-aliased MEMs from DEBUG_INSN setting_insns, we could unchain lots more non-DEBUG MEMs with -g than with -g0. 2023-02-02 Jakub Jelinek <jakub@redhat.com> PR debug/106746 PR rtl-optimization/108463 PR target/108484 * cselib.cc (cselib_current_insn): Move declaration earlier. (cselib_hasher::equal): For debug only locs, temporarily override cselib_current_insn to their l->setting_insn for the rtx_equal_for_cselib_1 call, so that unsuccessful comparisons don't promote some debug locs. * sched-deps.cc (sched_analyze_2) <case MEM>: For MEMs in DEBUG_INSNs when using cselib call cselib_lookup_from_insn on the address but don't substitute it. * gcc.dg/pr108463.c: New test.
2023-02-02middle-end/108625 - wrong folding due to misinterpreted !Richard Biener2-2/+18
The following fixes a problem with ! handling in genmatch which isn't conservative enough when intermediate simplifications push to the sequence but the final operation appears to just pick an existing (but in this case newly defined in the sequence) operand. The easiest fix is to disallow adding to the sequence when processing !. PR middle-end/108625 * genmatch.cc (expr::gen_transform): Also disallow resimplification from pushing to lseq with force_leaf. (dt_simplify::gen_1): Likewise. * gcc.dg/pr108625.c: New testcase.
2023-02-02amdgcn, libgomp: Manually allocated stacksAndrew Stubbs14-233/+332
Switch from using stacks in the "private segment" to using a memory block allocated on the host side. The primary reason is to permit the reverse offload implementation to access values located on the device stack, but there may also be performance benefits, especially with repeated kernel invocations. This implementation unifies the stacks with the "team arena" optimization feature, and now allows both to have run-time configurable sizes. A new ABI is needed, so all libraries must be rebuilt, and newlib must be version 4.3.0.20230120 or newer. gcc/ChangeLog: * config/gcn/gcn-run.cc: Include libgomp-gcn.h. (struct kernargs): Replace the common content with kernargs_abi. (struct heap): Delete. (main): Read GCN_STACK_SIZE envvar. Allocate space for the device stacks. Write the new kernargs fields. * config/gcn/gcn.cc (gcn_option_override): Remove stack_size_opt. (default_requested_args): Remove PRIVATE_SEGMENT_BUFFER_ARG and PRIVATE_SEGMENT_WAVE_OFFSET_ARG. (gcn_addr_space_convert): Mask the QUEUE_PTR_ARG content. (gcn_expand_prologue): Move the TARGET_PACKED_WORK_ITEMS to the top. Set up the stacks from the values in the kernargs, not private. (gcn_expand_builtin_1): Match the stack configuration in the prologue. (gcn_hsa_declare_function_name): Turn off the private segment. (gcn_conditional_register_usage): Ensure QUEUE_PTR is fixed. * config/gcn/gcn.h (FIXED_REGISTERS): Fix the QUEUE_PTR register. * config/gcn/gcn.opt (mstack-size): Change the description. include/ChangeLog: * gomp-constants.h (GOMP_VERSION_GCN): Bump. libgomp/ChangeLog: * config/gcn/libgomp-gcn.h (DEFAULT_GCN_STACK_SIZE): New define. (DEFAULT_TEAM_ARENA_SIZE): New define. (struct heap): Move to this file. (struct kernargs_abi): Likewise. * config/gcn/team.c (gomp_gcn_enter_kernel): Use team arena size from the kernargs. * libgomp.h: Include libgomp-gcn.h. (TEAM_ARENA_SIZE): Remove. (team_malloc): Update the error message. * plugin/plugin-gcn.c (struct kernargs): Move common content to struct kernargs_abi. (struct agent_info): Rename team arenas to ephemeral memories. (struct team_arena_list): Rename .... (struct ephemeral_memories_list): to this. (struct heap): Delete. (team_arena_size): New variable. (stack_size): New variable. (print_kernel_dispatch): Update debug messages. (init_environment_variables): Read GCN_TEAM_ARENA_SIZE. Read GCN_STACK_SIZE. (get_team_arena): Rename ... (configure_ephemeral_memories): ... to this, and set up stacks. (release_team_arena): Rename ... (release_ephemeral_memories): ... to this. (destroy_team_arenas): Rename ... (destroy_ephemeral_memories): ... to this. (create_kernel_dispatch): Add num_threads parameter. Adjust for kernargs_abi refactor and ephemeral memories. (release_kernel_dispatch): Adjust for ephemeral memories. (run_kernel): Pass thread-count to create_kernel_dispatch. (GOMP_OFFLOAD_init_device): Adjust for ephemeral memories. (GOMP_OFFLOAD_fini_device): Adjust for ephemeral memories. gcc/testsuite/ChangeLog: * gcc.c-torture/execute/pr47237.c: Xfail on amdgcn. * gcc.dg/builtin-apply3.c: Xfail for amdgcn. * gcc.dg/builtin-apply4.c: Xfail for amdgcn. * gcc.dg/torture/stackalign/builtin-apply-3.c: Xfail for amdgcn. * gcc.dg/torture/stackalign/builtin-apply-4.c: Xfail for amdgcn.
2023-02-02libgomp.texi (OpenMP TR11 impl. status): Fix 'strict' itemTobias Burnus1-2/+1
Fix the 'strict' modifier status: it is already listed (as 'Y') for OpenMP 5.1 for num_task and grainsize; only strict on num_threads is new with TR11. libgomp/ * libgomp.texi (OpenMP TR11): Fix item for 'strict' modifier.
2023-02-02arm: Fix MVE predicates synthesis [PR 108443]Andre Vieira14-89/+160
This patch fixes the way we synthesize MVE predicate immediates and fixes some other inconsistencies around predicates. For instance this patch fixes the modes used in the vctp intrinsics, to couple them with predicate modes with the appropriate lane numbers. For this V2QI is added to represent a predicate created by vctp64q. The reason we use V2QI and not for instance a V2BI with 8-bit boolean modes is because we are trying to avoid having two 'INT' modes of the same size. We make sure we use the V2QI mode instead of HI for any instruction working on two lanes of 64-bits consuming a predicate. gcc/ChangeLog: PR target/108443 * config/arm/arm.h (VALID_MVE_PRED_MODE): Add V2QI. * config/arm/arm.cc (thumb2_legitimate_address_p): Use HImode for addressing MVE predicate modes. (mve_bool_vec_to_const): Change to represent correct MVE predicate format. (arm_hard_regno_mode_ok): Use VALID_MVE_PRED_MODE instead of checking modes. (arm_vector_mode_supported_p): Likewise. (arm_mode_to_pred_mode): Add V2QI. * config/arm/arm-builtins.cc (UNOP_PRED_UNONE_QUALIFIERS): New qualifier. (UNOP_PRED_PRED_QUALIFIERS): New qualifier (BINOP_PRED_UNONE_PRED_QUALIFIERS): New qualifier. (v2qi_UP): New macro. (v4bi_UP): New macro. (v8bi_UP): New macro. (v16bi_UP): New macro. (arm_expand_builtin_args): Make it able to expand the new predicate modes. * config/arm/arm-modes.def (V2QI): New mode. * config/arm/arm-simd-builtin-types.def (Pred1x16_t, Pred2x8_t Pred4x4_t): Remove unused predicate builtin types. * config/arm/arm_mve.h (__arm_vctp16q, __arm_vctp32q, __arm_vctp64q, __arm_vctp8q, __arm_vpnot, __arm_vctp8q_m, __arm_vctp64q_m, __arm_vctp32q_m, __arm_vctp16q_m): Use predicate modes. * config/arm/arm_mve_builtins.def (vctp16q, vctp32q, vctp64q, vctp8q, vpnot, vctp8q_m, vctp16q_m, vctp32q_m, vctp64q_m): Likewise. * config/arm/constraints.md (DB): Check for VALID_MVE_PRED_MODE instead of MODE_VECTOR_BOOL. * config/arm/iterators.md (MVE_7, MVE_7_HI): Add V2QI (MVE_VPRED): Likewise. (MVE_vpred): Add V2QI and map upper case predicate modes to lower case. (MVE_vctp): New mode attribute. (mode1): Remove. (VCTPQ): Remove. (VCTPQ_M): Remove. * config/arm/mve.md (mve_vctp<mode1>qhi): Rename this... (mve_vctp<MVE_vctp>q<MVE_vpred>): ... to this. And use new mode attributes. (mve_vpnothi): Rename this... (mve_vpnotv16bi): ... to this. (mve_vctp<mode1>q_mhi): Rename this... (mve_vctp<MVE_vctp>q_m<MVE_vpred>):... to this. (mve_vldrdq_gather_base_z_<supf>v2di, mve_vldrdq_gather_offset_z_<supf>v2di, mve_vldrdq_gather_shifted_offset_z_<supf>v2di, mve_vstrdq_scatter_base_p_<supf>v2di, mve_vstrdq_scatter_offset_p_<supf>v2di, mve_vstrdq_scatter_offset_p_<supf>v2di_insn, mve_vstrdq_scatter_shifted_offset_p_<supf>v2di, mve_vstrdq_scatter_shifted_offset_p_<supf>v2di_insn, mve_vstrdq_scatter_base_wb_p_<supf>v2di, mve_vldrdq_gather_base_wb_z_<supf>v2di, mve_vldrdq_gather_base_nowb_z_<supf>v2di, mve_vldrdq_gather_base_wb_z_<supf>v2di_insn): Use V2QI insead of HI for predicates. * config/arm/unspecs.md (VCTP8Q, VCTP16Q, VCTP32Q, VCTP64Q): Replace these... (VCTP): ... with this. (VCTP8Q_M, VCTP16Q_M, VCTP32Q_M, VCTP64Q_M): Replace these... (VCTP_M): ... with this. * config/arm/vfp.md (*thumb2_movhi_vfp, *thumb2_movhi_fp16): Use VALID_MVE_PRED_MODE instead of checking for MODE_VECTOR_BOOL class. gcc/testsuite/ChangeLog: * gcc.target/arm/mve/pr108443-run.c: New test. * gcc.target/arm/mve/pr108443.c: New test.
2023-02-02arm: Remove unnecessary zero-extending of MVE predicates before use [PR 107674]Andre Vieira4-8/+26
This patch teaches GCC that zero-extending a MVE predicate from 16-bits to 32-bits and then only using 16-bits is a no-op. It does so in two steps: - it lets gcc know that it can access any MVE predicate mode using any other MVE predicate mode without needing to copy it, using the TARGET_MODES_TIEABLE_P hook, - it teaches simplify_subreg to optimize a subreg with a vector outermode, by replacing this outermode with a same-sized integer mode and trying the avalailable optimizations, then if successful it surrounds the result with a subreg casting it back to the original vector outermode. gcc/ChangeLog: PR target/107674 * config/arm/arm.cc (arm_hard_regno_mode_ok): Use new MACRO. (arm_modes_tieable_p): Make MVE predicate modes tieable. * config/arm/arm.h (VALID_MVE_PRED_MODE): New define. * simplify-rtx.cc (simplify_context::simplify_subreg): Teach simplify_subreg to simplify subregs where the outermode is not scalar. gcc/testsuite/ChangeLog: * gcc.target/arm/mve/mve_vpt.c: Change to remove unecessary zero-extend.
2023-02-02arm: Fix sign of MVE predicate mve_pred16_t [PR 107674]Andre Vieira2-8/+35
The ACLE defines mve_pred16_t as an unsigned short. This patch makes sure GCC treats the predicate as an unsigned type, rather than signed. gcc/ChangeLog: PR target/107674 * config/arm/arm-builtins.cc (arm_simd_builtin_type): Rewrite to use new qualifiers parameter and use unsigned short type for MVE predicate. (arm_init_builtin): Call arm_simd_builtin_type with qualifiers parameter. (arm_init_crypto_builtins): Likewise. gcc/testsuite/ChangeLog: PR target/107674 * gcc.target/arm/mve/mve_vpt.c: New test.
2023-02-02Replace IFN_TRAP with BUILT_IN_UNREACHABLE_TRAP [PR107300]Jakub Jelinek12-26/+42
For PR106099 I've added IFN_TRAP as an alternative to __builtin_trap meant for __builtin_unreachable purposes (e.g. with -funreachable-traps or some sanitizers) which doesn't need vops because __builtin_unreachable doesn't need them either. This works in various cases, but unfortunately IPA likes to decide on the redirection to unreachable just by tweaking the cgraph edge to point to a different FUNCTION_DECL. As internal functions don't have a decl, this causes problems like in the following testcase. The following patch fixes it by removing IFN_TRAP again and replacing it with user inaccessible BUILT_IN_UNREACHABLE_TRAP, so that e.g. builtin_decl_unreachable can return it directly and we don't need to tweak it later in wherever we actually replace the call stmt. 2023-02-02 Jakub Jelinek <jakub@redhat.com> PR ipa/107300 * builtins.def (BUILT_IN_UNREACHABLE_TRAP): New builtin. * internal-fn.def (TRAP): Remove. * internal-fn.cc (expand_TRAP): Remove. * tree.cc (build_common_builtin_nodes): Define BUILT_IN_UNREACHABLE_TRAP if not yet defined. (builtin_decl_unreachable): Use BUILT_IN_UNREACHABLE_TRAP instead of BUILT_IN_TRAP. * gimple.cc (gimple_build_builtin_unreachable): Remove emitting internal function for BUILT_IN_TRAP. * asan.cc (maybe_instrument_call): Handle BUILT_IN_UNREACHABLE_TRAP. * cgraph.cc (cgraph_edge::verify_corresponds_to_fndecl): Handle BUILT_IN_UNREACHABLE_TRAP instead of BUILT_IN_TRAP. * ipa-devirt.cc (possible_polymorphic_call_target_p): Handle BUILT_IN_UNREACHABLE_TRAP. * builtins.cc (expand_builtin, is_inexpensive_builtin): Likewise. * tree-cfg.cc (verify_gimple_call, pass_warn_function_return::execute): Likewise. * attribs.cc (decl_attributes): Don't report exclusions on BUILT_IN_UNREACHABLE_TRAP either. * gcc.dg/pr107300.c: New test.
2023-02-02Don't peel nonlinear iv(mult or shift) for epilog when vf is not constant.liuhongt4-49/+55
Normally when vf is not constant, it will be prevented by vectorizable_nonlinear_inductions, but for this case, it failed going into if (STMT_VINFO_RELEVANT_P (stmt_info)) { need_to_vectorize = true; if (STMT_VINFO_DEF_TYPE (stmt_info) == vect_induction_def && ! PURE_SLP_STMT (stmt_info)) ok = vectorizable_induction (loop_vinfo, stmt_info, NULL, NULL, &cost_vec); since the iv is never used outside of the loop, and will be dce later, so vectorizer doesn't bother checking if it's vectorizable. it's true but hit gcc_assert in vect_can_peel_nonlinear_iv_p when vf is not constant. One solution is ignoring the nonlinear iv peeling if it's !STMT_VINFO_RELEVANT_P (stmt_info) just like the upper code, the other solution is returning false earlier in the vect_can_peel_nonlinear_iv_p when vf is not constant, the patch chooses the second incase there's other cases using vect_can_advance_ivs_p which calls vect_can_peel_nonlinear_iv_p. Also remove vect_peel_nonlinear_iv_p from vectorizable_nonlinear_inductions. gcc/ChangeLog: PR tree-optimization/108601 * tree-vectorizer.h (vect_can_peel_nonlinear_iv_p): Removed. * tree-vect-loop.cc (vectorizable_nonlinear_induction): Remove vect_can_peel_nonlinear_iv_p. (vect_can_peel_nonlinear_iv_p): Don't peel nonlinear iv(mult or shift) for epilog when vf is not constant and moved the defination to .. * tree-vect-loop-manip.cc (vect_can_peel_nonlinear_iv_p): .. Here. gcc/testsuite/ChangeLog: * gcc.target/aarch64/pr108601.c: New test.
2023-02-02nested, openmp: Wrap OMP_CLAUSE_*_GIMPLE_SEQ into GIMPLE_BIND for ↵Jakub Jelinek2-16/+34
declare_vars [PR108435] When gimplifying OMP_CLAUSE_{LASTPRIVATE,LINEAR}_STMT, we wrap it always into a GIMPLE_BIND, but when putting statements directly into OMP_CLAUSE_{LASTPRIVATE,LINEAR}_GIMPLE_SEQ, we do it only if needed (there are any temporaries that need to be declared in the sequence). convert_nonlocal_omp_clauses was relying on the GIMPLE_BIND to be there always because it called declare_vars on it. The following patch wraps it into GIMPLE_BIND in tree-nested if we need to declare_vars on it on demand. 2023-02-02 Jakub Jelinek <jakub@redhat.com> PR middle-end/108435 * tree-nested.cc (convert_nonlocal_omp_clauses) <case OMP_CLAUSE_LASTPRIVATE>: If info->new_local_var_chain and *seq is not a GIMPLE_BIND, wrap the sequence into a new GIMPLE_BIND before calling declare_vars. (convert_nonlocal_omp_clauses) <case OMP_CLAUSE_LINEAR>: Merge with the OMP_CLAUSE_LASTPRIVATE handling except for whether seq is initialized to &OMP_CLAUSE_LASTPRIVATE_GIMPLE_SEQ (clause) or &OMP_CLAUSE_LINEAR_GIMPLE_SEQ (clause). * gcc.dg/gomp/pr108435.c: New test.
2023-02-02libstdc++: Switch a www.open-std.org link to httpsGerald Pfeifer2-2/+2
libstdc++-v3/ChangeLog: * doc/xml/manual/using_exceptions.xml: Update a www.open-std.org link to https. * doc/html/manual/using_exceptions.html: Regenerate.
2023-02-02libstdc++: Fix link to online GDB manualGerald Pfeifer2-2/+2
libstdc++-v3/ChangeLog: * doc/xml/manual/debug.xml: Fix link to online GDB manual. * doc/html/manual/debug.html: Regenerate.
2023-02-02Daily bump.GCC Administrator11-1/+495
2023-02-01libstdc++: Fix std::random_device for avrJonathan Wakely1-0/+2
This fixes a build failure that affects avr, but could affect other targets in theory. The _M_fini function should not try to use ::open or ::fopen if _GLIBCXX_USE_DEV_RANDOM is not defined, because no file can ever have been opened. libstdc++-v3/ChangeLog: * src/c++11/random.cc (random_device::_M_fini): Do not try to close the file handle if the target doesn't support the /dev/random and /dev/urandom files.