[Bug c++/56289] Bad location for unused value warning with comma operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56289 Gayathri Gottumukkala changed: What|Removed |Added CC||gayathri.gottumukkala.27@gm ||ail.com --- Comment #5 from Gayathri Gottumukkala --- We cannot cast the two variables in single line using void. Instead of that we have to use void for two variables separately.
[Bug c++/65350] [C++14] operator new[] should not be called if # of initializer elements exceeds # of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65350 Gayathri Gottumukkala changed: What|Removed |Added CC||gayathri.gottumukkala.27@gm ||ail.com --- Comment #4 from Gayathri Gottumukkala --- "cout" statement is executed before the exception is raised, hence two lines are printed as output.
[Bug c++/70352] [C++11] auto cannot be used in the type-id of a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70352 Gayathri Gottumukkala changed: What|Removed |Added CC||gayathri.gottumukkala.27@gm ||ail.com --- Comment #3 from Gayathri Gottumukkala --- Syntax error, by removing braces and by releasing the memory of variable, the code is getting compiled.
[Bug c++/111316] std::vector's operator < does not work with recursive data type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111316 --- Comment #3 from Andrew Pinski --- See https://cplusplus.github.io/CWG/issues/2369.html
[Bug c++/111316] std::vector's operator < does not work with recursive data type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111316 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99599 --- Comment #2 from Andrew Pinski --- Most likely a dup of bug 99599.
[Bug c++/111316] std::vector's operator < does not work with recursive data type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111316 --- Comment #1 from Andrew Pinski --- Yes and GCC is the only compiler which implements the atomic constraint rule for C++20.
[Bug c++/111316] New: std::vector's operator < does not work with recursive data type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111316
Bug ID: 111316
Summary: std::vector's operator < does not work with recursive
data type
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xgao at nvidia dot com
Target Milestone: ---
Created attachment 55847
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55847=edit
minimum repro
The attached minimal repro does not work on g++ on C++20, but it works with g++
on C++17 and clang++ on both C++17 and C++20. See the code for detail:
Error message:
/usr/include/c++/13.2.1/compare:1216:18: error: satisfaction of atomic
constraint ‘requires{{__t < __u} -> decltype(auto) [requires
std::__detail::__boolean_testable<, >];{__u < __t} ->
decltype(auto) [requires std::__detail::__boolean_testable<, >];}
[with _Tp = _Tp; _Up = _Up]’ depends on itself
[Bug libstdc++/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315 --- Comment #1 from Andrew Pinski --- Hmm, is libbacktrace not working with PIE applications ...
[Bug c++/111314] Can not deduct parameter pack as a single type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111314
--- Comment #2 from Andrew Pinski ---
If change DynamicType to a variable length template, then it works; that is:
template class, typename...>
struct DynamicType {};
[Bug libstdc++/111315] New: libstdc++ stacktrace testsuite failures with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315 Bug ID: 111315 Summary: libstdc++ stacktrace testsuite failures with --enable-default-pie Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rimvydas.jas at gmail dot com Target Milestone: --- The GCC configured with --enable-default-pie gives: === libstdc++ tests === Running target unix FAIL: 19_diagnostics/stacktrace/entry.cc execution test FAIL: 19_diagnostics/stacktrace/stacktrace.cc execution test libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc:39: void test_members(): Assertion 'e1.source_line() == (__LINE__ - 5)' failed. libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc:132: void test_assign(): Assertion 's0.at(0).source_line() == (__LINE__ - 4)' failed. In both cases source_line() methods return 0. Also, the -fno-pie option cannot be used when linking these tescases: /usr/bin/ld: /tmp/ccv2BTff.o: relocation R_X86_64_32 against symbol `_ZNSt16stacktrace_entry14_S_err_handlerEPvPKci' can not be used when making a PIE object; recompile with -fPIE
[Bug c++/111314] Can not deduct parameter pack as a single type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111314
--- Comment #1 from Andrew Pinski ---
Reduced testcase:
template
struct Template1 {};
template class, typename>
struct DynamicType {};
template
struct is_dynamic_type
{ static constexpr bool value = false; };
template class Template, typename... Ts>
struct is_dynamic_type>
{ static constexpr bool value = true; };
// This fails:
static_assert(is_dynamic_type>::value, "");
RE: [PATCH] RISC-V: Remove incorrect earliest vsetvl post optimization[PR111313]
Committed, thanks Kito. Pan -Original Message- From: Gcc-patches On Behalf Of Kito Cheng via Gcc-patches Sent: Thursday, September 7, 2023 11:39 AM To: Juzhe-Zhong Cc: GCC Patches ; Kito Cheng Subject: Re: [PATCH] RISC-V: Remove incorrect earliest vsetvl post optimization[PR111313] LGTM Juzhe-Zhong 於 2023年9月7日 週四 11:36 寫道： > This patch removes the incorrect earliest poset vsetvl optimization, > such bug was found in vect-double-reduc-5.c which is runtime(execution > fail) and also in PR111313. > > For VLMAX intrinsics, we always emit a bogus patter which is vlmax_avl > (see vector.md) to > occupy a scalar register which is used by the following RVV instruction > which is VLMAX AVL. > > Then for O2, O3, Ofast, earliest LCM works so well. > However, for O1, the vlmax_avl is not well optimized in the before pass > which confused LCM earliest > so that we will end up with some redundant vsetvli zero,zero instructions > in O1. (Note that O2 O3 Ofast are all good). > > To elide those redundant vsetvli zero,zero, I added > cleanup_earliest_vsetvls to elide those redundant vsetvls. > > Now, after I review the implementation of this post optimizaiton again, I > found it is incorrect and it is hard to > do the post optimizations for vsetvls that earliest LCM failed to > eliminate. > > Besides, such performance issues only happen in O1 or O0, such issues may > not be serious. > So remove it and we may will find another way (E.g. adjust vlmax_avl > pattern COST) > to optimize it if we really need to care about performance for O1. > > PR target/111313 > > gcc/ChangeLog: > > * config/riscv/riscv-vsetvl.cc > (pass_vsetvl::cleanup_earliest_vsetvls): Remove. > (pass_vsetvl::df_post_optimization): Remove incorrect function. > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/rvv/vsetvl/avl_single-13.c: Adapt test. > * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-17.c: Skip check for > O1. > * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-18.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-19.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-20.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-10.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-11.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-12.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-13.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-14.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-15.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-16.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-17.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-18.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-19.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-20.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-21.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-22.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-23.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-24.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-25.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-26.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-27.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-28.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-3.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-4.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-5.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-6.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-7.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-8.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-9.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-2.c: Ditto. > * gcc.target/riscv/rvv/autovec/pr111313.c: New test. > > --- > gcc/config/riscv/riscv-vsetvl.cc | 58 --- > .../gcc.target/riscv/rvv/autovec/pr111313.c | 20 +++ > .../riscv/rvv/vsetvl/avl_single-13.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_bb_prop-17.c | 8 +-- > .../riscv/rvv/vsetvl/vlmax_bb_prop-18.c | 8 +-- > .../riscv/rvv/vsetvl/vlmax_bb_prop-19.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_bb_prop-20.c | 4 +- > .../gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-10.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-11.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-12.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-13.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-14.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-15.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-16.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-17.c | 2 +- >
[Bug target/111313] RISC-V: Incorrect vsetvl code gen for 2 level loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111313 --- Comment #1 from CVS Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:572abb52f5761a647035ee39d0e443c1c3622e75 commit r14-3765-g572abb52f5761a647035ee39d0e443c1c3622e75 Author: Juzhe-Zhong Date: Thu Sep 7 11:35:53 2023 +0800 RISC-V: Remove incorrect earliest vsetvl post optimization[PR111313] This patch removes the incorrect earliest poset vsetvl optimization, such bug was found in vect-double-reduc-5.c which is runtime(execution fail) and also in PR111313. For VLMAX intrinsics, we always emit a bogus patter which is vlmax_avl (see vector.md) to occupy a scalar register which is used by the following RVV instruction which is VLMAX AVL. Then for O2, O3, Ofast, earliest LCM works so well. However, for O1, the vlmax_avl is not well optimized in the before pass which confused LCM earliest so that we will end up with some redundant vsetvli zero,zero instructions in O1. (Note that O2 O3 Ofast are all good). To elide those redundant vsetvli zero,zero, I added cleanup_earliest_vsetvls to elide those redundant vsetvls. Now, after I review the implementation of this post optimizaiton again, I found it is incorrect and it is hard to do the post optimizations for vsetvls that earliest LCM failed to eliminate. Besides, such performance issues only happen in O1 or O0, such issues may not be serious. So remove it and we may will find another way (E.g. adjust vlmax_avl pattern COST) to optimize it if we really need to care about performance for O1. PR target/111313 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pass_vsetvl::cleanup_earliest_vsetvls): Remove. (pass_vsetvl::df_post_optimization): Remove incorrect function. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/vsetvl/avl_single-13.c: Adapt test. * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-17.c: Skip check for O1. * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-18.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-19.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-20.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-10.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-11.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-12.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-13.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-14.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-15.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-16.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-17.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-18.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-19.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-20.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-21.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-22.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-23.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-24.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-25.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-26.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-27.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-28.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-3.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-4.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-5.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-6.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-7.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-8.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-9.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-2.c: Ditto. * gcc.target/riscv/rvv/autovec/pr111313.c: New test.
Re: [PATCH] RISC-V: Remove incorrect earliest vsetvl post optimization[PR111313]
LGTM Juzhe-Zhong 於 2023年9月7日 週四 11:36 寫道： > This patch removes the incorrect earliest poset vsetvl optimization, > such bug was found in vect-double-reduc-5.c which is runtime(execution > fail) and also in PR111313. > > For VLMAX intrinsics, we always emit a bogus patter which is vlmax_avl > (see vector.md) to > occupy a scalar register which is used by the following RVV instruction > which is VLMAX AVL. > > Then for O2, O3, Ofast, earliest LCM works so well. > However, for O1, the vlmax_avl is not well optimized in the before pass > which confused LCM earliest > so that we will end up with some redundant vsetvli zero,zero instructions > in O1. (Note that O2 O3 Ofast are all good). > > To elide those redundant vsetvli zero,zero, I added > cleanup_earliest_vsetvls to elide those redundant vsetvls. > > Now, after I review the implementation of this post optimizaiton again, I > found it is incorrect and it is hard to > do the post optimizations for vsetvls that earliest LCM failed to > eliminate. > > Besides, such performance issues only happen in O1 or O0, such issues may > not be serious. > So remove it and we may will find another way (E.g. adjust vlmax_avl > pattern COST) > to optimize it if we really need to care about performance for O1. > > PR target/111313 > > gcc/ChangeLog: > > * config/riscv/riscv-vsetvl.cc > (pass_vsetvl::cleanup_earliest_vsetvls): Remove. > (pass_vsetvl::df_post_optimization): Remove incorrect function. > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/rvv/vsetvl/avl_single-13.c: Adapt test. > * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-17.c: Skip check for > O1. > * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-18.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-19.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-20.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-10.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-11.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-12.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-13.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-14.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-15.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-16.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-17.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-18.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-19.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-20.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-21.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-22.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-23.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-24.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-25.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-26.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-27.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-28.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-3.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-4.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-5.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-6.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-7.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-8.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_phi-9.c: Ditto. > * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-2.c: Ditto. > * gcc.target/riscv/rvv/autovec/pr111313.c: New test. > > --- > gcc/config/riscv/riscv-vsetvl.cc | 58 --- > .../gcc.target/riscv/rvv/autovec/pr111313.c | 20 +++ > .../riscv/rvv/vsetvl/avl_single-13.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_bb_prop-17.c | 8 +-- > .../riscv/rvv/vsetvl/vlmax_bb_prop-18.c | 8 +-- > .../riscv/rvv/vsetvl/vlmax_bb_prop-19.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_bb_prop-20.c | 4 +- > .../gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-10.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-11.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-12.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-13.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-14.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-15.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-16.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-17.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-18.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-19.c | 2 +- > .../gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-20.c | 2 +- > .../riscv/rvv/vsetvl/vlmax_phi-21.c | 2 +- >
[Bug c++/111314] New: Can not deduct parameter pack as a single type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111314
Bug ID: 111314
Summary: Can not deduct parameter pack as a single type
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xgao at nvidia dot com
Target Milestone: ---
The following code does not work:
#include
template
struct Template {};
template typename, typename>
struct DynamicType {};
template
struct is_dynamic_type : std::false_type {};
template typename Template, typename... Ts>
struct is_dynamic_type> : std::true_type {};
template
constexpr bool is_dynamic_type_v = is_dynamic_type::value;
// This fails:
static_assert(is_dynamic_type_v>);
int main() {}
[PATCH] RISC-V: Remove incorrect earliest vsetvl post optimization[PR111313]
This patch removes the incorrect earliest poset vsetvl optimization, such bug was found in vect-double-reduc-5.c which is runtime(execution fail) and also in PR111313. For VLMAX intrinsics, we always emit a bogus patter which is vlmax_avl (see vector.md) to occupy a scalar register which is used by the following RVV instruction which is VLMAX AVL. Then for O2, O3, Ofast, earliest LCM works so well. However, for O1, the vlmax_avl is not well optimized in the before pass which confused LCM earliest so that we will end up with some redundant vsetvli zero,zero instructions in O1. (Note that O2 O3 Ofast are all good). To elide those redundant vsetvli zero,zero, I added cleanup_earliest_vsetvls to elide those redundant vsetvls. Now, after I review the implementation of this post optimizaiton again, I found it is incorrect and it is hard to do the post optimizations for vsetvls that earliest LCM failed to eliminate. Besides, such performance issues only happen in O1 or O0, such issues may not be serious. So remove it and we may will find another way (E.g. adjust vlmax_avl pattern COST) to optimize it if we really need to care about performance for O1. PR target/111313 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pass_vsetvl::cleanup_earliest_vsetvls): Remove. (pass_vsetvl::df_post_optimization): Remove incorrect function. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/vsetvl/avl_single-13.c: Adapt test. * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-17.c: Skip check for O1. * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-18.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-19.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-20.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-10.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-11.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-12.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-13.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-14.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-15.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-16.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-17.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-18.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-19.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-20.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-21.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-22.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-23.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-24.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-25.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-26.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-27.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-28.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-3.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-4.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-5.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-6.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-7.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-8.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-9.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-2.c: Ditto. * gcc.target/riscv/rvv/autovec/pr111313.c: New test. --- gcc/config/riscv/riscv-vsetvl.cc | 58 --- .../gcc.target/riscv/rvv/autovec/pr111313.c | 20 +++ .../riscv/rvv/vsetvl/avl_single-13.c | 2 +- .../riscv/rvv/vsetvl/vlmax_bb_prop-17.c | 8 +-- .../riscv/rvv/vsetvl/vlmax_bb_prop-18.c | 8 +-- .../riscv/rvv/vsetvl/vlmax_bb_prop-19.c | 2 +- .../riscv/rvv/vsetvl/vlmax_bb_prop-20.c | 4 +- .../gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-10.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-11.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-12.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-13.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-14.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-15.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-16.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-17.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-18.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-19.c | 2 +- .../gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-20.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-21.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-22.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-23.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-24.c | 2 +- .../riscv/rvv/vsetvl/vlmax_phi-25.c | 2 +-
[PATCH] Checking undefined_p before using the vr
Hi,
As discussed in PR111303:
For pattern "(X + C) / N": "div (plus@3 @0 INTEGER_CST@1) INTEGER_CST@2)",
Even if "X" has value-range and "X + C" does not overflow, "@3" may still
be undefined. Like below example:
_3 = _2 + -5;
if (0 != 0)
goto ; [34.00%]
else
goto ; [66.00%]
;; succ: 3
;; 4
;; basic block 3, loop depth 0
;; pred: 2
_5 = _3 / 5;
;; succ: 4
The whole pattern "(_2 + -5 ) / 5" is in "bb 3", but "bb 3" would be
unreachable (because "if (0 != 0)" is always false).
And "get_range_query (cfun)->range_of_expr (vr3, @3)" is checked in
"bb 3", "range_of_expr" gets an "undefined vr3". Where "@3" is "_5".
So, before using "vr3", it would be safe to check "!vr3.undefined_p ()".
Bootstrap & regtest pass on ppc64{,le} and x86_64.
Is this ok for trunk?
BR,
Jeff (Jiufu Guo)
PR middle-end/111303
gcc/ChangeLog:
* match.pd ((X - N * M) / N): Add undefined_p checking.
(X + N * M) / N): Likewise.
((X + C) div_rshift N): Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/pr111303.c: New test.
---
gcc/match.pd| 3 +++
gcc/testsuite/gcc.dg/pr111303.c | 11 +++
2 files changed, 14 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/pr111303.c
diff --git a/gcc/match.pd b/gcc/match.pd
index 801edb128f9..e2583ca7960 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -975,6 +975,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* "X+(N*M)" doesn't overflow. */
&& range_op_handler (PLUS_EXPR).overflow_free_p (vr0, vr3)
&& get_range_query (cfun)->range_of_expr (vr4, @4)
+ && !vr4.undefined_p ()
/* "X+N*M" is not with opposite sign as "X". */
&& (TYPE_UNSIGNED (type)
|| (vr0.nonnegative_p () && vr4.nonnegative_p ())
@@ -995,6 +996,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* "X - (N*M)" doesn't overflow. */
&& range_op_handler (MINUS_EXPR).overflow_free_p (vr0, vr3)
&& get_range_query (cfun)->range_of_expr (vr4, @4)
+ && !vr4.undefined_p ()
/* "X-N*M" is not with opposite sign as "X". */
&& (TYPE_UNSIGNED (type)
|| (vr0.nonnegative_p () && vr4.nonnegative_p ())
@@ -1025,6 +1027,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* "X+C" doesn't overflow. */
&& range_op_handler (PLUS_EXPR).overflow_free_p (vr0, vr1)
&& get_range_query (cfun)->range_of_expr (vr3, @3)
+ && !vr3.undefined_p ()
/* "X+C" and "X" are not of opposite sign. */
&& (TYPE_UNSIGNED (type)
|| (vr0.nonnegative_p () && vr3.nonnegative_p ())
diff --git a/gcc/testsuite/gcc.dg/pr111303.c b/gcc/testsuite/gcc.dg/pr111303.c
new file mode 100644
index 000..eaabe55c105
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111303.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+/* Make sure no ICE. */
+unsigned char a;
+int b(int c) {
+ if (c >= 5000)
+return c / 5;
+}
+void d() { b(a - 5); }
+int main() {}
--
2.25.1
Re: [PATCH v3] RISC-V: Add autovec FP binary operations.
Hi Robin, Yes, you're right, this should not be necessary. This is more of a test for the execution environment than the compiler. I think Juzhe removed it already in his patch that enables the vector test suite. In the future we would use the checks that Joern added, not sure if they are already upstream All right, let's wait for further action. Thanks. -- Best, Lehua
Re: [PATCH] LoongArch: Link c++ header directory in the default ABI to the toplevel.
On Wed, Sep 06, 2023 at 06:38:25PM +0800, Xi Ruoyao wrote:
> On Wed, 2023-09-06 at 18:06 +0800, Yang Yujie wrote:
> > When multilib is enabled, the c++ header directory of the default multilib
> > variant needs to be linked to the toplevel since g++ does not search the
> > toplevel in this case.
> >
> > libstdc++-v3/ChangeLog:
> >
> > * configure.host: Register t-loongarch in tmake_file.
> > * config/cpu/loongarch/t-loongarch: New file. Link c++ header
> > directory in the default ABI to the toplevel.
> > ---
> > libstdc++-v3/config/cpu/loongarch/t-loongarch | 12
> > libstdc++-v3/configure.host | 5 -
> > 2 files changed, 16 insertions(+), 1 deletion(-)
> > create mode 100644 libstdc++-v3/config/cpu/loongarch/t-loongarch
> >
> > diff --git a/libstdc++-v3/config/cpu/loongarch/t-loongarch
> > b/libstdc++-v3/config/cpu/loongarch/t-loongarch
> > new file mode 100644
> > index 000..942eddeb3be
> > --- /dev/null
> > +++ b/libstdc++-v3/config/cpu/loongarch/t-loongarch
> > @@ -0,0 +1,12 @@
> > +LA_DEFAULT_MULTIDIR = $(shell $(CXX) --print-multi-directory)
> > +TOPLEV_HEADERS =
> > $(DESTDIR)${gxx_include_dir}/${host_alias}/$(LA_DEFAULT_MULTIDIR)
> > +
> > +.PHONY: install-toplevel-link
> > +install: install-toplevel-link
> > +install-toplevel-link:
> > + if test x$(MULTIDO) != xtrue && \
> > + test x$(LA_DEFAULT_MULTIDIR) != x.; then \
> > + $(MKDIR_P) "$(dir $(TOPLEV_HEADERS))"; \
> > + rm -rf "$(TOPLEV_HEADERS)"; \
> > + $(LN_S) ../ "$(TOPLEV_HEADERS)"; \
>
> From autoconf info page:
>
> -- Macro: AC_PROG_LN_S
> If ‘ln -s’ works on the current file system (the operating system
> and file system support symbolic links), set the output variable
> ‘LN_S’ to ‘ln -s’; otherwise, if ‘ln’ works, set ‘LN_S’ to ‘ln’,
> and otherwise set it to ‘cp -pR’.
>
> If you make a link in a directory other than the current directory,
> its meaning depends on whether ‘ln’ or ‘ln -s’ is used. To safely
> create links using ‘$(LN_S)’, either find out which form is used
> and adjust the arguments, or always invoke ‘ln’ in the directory
> where the link is to be created.
>
> In other words, it does not work to do:
> $(LN_S) foo /x/bar
>
> Instead, do:
>
> (cd /x && $(LN_S) foo bar)
>
> But for this special case we cannot "cp -pR ../ $(TOPLEV_HEADERS)"
> either:
>
> $ cp ../* -pR something
> cp: cannot copy a directory, '../g', into itself, 'h/g'
>
> So I guess we'll need something like
>
> if ln -s ../ "$(TOPLEV_HEADERS)"; then
> # OK!
> true
> else
> # system does not support symlink :(
> # install another copy of toplevel headers into default multilib subdir
> TODO:
> fi
>
> And all libstdc++ patches should Cc: libstd...@gcc.gnu.org.
>
> > + fi
> > diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
> > index 9e7c7f02dfd..9dc42ad3edb 100644
> > --- a/libstdc++-v3/configure.host
> > +++ b/libstdc++-v3/configure.host
> > @@ -315,7 +315,10 @@ esac
> > # Set any OS-dependent and CPU-dependent bits.
> > # THIS TABLE IS SORTED. KEEP IT THAT WAY.
> > case "${host}" in
> > - *-*-linux* | *-*-uclinux*)
> > + loongarch*)
> > + tmake_file="cpu/loongarch/t-loongarch"
> > + ;;
> > + *-*-linux* | *-*-uclinux*)
> > case "${host_cpu}" in
> > i[567]86)
> > abi_baseline_pair=i486-linux-gnu
>
> --
> Xi Ruoyao
> School of Aerospace Science and Technology, Xidian University
Thanks for the review!
After some tweaking, it appeared that we can simply override
${multisubdir} in configure.host and achieve the same.
I will upload another patch soon.
Yujie
Re: [PATCH v1 4/4] LoongArch: Add tests for Loongson SX floating-point conversion instructions.
在 2023-09-06三的 18:56 +0800，Xi Ruoyao写道： > On Wed, 2023-09-06 at 18:45 +0800, Xiaolong Chen wrote: > > + *((int*)& __m128_op0[3]) = 0x004200a0; > > + *((int*)& __m128_op0[2]) = 0x; > > + *((int*)& __m128_op0[1]) = 0x004200a0; > > + *((int*)& __m128_op0[0]) = 0x0021; > > These are aliasing rule violation and they will suddenly blow up when > GCC optimizer starts to optimize more aggressively based on the > aliasing > rule. > > Try not to use these (you can write a helper function to memcpy() > into a > __m128). Or use -fno-strict-alising in dg-options. > Okay, thanks for the tip. After carefully reading the gcc manual, a new addition -fno-strict-aliasing in dg-options is added. Thanks.
[PATCH v4] RISC-V:Optimize the MASK opt generation
This patch rebases the change of "[PATCH] RISC-V: Optimize the MASK opt generation" and add the new explanation in the options.texi. gcc/ChangeLog: * config/riscv/riscv-opts.h (MASK_ZICSR): (MASK_ZIFENCEI): Delete; (MASK_ZIHINTNTL):Ditto; (MASK_ZIHINTPAUSE): Ditto; (TARGET_ZICSR): Ditto; (TARGET_ZIFENCEI): Ditto; (TARGET_ZIHINTNTL): Ditto; (TARGET_ZIHINTPAUSE):Ditto; (MASK_ZAWRS):Ditto; (TARGET_ZAWRS): Ditto; (MASK_ZBA): Ditto; (MASK_ZBB): Ditto; (MASK_ZBC): Ditto; (MASK_ZBS): Ditto; (TARGET_ZBA):Ditto; (TARGET_ZBB):Ditto; (TARGET_ZBC):Ditto; (TARGET_ZBS):Ditto; (MASK_ZFINX):Ditto; (MASK_ZDINX):Ditto; (MASK_ZHINX):Ditto; (MASK_ZHINXMIN): Ditto; (TARGET_ZFINX): Ditto; (TARGET_ZDINX): Ditto; (TARGET_ZHINX): Ditto; (TARGET_ZHINXMIN): Ditto; (MASK_ZBKB): Ditto; (MASK_ZBKC): Ditto; (MASK_ZBKX): Ditto; (MASK_ZKNE): Ditto; (MASK_ZKND): Ditto; (MASK_ZKNH): Ditto; (MASK_ZKR): Ditto; (MASK_ZKSED):Ditto; (MASK_ZKSH): Ditto; (MASK_ZKT): Ditto; (TARGET_ZBKB): Ditto; (TARGET_ZBKC): Ditto; (TARGET_ZBKX): Ditto; (TARGET_ZKNE): Ditto; (TARGET_ZKND): Ditto; (TARGET_ZKNH): Ditto; (TARGET_ZKR):Ditto; (TARGET_ZKSED): Ditto; (TARGET_ZKSH): Ditto; (TARGET_ZKT):Ditto; (MASK_ZTSO): Ditto; (TARGET_ZTSO): Ditto; (MASK_VECTOR_ELEN_32): Ditto; (MASK_VECTOR_ELEN_64): Ditto; (MASK_VECTOR_ELEN_FP_32):Ditto; (MASK_VECTOR_ELEN_FP_64):Ditto; (MASK_VECTOR_ELEN_FP_16):Ditto; (TARGET_VECTOR_ELEN_32): Ditto; (TARGET_VECTOR_ELEN_64): Ditto; (TARGET_VECTOR_ELEN_FP_32):Ditto; (TARGET_VECTOR_ELEN_FP_64):Ditto; (TARGET_VECTOR_ELEN_FP_16):Ditto; (MASK_ZVBB): Ditto; (MASK_ZVBC): Ditto; (TARGET_ZVBB): Ditto; (TARGET_ZVBC): Ditto; (MASK_ZVKG): Ditto; (MASK_ZVKNED): Ditto; (MASK_ZVKNHA): Ditto; (MASK_ZVKNHB): Ditto; (MASK_ZVKSED): Ditto; (MASK_ZVKSH): Ditto; (MASK_ZVKN): Ditto; (MASK_ZVKNC): Ditto; (MASK_ZVKNG): Ditto; (MASK_ZVKS): Ditto; (MASK_ZVKSC): Ditto; (MASK_ZVKSG): Ditto; (MASK_ZVKT): Ditto; (TARGET_ZVKG): Ditto; (TARGET_ZVKNED): Ditto; (TARGET_ZVKNHA): Ditto; (TARGET_ZVKNHB): Ditto; (TARGET_ZVKSED): Ditto; (TARGET_ZVKSH):Ditto; (TARGET_ZVKN): Ditto; (TARGET_ZVKNC):Ditto; (TARGET_ZVKNG):Ditto; (TARGET_ZVKS): Ditto; (TARGET_ZVKSC):Ditto; (TARGET_ZVKSG):Ditto; (TARGET_ZVKT): Ditto; (MASK_ZVL32B): Ditto; (MASK_ZVL64B): Ditto; (MASK_ZVL128B):Ditto; (MASK_ZVL256B):Ditto; (MASK_ZVL512B):Ditto; (MASK_ZVL1024B): Ditto; (MASK_ZVL2048B): Ditto; (MASK_ZVL4096B): Ditto; (MASK_ZVL8192B): Ditto; (MASK_ZVL16384B): Ditto; (MASK_ZVL32768B): Ditto; (MASK_ZVL65536B): Ditto; (TARGET_ZVL32B): Ditto; (TARGET_ZVL64B): Ditto; (TARGET_ZVL128B): Ditto; (TARGET_ZVL256B): Ditto; (TARGET_ZVL512B): Ditto; (TARGET_ZVL1024B): Ditto; (TARGET_ZVL2048B): Ditto; (TARGET_ZVL4096B): Ditto; (TARGET_ZVL8192B): Ditto; (TARGET_ZVL16384B):Ditto; (TARGET_ZVL32768B):Ditto; (TARGET_ZVL65536B):Ditto; (MASK_ZICBOZ): Ditto; (MASK_ZICBOM): Ditto; (MASK_ZICBOP): Ditto; (TARGET_ZICBOZ): Ditto; (TARGET_ZICBOM): Ditto; (TARGET_ZICBOP): Ditto; (MASK_ZICOND): Ditto; (TARGET_ZICOND): Ditto; (MASK_ZFA):Ditto; (TARGET_ZFA): Ditto; (MASK_ZFHMIN): Ditto; (MASK_ZFH):Ditto; (MASK_ZVFHMIN):Ditto; (MASK_ZVFH): Ditto; (TARGET_ZFHMIN): Ditto; (TARGET_ZFH): Ditto; (TARGET_ZVFHMIN): Ditto;
[RFC PATCH 2/2] RISC-V: Update testsuite for type-changed builtins
From: Tsukasa OI
This commit replaces the type of the builtin used in the testsuite.
Even without this commit, it won't cause any test failures but changed so
that no confusion occurs.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zbc32.c: Make signed type to unsigned.
* gcc.target/riscv/zbc64.c: Ditto.
* gcc.target/riscv/zbkb32.c: Ditto.
* gcc.target/riscv/zbkb64.c: Ditto.
* gcc.target/riscv/zbkc32.c: Ditto.
* gcc.target/riscv/zbkc64.c: Ditto.
* gcc.target/riscv/zbkx32.c: Ditto.
* gcc.target/riscv/zbkx64.c: Ditto.
* gcc.target/riscv/zknd32.c: Ditto.
* gcc.target/riscv/zknd64.c: Ditto.
* gcc.target/riscv/zkne32.c: Ditto.
* gcc.target/riscv/zkne64.c: Ditto.
* gcc.target/riscv/zknh-sha256.c: Ditto.
* gcc.target/riscv/zknh-sha512-32.c: Ditto.
* gcc.target/riscv/zknh-sha512-64.c: Ditto.
* gcc.target/riscv/zksed32.c: Ditto.
* gcc.target/riscv/zksed64.c: Ditto.
* gcc.target/riscv/zksh32.c: Ditto.
* gcc.target/riscv/zksh64.c: Ditto.
---
gcc/testsuite/gcc.target/riscv/zbc32.c | 6 +++---
gcc/testsuite/gcc.target/riscv/zbc64.c | 6 +++---
gcc/testsuite/gcc.target/riscv/zbkb32.c | 10 +-
gcc/testsuite/gcc.target/riscv/zbkb64.c | 8
gcc/testsuite/gcc.target/riscv/zbkc32.c | 4 ++--
gcc/testsuite/gcc.target/riscv/zbkc64.c | 4 ++--
gcc/testsuite/gcc.target/riscv/zbkx32.c | 4 ++--
gcc/testsuite/gcc.target/riscv/zbkx64.c | 4 ++--
gcc/testsuite/gcc.target/riscv/zknd32.c | 4 ++--
gcc/testsuite/gcc.target/riscv/zknd64.c | 10 +-
gcc/testsuite/gcc.target/riscv/zkne32.c | 4 ++--
gcc/testsuite/gcc.target/riscv/zkne64.c | 8
gcc/testsuite/gcc.target/riscv/zknh-sha256.c| 8
gcc/testsuite/gcc.target/riscv/zknh-sha512-32.c | 12 ++--
gcc/testsuite/gcc.target/riscv/zknh-sha512-64.c | 8
gcc/testsuite/gcc.target/riscv/zksed32.c| 4 ++--
gcc/testsuite/gcc.target/riscv/zksed64.c| 4 ++--
gcc/testsuite/gcc.target/riscv/zksh32.c | 4 ++--
gcc/testsuite/gcc.target/riscv/zksh64.c | 4 ++--
19 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/zbc32.c
b/gcc/testsuite/gcc.target/riscv/zbc32.c
index 08705c4a687e..f3fb2238f7f4 100644
--- a/gcc/testsuite/gcc.target/riscv/zbc32.c
+++ b/gcc/testsuite/gcc.target/riscv/zbc32.c
@@ -3,17 +3,17 @@
/* { dg-skip-if "" { *-*-* } { "-g" "-flto"} } */
#include
-int32_t foo1(int32_t rs1, int32_t rs2)
+uint32_t foo1(uint32_t rs1, uint32_t rs2)
{
return __builtin_riscv_clmul(rs1, rs2);
}
-int32_t foo2(int32_t rs1, int32_t rs2)
+uint32_t foo2(uint32_t rs1, uint32_t rs2)
{
return __builtin_riscv_clmulh(rs1, rs2);
}
-int32_t foo3(int32_t rs1, int32_t rs2)
+uint32_t foo3(uint32_t rs1, uint32_t rs2)
{
return __builtin_riscv_clmulr(rs1, rs2);
}
diff --git a/gcc/testsuite/gcc.target/riscv/zbc64.c
b/gcc/testsuite/gcc.target/riscv/zbc64.c
index a19f42b2883f..841a0aa7847d 100644
--- a/gcc/testsuite/gcc.target/riscv/zbc64.c
+++ b/gcc/testsuite/gcc.target/riscv/zbc64.c
@@ -3,17 +3,17 @@
/* { dg-skip-if "" { *-*-* } { "-g" "-flto"} } */
#include
-int64_t foo1(int64_t rs1, int64_t rs2)
+uint64_t foo1(uint64_t rs1, uint64_t rs2)
{
return __builtin_riscv_clmul(rs1, rs2);
}
-int64_t foo2(int64_t rs1, int64_t rs2)
+uint64_t foo2(uint64_t rs1, uint64_t rs2)
{
return __builtin_riscv_clmulh(rs1, rs2);
}
-int64_t foo3(int64_t rs1, int64_t rs2)
+uint64_t foo3(uint64_t rs1, uint64_t rs2)
{
return __builtin_riscv_clmulr(rs1, rs2);
}
diff --git a/gcc/testsuite/gcc.target/riscv/zbkb32.c
b/gcc/testsuite/gcc.target/riscv/zbkb32.c
index dd45b8b9dc72..b2e442dc49d8 100644
--- a/gcc/testsuite/gcc.target/riscv/zbkb32.c
+++ b/gcc/testsuite/gcc.target/riscv/zbkb32.c
@@ -4,27 +4,27 @@
#include
-int32_t foo1(int16_t rs1, int16_t rs2)
+uint32_t foo1(uint16_t rs1, uint16_t rs2)
{
return __builtin_riscv_pack(rs1, rs2);
}
-int32_t foo2(int8_t rs1, int8_t rs2)
+uint32_t foo2(uint8_t rs1, uint8_t rs2)
{
return __builtin_riscv_packh(rs1, rs2);
}
-int32_t foo3(int32_t rs1)
+uint32_t foo3(uint32_t rs1)
{
return __builtin_riscv_brev8(rs1);
}
-int32_t foo4(int32_t rs1)
+uint32_t foo4(uint32_t rs1)
{
return __builtin_riscv_zip(rs1);
}
-int32_t foo5(int32_t rs1)
+uint32_t foo5(uint32_t rs1)
{
return __builtin_riscv_unzip(rs1);
}
diff --git a/gcc/testsuite/gcc.target/riscv/zbkb64.c
b/gcc/testsuite/gcc.target/riscv/zbkb64.c
index 960a2ae30ed6..08ac9c2a9f00 100644
--- a/gcc/testsuite/gcc.target/riscv/zbkb64.c
+++ b/gcc/testsuite/gcc.target/riscv/zbkb64.c
@@ -3,22 +3,22 @@
/* { dg-skip-if "" { *-*-* } { "-g" "-flto"} } */
#include
-int64_t foo1(int32_t rs1, int32_t rs2)
+uint64_t foo1(uint32_t rs1, uint32_t rs2)
{
return
[RFC PATCH 1/2] RISC-V: Make bit manipulation value / round number and shift amount types for builtins unsigned
From: Tsukasa OI
For bit manipulation operations, inputs and the manipulated output are
better to be unsigned like other target-independent builtins like
__builtin_bswap32 and __builtin_popcount.
Although this is not completely compatible as before (as the type changes),
most code will run normally, even without warnings (with -Wall -Wextra).
Round numbers and shift amount on the scalar crypto instructions are
changed to unsigned in parity with LLVM 17 commit 599421ae36c3
("[RISCV] Use unsigned instead of signed types for Zk* and Zb* builtins.").
gcc/ChangeLog:
* config/riscv/riscv-builtins.cc (RISCV_ATYPE_UQI): New for
uint8_t. (RISCV_ATYPE_UHI): New for uint16_t.
(RISCV_ATYPE_QI, RISCV_ATYPE_HI, RISCV_ATYPE_SI, RISCV_ATYPE_DI):
Removed as no longer used.
(RISCV_ATYPE_UDI): New for uint64_t.
* config/riscv/riscv-cmo.def: Make types unsigned for not working
"zicbop_cbo_prefetchi" and working bit manipulation clmul builtin
argument/return types.
* config/riscv/riscv-ftypes.def: Make bit manipulation, round
number and shift amount types unsigned.
* config/riscv/riscv-scalar-crypto.def: Ditto.
---
gcc/config/riscv/riscv-builtins.cc | 7 +-
gcc/config/riscv/riscv-cmo.def | 16 ++--
gcc/config/riscv/riscv-ftypes.def| 24 +++---
gcc/config/riscv/riscv-scalar-crypto.def | 104 +++
4 files changed, 75 insertions(+), 76 deletions(-)
diff --git a/gcc/config/riscv/riscv-builtins.cc
b/gcc/config/riscv/riscv-builtins.cc
index 8afe7b7e97d3..f6b06b3c16ac 100644
--- a/gcc/config/riscv/riscv-builtins.cc
+++ b/gcc/config/riscv/riscv-builtins.cc
@@ -155,11 +155,10 @@ AVAIL (hint_pause, (!0))
/* Argument types. */
#define RISCV_ATYPE_VOID void_type_node
+#define RISCV_ATYPE_UQI unsigned_intQI_type_node
+#define RISCV_ATYPE_UHI unsigned_intHI_type_node
#define RISCV_ATYPE_USI unsigned_intSI_type_node
-#define RISCV_ATYPE_QI intQI_type_node
-#define RISCV_ATYPE_HI intHI_type_node
-#define RISCV_ATYPE_SI intSI_type_node
-#define RISCV_ATYPE_DI intDI_type_node
+#define RISCV_ATYPE_UDI unsigned_intDI_type_node
#define RISCV_ATYPE_VOID_PTR ptr_type_node
/* RISCV_FTYPE_ATYPESN takes N RISCV_FTYPES-like type codes and lists
diff --git a/gcc/config/riscv/riscv-cmo.def b/gcc/config/riscv/riscv-cmo.def
index b92044dc6ff9..ff713b78e19e 100644
--- a/gcc/config/riscv/riscv-cmo.def
+++ b/gcc/config/riscv/riscv-cmo.def
@@ -13,15 +13,15 @@ RISCV_BUILTIN (zero_si, "zicboz_cbo_zero",
RISCV_BUILTIN_DIRECT_NO_TARGET, RISCV
RISCV_BUILTIN (zero_di, "zicboz_cbo_zero", RISCV_BUILTIN_DIRECT_NO_TARGET,
RISCV_VOID_FTYPE_VOID_PTR, zero64),
// zicbop
-RISCV_BUILTIN (prefetchi_si, "zicbop_cbo_prefetchi", RISCV_BUILTIN_DIRECT,
RISCV_SI_FTYPE_SI, prefetchi32),
-RISCV_BUILTIN (prefetchi_di, "zicbop_cbo_prefetchi", RISCV_BUILTIN_DIRECT,
RISCV_DI_FTYPE_DI, prefetchi64),
+RISCV_BUILTIN (prefetchi_si, "zicbop_cbo_prefetchi", RISCV_BUILTIN_DIRECT,
RISCV_USI_FTYPE_USI, prefetchi32),
+RISCV_BUILTIN (prefetchi_di, "zicbop_cbo_prefetchi", RISCV_BUILTIN_DIRECT,
RISCV_UDI_FTYPE_UDI, prefetchi64),
// zbkc or zbc
-RISCV_BUILTIN (clmul_si, "clmul", RISCV_BUILTIN_DIRECT, RISCV_SI_FTYPE_SI_SI,
clmul_zbkc32_or_zbc32),
-RISCV_BUILTIN (clmul_di, "clmul", RISCV_BUILTIN_DIRECT, RISCV_DI_FTYPE_DI_DI,
clmul_zbkc64_or_zbc64),
-RISCV_BUILTIN (clmulh_si, "clmulh", RISCV_BUILTIN_DIRECT,
RISCV_SI_FTYPE_SI_SI, clmul_zbkc32_or_zbc32),
-RISCV_BUILTIN (clmulh_di, "clmulh", RISCV_BUILTIN_DIRECT,
RISCV_DI_FTYPE_DI_DI, clmul_zbkc64_or_zbc64),
+RISCV_BUILTIN (clmul_si, "clmul", RISCV_BUILTIN_DIRECT,
RISCV_USI_FTYPE_USI_USI, clmul_zbkc32_or_zbc32),
+RISCV_BUILTIN (clmul_di, "clmul", RISCV_BUILTIN_DIRECT,
RISCV_UDI_FTYPE_UDI_UDI, clmul_zbkc64_or_zbc64),
+RISCV_BUILTIN (clmulh_si, "clmulh", RISCV_BUILTIN_DIRECT,
RISCV_USI_FTYPE_USI_USI, clmul_zbkc32_or_zbc32),
+RISCV_BUILTIN (clmulh_di, "clmulh", RISCV_BUILTIN_DIRECT,
RISCV_UDI_FTYPE_UDI_UDI, clmul_zbkc64_or_zbc64),
// zbc
-RISCV_BUILTIN (clmulr_si, "clmulr", RISCV_BUILTIN_DIRECT,
RISCV_SI_FTYPE_SI_SI, clmulr_zbc32),
-RISCV_BUILTIN (clmulr_di, "clmulr", RISCV_BUILTIN_DIRECT,
RISCV_DI_FTYPE_DI_DI, clmulr_zbc64),
+RISCV_BUILTIN (clmulr_si, "clmulr", RISCV_BUILTIN_DIRECT,
RISCV_USI_FTYPE_USI_USI, clmulr_zbc32),
+RISCV_BUILTIN (clmulr_di, "clmulr", RISCV_BUILTIN_DIRECT,
RISCV_UDI_FTYPE_UDI_UDI, clmulr_zbc64),
diff --git a/gcc/config/riscv/riscv-ftypes.def
b/gcc/config/riscv/riscv-ftypes.def
index 3b518195a29c..366861ce640e 100644
--- a/gcc/config/riscv/riscv-ftypes.def
+++ b/gcc/config/riscv/riscv-ftypes.def
@@ -30,15 +30,15 @@ DEF_RISCV_FTYPE (0, (USI))
DEF_RISCV_FTYPE (0, (VOID))
DEF_RISCV_FTYPE (1, (VOID, USI))
DEF_RISCV_FTYPE (1, (VOID, VOID_PTR))
-DEF_RISCV_FTYPE (1, (SI, SI))
-DEF_RISCV_FTYPE (1, (DI, DI))
-DEF_RISCV_FTYPE (2, (SI, QI, QI))
-DEF_RISCV_FTYPE (2, (SI, HI, HI))
-DEF_RISCV_FTYPE (2, (SI, SI, SI))
-DEF_RISCV_FTYPE (2, (DI, QI, QI))
-DEF_RISCV_FTYPE
[RFC PATCH 0/2] RISC-V: Change RISC-V bit manipulation / scalar crypto builtin types
Hello,
Many RISC-V builtins operate in signed integer types but in many cases,
they are better to be unsigned.
There are a few reasons to do that:
1. Being more natural
For bit manipulation operations, the direct input and the result should
have an unsigned type.
e.g. __builtin_bswap16
Both input and output should be (and are) unsigned.
e.g. __builtin_popcount
The input should be (and is) unsigned.
The output is a bit count and is in int (signed integer).
2. In parity with LLVM 17
LLVM made similar changes to this patch set in commit 599421ae36c3
("[RISCV] Use unsigned instead of signed types for Zk* and Zb*
builtins.") by Craig Topper.
Note that shift amount / round number argument types are changed to
unsigned in this LLVM commit, I did the same.
3. Minimum compatibility breakage
This change rarely causes warnings even if both -Wall and -Wextra are
specified. In fact, only applying PATCH 1/2 does not cause any
additional test failures. PATCH 2/2 only contains testsuite changes
(uses correct types as the builtin uses).
But not completely compatible. For instance, we will notice when operating
with for instance C++'s "auto" / "decltype" or overload resolution.
So, I would like to hear your thoughts first.
Note that, the only reason I separated this RFC patch set to two patches
is to demonstrate that no additional warnings occur even if only PATCH 1/2
is applied. If approved or leaves an RFC PATCH, both will be merged.
p.s.
LLVM has another type of different builtin types (with the same name),
scalar cryptography builtins that operate in 32-bit integers, not XLEN-
specific (applies to SHA-256, SM3 and SM4). For those cases, GCC prefers
XLEN-specific integer type but LLVM 17 always prefers uint32_t.
This is a result of LLVM commit 599421ae36c3 ("[RISCV] Re-define sha256,
Zksed, and Zksh intrinsics to use i32 types.").
Because just changing the width causes errors on GCC, even if I change them
to uint32_t, that would be in a different patch set.
Sincerely,
Tsukasa
Tsukasa OI (2):
RISC-V: Make bit manipulation value / round number and shift amount
types for builtins unsigned
RISC-V: Update testsuite for type-changed builtins
gcc/config/riscv/riscv-builtins.cc| 7 +-
gcc/config/riscv/riscv-cmo.def| 16 +--
gcc/config/riscv/riscv-ftypes.def | 24 ++--
gcc/config/riscv/riscv-scalar-crypto.def | 104 +-
gcc/testsuite/gcc.target/riscv/zbc32.c| 6 +-
gcc/testsuite/gcc.target/riscv/zbc64.c| 6 +-
gcc/testsuite/gcc.target/riscv/zbkb32.c | 10 +-
gcc/testsuite/gcc.target/riscv/zbkb64.c | 8 +-
gcc/testsuite/gcc.target/riscv/zbkc32.c | 4 +-
gcc/testsuite/gcc.target/riscv/zbkc64.c | 4 +-
gcc/testsuite/gcc.target/riscv/zbkx32.c | 4 +-
gcc/testsuite/gcc.target/riscv/zbkx64.c | 4 +-
gcc/testsuite/gcc.target/riscv/zknd32.c | 4 +-
gcc/testsuite/gcc.target/riscv/zknd64.c | 10 +-
gcc/testsuite/gcc.target/riscv/zkne32.c | 4 +-
gcc/testsuite/gcc.target/riscv/zkne64.c | 8 +-
gcc/testsuite/gcc.target/riscv/zknh-sha256.c | 8 +-
.../gcc.target/riscv/zknh-sha512-32.c | 12 +-
.../gcc.target/riscv/zknh-sha512-64.c | 8 +-
gcc/testsuite/gcc.target/riscv/zksed32.c | 4 +-
gcc/testsuite/gcc.target/riscv/zksed64.c | 4 +-
gcc/testsuite/gcc.target/riscv/zksh32.c | 4 +-
gcc/testsuite/gcc.target/riscv/zksh64.c | 4 +-
23 files changed, 133 insertions(+), 134 deletions(-)
base-commit: af88776caa20342482b11ccb580742a46c621250
--
2.42.0
Re: [PATCH] LoongArch: Use bstrins instruction for (a & ~mask) and (a & mask) | (b & ~mask) [PR111252]
在 2023/9/6 下午6:58, Xi Ruoyao 写道: Forgot to mention: I've bootstrapped and regtested this patch on loongarch64-linux-gnu (with PR110939 patch applied to unbreak the bootstrapping). Ok for trunk? LGTM! Thanks! On Wed, 2023-09-06 at 18:46 +0800, Xi Ruoyao wrote: If mask is a constant with value ((1 << N) - 1) << M we can perform this optimization. gcc/ChangeLog: PR target/111252 * config/loongarch/loongarch-protos.h (loongarch_pre_reload_split): Declare new function. (loongarch_use_bstrins_for_ior_with_mask): Likewise. * config/loongarch/loongarch.cc (loongarch_pre_reload_split): Implement. (loongarch_use_bstrins_for_ior_with_mask): Likewise. * config/loongarch/predicates.md (ins_zero_bitmask_operand): New predicate. * config/loongarch/loongarch.md (bstrins__for_mask): New define_insn_and_split. (bstrins__for_ior_mask): Likewise. (define_peephole2): Further optimize code sequence produced by bstrins__for_ior_mask if possible. gcc/testsuite/ChangeLog: * g++.target/loongarch/bstrins-compile.C: New test. * g++.target/loongarch/bstrins-run.C: New test. /* snip */
[Bug tree-optimization/111268] [14 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-09-07
Ever confirmed|0 |1
--- Comment #8 from Andrew Pinski ---
Reduced testcase:
```
#include
void f(unsigned long *expected, svuint64_t values) {
svst1_u64(svptrue_b64(), expected, values);
expected[0] = (expected[0]+1);
expected[1] = (expected[1]+1);
}
```
[PATCH] Support vpermw/vpermi2w/vpermt2w instructions for vector HF/BFmodes.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
* config/i386/sse.md
(_vpermt2var3): New define_insn.
(VHFBF_AVX512VL): New mode iterator.
(VI2HFBF_AVX512VL): New mode iterator.
---
gcc/config/i386/sse.md | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 6d3ae8dea0c..12fe97951ee 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -466,6 +466,10 @@ (define_mode_iterator VHFBF_128 [V8HF V8BF])
(define_mode_iterator VHF_AVX512VL
[V32HF (V16HF "TARGET_AVX512VL") (V8HF "TARGET_AVX512VL")])
+(define_mode_iterator VHFBF_AVX512VL
+ [V32HF (V16HF "TARGET_AVX512VL") (V8HF "TARGET_AVX512VL")
+ V32BF (V16BF "TARGET_AVX512VL") (V8BF "TARGET_AVX512VL")])
+
;; All vector integer modes
(define_mode_iterator VI
[(V16SI "TARGET_AVX512F") (V8DI "TARGET_AVX512F")
@@ -565,6 +569,11 @@ (define_mode_iterator VI48_AVX512F_AVX512VL
(define_mode_iterator VI2_AVX512VL
[(V8HI "TARGET_AVX512VL") (V16HI "TARGET_AVX512VL") V32HI])
+(define_mode_iterator VI2HFBF_AVX512VL
+ [(V8HI "TARGET_AVX512VL") (V16HI "TARGET_AVX512VL") V32HI
+ (V8HF "TARGET_AVX512VL") (V16HF "TARGET_AVX512VL") V32HF
+ (V8BF "TARGET_AVX512VL") (V16BF "TARGET_AVX512VL") V32BF])
+
(define_mode_iterator VI2H_AVX512VL
[(V8HI "TARGET_AVX512VL") (V16HI "TARGET_AVX512VL") V32HI
(V8SI "TARGET_AVX512VL") V16SI
@@ -26110,13 +26119,13 @@ (define_insn "_permvar"
(set_attr "mode" "")])
(define_insn "_permvar"
- [(set (match_operand:VI2_AVX512VL 0 "register_operand" "=v")
- (unspec:VI2_AVX512VL
- [(match_operand:VI2_AVX512VL 1 "nonimmediate_operand" "vm")
+ [(set (match_operand:VI2HFBF_AVX512VL 0 "register_operand" "=v")
+ (unspec:VI2HFBF_AVX512VL
+ [(match_operand:VI2HFBF_AVX512VL 1 "nonimmediate_operand" "vm")
(match_operand: 2 "register_operand" "v")]
UNSPEC_VPERMVAR))]
"TARGET_AVX512BW && "
- "vperm\t{%1, %2, %0|%0, %2, %1}"
+ "vpermw\t{%1, %2, %0|%0, %2, %1}"
[(set_attr "type" "sselog")
(set_attr "prefix" "")
(set_attr "mode" "")])
@@ -26987,6 +26996,21 @@ (define_insn
"_vpermt2var3"
(set_attr "prefix" "evex")
(set_attr "mode" "")])
+(define_insn "_vpermt2var3"
+ [(set (match_operand:VHFBF_AVX512VL 0 "register_operand" "=v,v")
+ (unspec:VHFBF_AVX512VL
+ [(match_operand: 1 "register_operand" "v,0")
+ (match_operand:VHFBF_AVX512VL 2 "register_operand" "0,v")
+ (match_operand:VHFBF_AVX512VL 3 "nonimmediate_operand" "vm,vm")]
+ UNSPEC_VPERMT2))]
+ "TARGET_AVX512BW"
+ "@
+ vpermt2w\t{%3, %1, %0|%0, %1, %3}
+ vpermi2w\t{%3, %2, %0|%0, %2, %3}"
+ [(set_attr "type" "sselog")
+ (set_attr "prefix" "evex")
+ (set_attr "mode" "")])
+
(define_insn "_vpermt2var3_mask"
[(set (match_operand:VPERMI2 0 "register_operand" "=v")
(vec_merge:VPERMI2
--
2.31.1
Re: [PATCH v1 1/4] LoongArch: Add tests of -mstrict-align option.
在 2023/9/6 下午7:10, Xi Ruoyao 写道:
On Wed, 2023-09-06 at 18:43 +0800, Xiaolong Chen wrote:
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/strict-align.c: New test.
A question: is there really a CPU model with LSX/LASX but without
unaligned access support? If not I think we'd just reject -mstrict-
align -mlsx.
Currently Glibc assumes if LSX is available then unaligned access must
be available too.
This is not a question of support or unsupport, the original intention
is to need to naturally align memory access to improve performance after
enabling LSX, but this part of the code has not been ported to the main
branch, so we will submit this test example after adding the
corresponding function.
Thanks!
---
gcc/testsuite/gcc.target/loongarch/strict-align.c | 13 +
1 file changed, 13 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/loongarch/strict-align.c
diff --git a/gcc/testsuite/gcc.target/loongarch/strict-align.c
b/gcc/testsuite/gcc.target/loongarch/strict-align.c
new file mode 100644
index 000..bcad2b84f68
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/strict-align.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-Ofast -mstrict-align -mlasx" } */
+/* { dg-final { scan-assembler-not "vfadd.s" } } */
+
+void
+foo (float* restrict x, float* restrict y)
+{
+ x[0] = x[0] + y[0];
+ x[1] = x[1] + y[1];
+ x[2] = x[2] + y[2];
+ x[3] = x[3] + y[3];
+}
+
[Bug c/111313] New: RISC-V: Incorrect code gen for 2 level loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111313
Bug ID: 111313
Summary: RISC-V: Incorrect code gen for 2 level loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pan2.li at intel dot com
Target Milestone: ---
Created attachment 55846
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55846=edit
Reproduce code
Given we have an example code as below.
#define K 32
signed short in[2*K][K] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
signed short coeff[K][K] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
__attribute__ ((noinline)) void
test ()
{
for (int j = 0; j < K; j++)
{
for (int i = 0; i < 2*K; i++)
in[i][j] = i+j;
for (int i = 0; i < K; i++)
coeff[i][j] = i + 2;
}
}
When compile with option similar to "-march=rv64imafdcv -mabi=lp64d
-mcmodel=medlow -fdiagnostics-plain-output -flto -ffat-lto-objects --param
riscv-autovec-preference=scalable -Wno-psabi -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common
-fdump-tree-vect-details "
The assembly code will be:
init_in:
lui t1,%hi(coeff)
lui a7,%hi(in)
csrra0,vlenb
addit1,t1,%lo(coeff)
addia7,a7,%lo(in)
srlia0,a0,2
li a6,0
li t3,32
vsetvli a1,zero,e16,mf2,ta,ma
vid.v v3
vsll.vi v3,v3,6
.L2:
mv a2,a7
li a4,64
vmv.v.x v4,a6 <= this insn will have e16 first, and then e32 when loop
back
vsetvli zero,zero,e32,m1,ta,ma
vid.v v2
.L3:
vsetvli zero,zero,e16,mf2,ta,ma
vmv1r.v v1,v2
vncvt.x.x.w v1,v1
vsetvli a5,a4,e8,mf4,ta,ma
vsetvli a3,zero,e16,mf2,ta,ma
sub a4,a4,a5
vadd.vv v1,v1,v4
vsetvli zero,a5,e16,mf2,ta,ma
sllia5,a5,6
vsuxei16.v v1,(a2),v3
vsetvli a1,zero,e32,m1,ta,ma
add a2,a2,a5
vmv.v.x v1,a0
vadd.vv v2,v2,v1
bne a4,zero,.L3
mv a2,t1
li a4,32
vid.v v2
.L4:
vsetvli zero,zero,e16,mf2,ta,ma
vmv1r.v v1,v2
vncvt.x.x.w v1,v1
vsetvli a5,a4,e8,mf4,ta,ma
vsetvli a3,zero,e16,mf2,ta,ma
sub a4,a4,a5
vadd.vi v1,v1,2
vsetvli zero,a5,e16,mf2,ta,ma
sllia5,a5,6
vsuxei16.v v1,(a2),v3
vsetvli a1,zero,e32,m1,ta,ma
add a2,a2,a5
vmv.v.x v1,a0
vadd.vv v2,v2,v1
bne a4,zero,.L4
addiw a6,a6,1
addit1,t1,2
addia7,a7,2
bne a6,t3,.L2
ret
Re: Re: [PATCH v3] RISC-V:Optimize the MASK opt generation
Thanks reminder, I should rebase again. -- Feng Wang >Hi, > >I will need to notify you that x_riscv_xventana_subext, >MASK_XVENTANACONDOPS and TARGET_XVENTANACONDOPS are added (I think you >want to rewrite those definitions like the rest). Also, be careful not >to remove TARGET_ZICOND_LIKE. > >Thanks, >Tsukasa > >On 2023/09/06 11:02, Feng Wang wrote: >> This patch rebases the change of "[PATCH] RISC-V: Optimize the MASK opt >> generation" and add the new explanation in the options.texi. >> Please check the detail info on the >> "https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg302295.html; >> gcc/ChangeLog: >> >> * config/riscv/riscv-opts.h (MASK_ZICSR): >> (MASK_ZIFENCEI): Delete; >> (MASK_ZIHINTNTL): Ditto; >> (MASK_ZIHINTPAUSE): Ditto; >> (TARGET_ZICSR): Ditto; >> (TARGET_ZIFENCEI): Ditto; >> (TARGET_ZIHINTNTL): Ditto; >> (TARGET_ZIHINTPAUSE):Ditto; >> (MASK_ZAWRS): Ditto; >> (TARGET_ZAWRS): Ditto; >> (MASK_ZBA): Ditto; >> (MASK_ZBB): Ditto; >> (MASK_ZBC): Ditto; >> (MASK_ZBS): Ditto; >> (TARGET_ZBA): Ditto; >> (TARGET_ZBB): Ditto; >> (TARGET_ZBC): Ditto; >> (TARGET_ZBS): Ditto; >> (MASK_ZFINX): Ditto; >> (MASK_ZDINX): Ditto; >> (MASK_ZHINX): Ditto; >> (MASK_ZHINXMIN): Ditto; >> (TARGET_ZFINX): Ditto; >> (TARGET_ZDINX): Ditto; >> (TARGET_ZHINX): Ditto; >> (TARGET_ZHINXMIN): Ditto; >> (MASK_ZBKB): Ditto; >> (MASK_ZBKC): Ditto; >> (MASK_ZBKX): Ditto; >> (MASK_ZKNE): Ditto; >> (MASK_ZKND): Ditto; >> (MASK_ZKNH): Ditto; >> (MASK_ZKR): Ditto; >> (MASK_ZKSED): Ditto; >> (MASK_ZKSH): Ditto; >> (MASK_ZKT): Ditto; >> (TARGET_ZBKB): Ditto; >> (TARGET_ZBKC): Ditto; >> (TARGET_ZBKX): Ditto; >> (TARGET_ZKNE): Ditto; >> (TARGET_ZKND): Ditto; >> (TARGET_ZKNH): Ditto; >> (TARGET_ZKR): Ditto; >> (TARGET_ZKSED): Ditto; >> (TARGET_ZKSH): Ditto; >> (TARGET_ZKT): Ditto; >> (MASK_ZTSO): Ditto; >> (TARGET_ZTSO): Ditto; >> (MASK_VECTOR_ELEN_32): Ditto; >> (MASK_VECTOR_ELEN_64): Ditto; >> (MASK_VECTOR_ELEN_FP_32):Ditto; >> (MASK_VECTOR_ELEN_FP_64):Ditto; >> (MASK_VECTOR_ELEN_FP_16):Ditto; >> (TARGET_VECTOR_ELEN_32): Ditto; >> (TARGET_VECTOR_ELEN_64): Ditto; >> (TARGET_VECTOR_ELEN_FP_32):Ditto; >> (TARGET_VECTOR_ELEN_FP_64):Ditto; >> (TARGET_VECTOR_ELEN_FP_16):Ditto; >> (MASK_ZVBB): Ditto; >> (MASK_ZVBC): Ditto; >> (TARGET_ZVBB): Ditto; >> (TARGET_ZVBC): Ditto; >> (MASK_ZVKG): Ditto; >> (MASK_ZVKNED): Ditto; >> (MASK_ZVKNHA): Ditto; >> (MASK_ZVKNHB): Ditto; >> (MASK_ZVKSED): Ditto; >> (MASK_ZVKSH): Ditto; >> (MASK_ZVKN): Ditto; >> (MASK_ZVKNC): Ditto; >> (MASK_ZVKNG): Ditto; >> (MASK_ZVKS): Ditto; >> (MASK_ZVKSC): Ditto; >> (MASK_ZVKSG): Ditto; >> (MASK_ZVKT): Ditto; >> (TARGET_ZVKG): Ditto; >> (TARGET_ZVKNED): Ditto; >> (TARGET_ZVKNHA): Ditto; >> (TARGET_ZVKNHB): Ditto; >> (TARGET_ZVKSED): Ditto; >> (TARGET_ZVKSH): Ditto; >> (TARGET_ZVKN): Ditto; >> (TARGET_ZVKNC): Ditto; >> (TARGET_ZVKNG): Ditto; >> (TARGET_ZVKS): Ditto; >> (TARGET_ZVKSC): Ditto; >> (TARGET_ZVKSG): Ditto; >> (TARGET_ZVKT): Ditto; >> (MASK_ZVL32B): Ditto; >> (MASK_ZVL64B): Ditto; >> (MASK_ZVL128B): Ditto; >> (MASK_ZVL256B): Ditto; >> (MASK_ZVL512B): Ditto; >> (MASK_ZVL1024B): Ditto; >> (MASK_ZVL2048B): Ditto; >> (MASK_ZVL4096B): Ditto; >> (MASK_ZVL8192B): Ditto; >> (MASK_ZVL16384B): Ditto; >> (MASK_ZVL32768B): Ditto; >> (MASK_ZVL65536B): Ditto; >> (TARGET_ZVL32B): Ditto; >> (TARGET_ZVL64B): Ditto; >> (TARGET_ZVL128B): Ditto; >> (TARGET_ZVL256B): Ditto; >> (TARGET_ZVL512B): Ditto; >> (TARGET_ZVL1024B): Ditto; >> (TARGET_ZVL2048B): Ditto; >>
Re: [PATCH v3] RISC-V:Optimize the MASK opt generation
Hi, I will need to notify you that x_riscv_xventana_subext, MASK_XVENTANACONDOPS and TARGET_XVENTANACONDOPS are added (I think you want to rewrite those definitions like the rest). Also, be careful not to remove TARGET_ZICOND_LIKE. Thanks, Tsukasa On 2023/09/06 11:02, Feng Wang wrote: > This patch rebases the change of "[PATCH] RISC-V: Optimize the MASK opt > generation" and add the new explanation in the options.texi. > Please check the detail info on the > "https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg302295.html; > gcc/ChangeLog: > > * config/riscv/riscv-opts.h (MASK_ZICSR): > (MASK_ZIFENCEI): Delete; > (MASK_ZIHINTNTL):Ditto; > (MASK_ZIHINTPAUSE): Ditto; > (TARGET_ZICSR): Ditto; > (TARGET_ZIFENCEI): Ditto; > (TARGET_ZIHINTNTL): Ditto; > (TARGET_ZIHINTPAUSE):Ditto; > (MASK_ZAWRS):Ditto; > (TARGET_ZAWRS): Ditto; > (MASK_ZBA): Ditto; > (MASK_ZBB): Ditto; > (MASK_ZBC): Ditto; > (MASK_ZBS): Ditto; > (TARGET_ZBA):Ditto; > (TARGET_ZBB):Ditto; > (TARGET_ZBC):Ditto; > (TARGET_ZBS):Ditto; > (MASK_ZFINX):Ditto; > (MASK_ZDINX):Ditto; > (MASK_ZHINX):Ditto; > (MASK_ZHINXMIN): Ditto; > (TARGET_ZFINX): Ditto; > (TARGET_ZDINX): Ditto; > (TARGET_ZHINX): Ditto; > (TARGET_ZHINXMIN): Ditto; > (MASK_ZBKB): Ditto; > (MASK_ZBKC): Ditto; > (MASK_ZBKX): Ditto; > (MASK_ZKNE): Ditto; > (MASK_ZKND): Ditto; > (MASK_ZKNH): Ditto; > (MASK_ZKR): Ditto; > (MASK_ZKSED):Ditto; > (MASK_ZKSH): Ditto; > (MASK_ZKT): Ditto; > (TARGET_ZBKB): Ditto; > (TARGET_ZBKC): Ditto; > (TARGET_ZBKX): Ditto; > (TARGET_ZKNE): Ditto; > (TARGET_ZKND): Ditto; > (TARGET_ZKNH): Ditto; > (TARGET_ZKR):Ditto; > (TARGET_ZKSED): Ditto; > (TARGET_ZKSH): Ditto; > (TARGET_ZKT):Ditto; > (MASK_ZTSO): Ditto; > (TARGET_ZTSO): Ditto; > (MASK_VECTOR_ELEN_32): Ditto; > (MASK_VECTOR_ELEN_64): Ditto; > (MASK_VECTOR_ELEN_FP_32):Ditto; > (MASK_VECTOR_ELEN_FP_64):Ditto; > (MASK_VECTOR_ELEN_FP_16):Ditto; > (TARGET_VECTOR_ELEN_32): Ditto; > (TARGET_VECTOR_ELEN_64): Ditto; > (TARGET_VECTOR_ELEN_FP_32):Ditto; > (TARGET_VECTOR_ELEN_FP_64):Ditto; > (TARGET_VECTOR_ELEN_FP_16):Ditto; > (MASK_ZVBB): Ditto; > (MASK_ZVBC): Ditto; > (TARGET_ZVBB): Ditto; > (TARGET_ZVBC): Ditto; > (MASK_ZVKG): Ditto; > (MASK_ZVKNED): Ditto; > (MASK_ZVKNHA): Ditto; > (MASK_ZVKNHB): Ditto; > (MASK_ZVKSED): Ditto; > (MASK_ZVKSH): Ditto; > (MASK_ZVKN): Ditto; > (MASK_ZVKNC): Ditto; > (MASK_ZVKNG): Ditto; > (MASK_ZVKS): Ditto; > (MASK_ZVKSC): Ditto; > (MASK_ZVKSG): Ditto; > (MASK_ZVKT): Ditto; > (TARGET_ZVKG): Ditto; > (TARGET_ZVKNED): Ditto; > (TARGET_ZVKNHA): Ditto; > (TARGET_ZVKNHB): Ditto; > (TARGET_ZVKSED): Ditto; > (TARGET_ZVKSH):Ditto; > (TARGET_ZVKN): Ditto; > (TARGET_ZVKNC):Ditto; > (TARGET_ZVKNG):Ditto; > (TARGET_ZVKS): Ditto; > (TARGET_ZVKSC):Ditto; > (TARGET_ZVKSG):Ditto; > (TARGET_ZVKT): Ditto; > (MASK_ZVL32B): Ditto; > (MASK_ZVL64B): Ditto; > (MASK_ZVL128B):Ditto; > (MASK_ZVL256B):Ditto; > (MASK_ZVL512B):Ditto; > (MASK_ZVL1024B): Ditto; > (MASK_ZVL2048B): Ditto; > (MASK_ZVL4096B): Ditto; > (MASK_ZVL8192B): Ditto; > (MASK_ZVL16384B): Ditto; > (MASK_ZVL32768B): Ditto; > (MASK_ZVL65536B): Ditto; > (TARGET_ZVL32B): Ditto; > (TARGET_ZVL64B): Ditto; > (TARGET_ZVL128B): Ditto; > (TARGET_ZVL256B): Ditto; > (TARGET_ZVL512B): Ditto; > (TARGET_ZVL1024B): Ditto; > (TARGET_ZVL2048B): Ditto; > (TARGET_ZVL4096B): Ditto; > (TARGET_ZVL8192B): Ditto; > (TARGET_ZVL16384B):Ditto; > (TARGET_ZVL32768B):Ditto; > (TARGET_ZVL65536B):Ditto; >
Re: [PATCH 3/5] RISC-V: Add Types to Un-Typed Zicond Instructions
On 2023/09/07 2:50, Edwin Lu wrote:
> This patch creates a new "zicond" type and updates all zicond instructions
> with that type.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md: Add "zicond" type
> * config/riscv/zicond.md: Update types
>
> Signed-off-by: Edwin Lu
> ---
> gcc/config/riscv/riscv.md | 5 +++--
> gcc/config/riscv/zicond.md | 8
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index 6684ad89cff..c329f55db43 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -313,6 +313,7 @@ (define_attr "ext_enabled" "no,yes"
> ;; cbocache block instructions
> ;; crypto cryptography instructions
> ;; csrcode size reduction instructions
> +;; zicondzicond instructions
> ;; Classification of RVV instructions which will be added to each RVV .md
> pattern and used by scheduler.
> ;; rdvlenb vector byte length vlenb csrr read
> ;; rdvlvector length vl csrr read
> @@ -422,8 +423,8 @@ (define_attr "type"
> mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul,
> fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip,
> rotate,clmul,min,max,minu,maxu,clz,ctz,cpop,
> - atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
> - vlde,vste,vldm,vstm,vlds,vsts,
> + atomic,condmove,cbo,crypto,csr,zicond,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,
> + vsetvl, vlde,vste,vldm,vstm,vlds,vsts,
> vldux,vldox,vstux,vstox,vldff,vldr,vstr,
>
> vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff,
> vialu,viwalu,vext,vicalu,vshift,vnshift,vicmp,viminmax,
> diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md
> index 1721e1011ea..0269bd14399 100644
> --- a/gcc/config/riscv/zicond.md
> +++ b/gcc/config/riscv/zicond.md
> @@ -30,7 +30,7 @@ (define_insn "*czero.."
>(const_int 0)))]
>"TARGET_ZICOND"
>"czero.\t%0,%2,%1"
> -)
> +[(set_attr "type" "zicond")])
>
> (define_insn "*czero.."
>[(set (match_operand:GPR 0 "register_operand" "=r")
> @@ -40,7 +40,7 @@ (define_insn "*czero.."
>(match_operand:GPR 2 "register_operand" "r")))]
>"TARGET_ZICOND"
>"czero.\t%0,%2,%1"
> -)
> +[(set_attr "type" "zicond")])
>
> ;; Special optimization under eq/ne in primitive semantics
> (define_insn "*czero.eqz..opt1"
> @@ -51,7 +51,7 @@ (define_insn "*czero.eqz..opt1"
>(match_operand:GPR 3 "register_operand" "r")))]
>"TARGET_ZICOND && rtx_equal_p (operands[1], operands[2])"
>"czero.eqz\t%0,%3,%1"
> -)
> +[(set_attr "type" "zicond")])
>
> (define_insn "*czero.nez..opt2"
>[(set (match_operand:GPR 0 "register_operand" "=r")
> @@ -61,7 +61,7 @@ (define_insn "*czero.nez..opt2"
>(match_operand:GPR 3 "register_operand" "1")))]
>"TARGET_ZICOND && rtx_equal_p (operands[1], operands[3])"
>"czero.eqz\t%0,%2,%1"
> -)
> +[(set_attr "type" "zicond")])
>
> ;; Combine creates this form in some cases (particularly the coremark
> ;; CRC loop.
Looks okay to me but will need to resolve merge conflicts after commit
af88776caa20 ("RISC-V: Add support for 'XVentanaCondOps' reusing
'Zicond' support").
Thanks,
Tsukasa
Mm om Yu
Sent from my iPhone
Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes
> Date: Thu, 7 Sep 2023 00:11:04 +0100 > From: Jonathan Wakely via Gcc-patches > On Thu, 7 Sept 2023 at 00:10, Jonathan Wakely wrote: > > I don't think there's a bug. $is_hosted is true for > > --enable-hosted-libstdcxx which is on by default. > > And IIRC __STDC_HOSTED__ is defined unless you compile with -ffreestanding. Also documented and thus fine by any (reasonable) definition :) no need for anyone (me) to guess. brgds, H-P
Re: [PATCH 2/5] RISC-V: Add Types for Un-Typed zc Instructions
csr is kind of confusing, I would suggest something like `pushpop` and
`mvpair`.
Edwin Lu 於 2023年9月7日 週四 01:51 寫道：
> This patch adds types to the untyped zc instructions. Creates a new
> type "csr" for these instructions for now.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md: Add "csr" type
> * config/riscv/zc.md: Update types
>
> Signed-off-by: Edwin Lu
> ---
> gcc/config/riscv/riscv.md | 3 +-
> gcc/config/riscv/zc.md| 102 +++---
> 2 files changed, 54 insertions(+), 51 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index d80b6938f84..6684ad89cff 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -312,6 +312,7 @@ (define_attr "ext_enabled" "no,yes"
> ;; condmoveconditional moves
> ;; cbocache block instructions
> ;; crypto cryptography instructions
> +;; csrcode size reduction instructions
> ;; Classification of RVV instructions which will be added to each RVV .md
> pattern and used by scheduler.
> ;; rdvlenb vector byte length vlenb csrr read
> ;; rdvlvector length vl csrr read
> @@ -421,7 +422,7 @@ (define_attr "type"
> mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul,
> fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip,
> rotate,clmul,min,max,minu,maxu,clz,ctz,cpop,
> - atomic,condmove,cbo,crypto,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
> + atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
> vlde,vste,vldm,vstm,vlds,vsts,
> vldux,vldox,vstux,vstox,vldff,vldr,vstr,
>
> vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff,
> diff --git a/gcc/config/riscv/zc.md b/gcc/config/riscv/zc.md
> index 77b28adde95..86f1afd66cb 100644
> --- a/gcc/config/riscv/zc.md
> +++ b/gcc/config/riscv/zc.md
> @@ -27,7 +27,7 @@ (define_insn "@gpr_multi_pop_up_to_ra_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop {ra}, %0"
> -)
> +[(set_attr "type" "csr")])
>
> (define_insn "@gpr_multi_pop_up_to_s0_"
>[(set (reg:X SP_REGNUM)
> @@ -41,7 +41,7 @@ (define_insn "@gpr_multi_pop_up_to_s0_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop {ra, s0}, %0"
> -)
> +[(set_attr "type" "csr")])
>
> (define_insn "@gpr_multi_pop_up_to_s1_"
>[(set (reg:X SP_REGNUM)
> @@ -58,7 +58,7 @@ (define_insn "@gpr_multi_pop_up_to_s1_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop {ra, s0-s1}, %0"
> -)
> +[(set_attr "type" "csr")])
>
> (define_insn "@gpr_multi_pop_up_to_s2_"
>[(set (reg:X SP_REGNUM)
> @@ -78,7 +78,7 @@ (define_insn "@gpr_multi_pop_up_to_s2_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop {ra, s0-s2}, %0"
> -)
> +[(set_attr "type" "csr")])
>
> (define_insn "@gpr_multi_pop_up_to_s3_"
>[(set (reg:X SP_REGNUM)
> @@ -101,7 +101,7 @@ (define_insn "@gpr_multi_pop_up_to_s3_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop {ra, s0-s3}, %0"
> -)
> +[(set_attr "type" "csr")])
>
> (define_insn "@gpr_multi_pop_up_to_s4_"
>[(set (reg:X SP_REGNUM)
> @@ -127,7 +127,7 @@ (define_insn "@gpr_multi_pop_up_to_s4_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop {ra, s0-s4}, %0"
> -)
> +[(set_attr "type" "csr")])
>
> (define_insn "@gpr_multi_pop_up_to_s5_"
>[(set (reg:X SP_REGNUM)
> @@ -156,7 +156,7 @@ (define_insn "@gpr_multi_pop_up_to_s5_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop {ra, s0-s5}, %0"
> -)
> +[(set_attr "type" "csr")])
>
> (define_insn "@gpr_multi_pop_up_to_s6_"
>[(set (reg:X SP_REGNUM)
> @@ -188,7 +188,7 @@ (define_insn "@gpr_multi_pop_up_to_s6_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop {ra, s0-s6}, %0"
> -)
> +[(set_attr "type" "csr")])
>
> (define_insn "@gpr_multi_pop_up_to_s7_"
>[(set (reg:X SP_REGNUM)
> @@ -223,7 +223,7 @@ (define_insn "@gpr_multi_pop_up_to_s7_"
>(const_int ]
>"TARGET_ZCMP"
>"cm.pop {ra, s0-s7}, %0"
> -)
> +[(set_attr "type" "csr")])
>
> (define_insn "@gpr_multi_pop_up_to_s8_"
>[(set (reg:X SP_REGNUM)
> @@ -261,7 +261,7 @@ (define_insn "@gpr_multi_pop_up_to_s8_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop {ra, s0-s8}, %0"
> -)
> +[(set_attr "type" "csr")])
>
> (define_insn "@gpr_multi_pop_up_to_s9_"
>[(set (reg:X SP_REGNUM)
> @@ -302,7 +302,7 @@ (define_insn "@gpr_multi_pop_up_to_s9_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop {ra, s0-s9}, %0"
> -)
> +[(set_attr "type" "csr")])
>
> (define_insn "@gpr_multi_pop_up_to_s11_"
>[(set (reg:X SP_REGNUM)
> @@ -349,7 +349,7 @@ (define_insn "@gpr_multi_pop_up_to_s11_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop {ra, s0-s11}, %0"
> -)
> +[(set_attr "type"
Re: [PATCH 1/5] RISC-V: Update Types for Vector Instructions
LGTM Edwin Lu 於 2023年9月7日 週四 01:51 寫道： > This patch adds types to vector instructions that were added after or were > missed by the original patch > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628594.html > > gcc/ChangeLog: > > * config/riscv/autovec-opt.md: Update types > * config/riscv/autovec.md: likewise > > Signed-off-by: Edwin Lu > --- > gcc/config/riscv/autovec-opt.md | 42 ++--- > gcc/config/riscv/autovec.md | 28 +++--- > 2 files changed, 47 insertions(+), 23 deletions(-) > > diff --git a/gcc/config/riscv/autovec-opt.md > b/gcc/config/riscv/autovec-opt.md > index 1ca5ce97193..6cc1a01629c 100644 > --- a/gcc/config/riscv/autovec-opt.md > +++ b/gcc/config/riscv/autovec-opt.md > @@ -728,7 +728,8 @@ (define_insn_and_split "*cond_abs" > gen_int_mode (GET_MODE_NUNITS > (mode), Pmode), > const0_rtx)); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine vlmax neg and UNSPEC_VCOPYSIGN > (define_insn_and_split "*copysign_neg" > @@ -746,7 +747,8 @@ (define_insn_and_split "*copysign_neg" >riscv_vector::emit_vlmax_insn (code_for_pred_ncopysign (mode), >riscv_vector::BINARY_OP, operands); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine sign_extend/zero_extend(vf2) and vcond_mask > (define_insn_and_split "*cond_" > @@ -765,7 +767,8 @@ (define_insn_and_split > "*cond_" > gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; >riscv_vector::expand_cond_len_unop (icode, ops); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine sign_extend/zero_extend(vf4) and vcond_mask > (define_insn_and_split "*cond_" > @@ -784,7 +787,8 @@ (define_insn_and_split > "*cond_" > gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; >riscv_vector::expand_cond_len_unop (icode, ops); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine sign_extend/zero_extend(vf8) and vcond_mask > (define_insn_and_split "*cond_" > @@ -803,7 +807,8 @@ (define_insn_and_split > "*cond_" > gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; >riscv_vector::expand_cond_len_unop (icode, ops); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine trunc(vf2) + vcond_mask > (define_insn_and_split "*cond_trunc" > @@ -823,7 +828,8 @@ (define_insn_and_split > "*cond_trunc" > gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; >riscv_vector::expand_cond_len_unop (icode, ops); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine FP sign_extend/zero_extend(vf2) and vcond_mask > (define_insn_and_split "*cond_extend" > @@ -842,7 +848,8 @@ (define_insn_and_split > "*cond_extend" > gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; >riscv_vector::expand_cond_len_unop (icode, ops); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine FP trunc(vf2) + vcond_mask > (define_insn_and_split "*cond_trunc" > @@ -862,7 +869,8 @@ (define_insn_and_split > "*cond_trunc" > gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; >riscv_vector::expand_cond_len_unop (icode, ops); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine convert(FP->INT) + vcond_mask > (define_insn_and_split "*cond_" > @@ -882,7 +890,8 @@ (define_insn_and_split "*cond_" > gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; >riscv_vector::expand_cond_len_unop (icode, ops); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine convert(INT->FP) + vcond_mask > (define_insn_and_split "*cond_" > @@ -902,7 +911,8 @@ (define_insn_and_split > "*cond_" > gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; >riscv_vector::expand_cond_len_unop (icode, ops); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine convert(FP->2xINT) + vcond_mask > (define_insn_and_split "*cond_" > @@ -922,7 +932,8 @@ (define_insn_and_split "*cond_" > gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; >riscv_vector::expand_cond_len_unop (icode, ops); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine convert(INT->2xFP) + vcond_mask > (define_insn_and_split "*cond_" > @@ -942,7 +953,8 @@ (define_insn_and_split > "*cond_" > gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; >riscv_vector::expand_cond_len_unop (icode, ops); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine convert(2xFP->INT) + vcond_mask > (define_insn_and_split "*cond_" > @@ -962,7 +974,8 @@ (define_insn_and_split "*cond_" > gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; >riscv_vector::expand_cond_len_unop (icode, ops); >DONE; > -}) > +} > +[(set_attr "type" "vector")]) > > ;; Combine convert(2xINT->FP) + vcond_mask > (define_insn_and_split "*cond_2" > @@ -982,4 +995,5 @@
Re: [PATCH 4/5] RISC-V: Update Types for RISC-V Instructions
LGTM Edwin Lu 於 2023年9月7日 週四 01:52 寫道： > This patch adds types to riscv instructions that were added or were > missed by the original patch > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628996.html > > gcc/ChangeLog: > > * config/riscv/riscv.md: Update types > > Signed-off-by: Edwin Lu > --- > gcc/config/riscv/riscv.md | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md > index c329f55db43..c1cecd27815 100644 > --- a/gcc/config/riscv/riscv.md > +++ b/gcc/config/riscv/riscv.md > @@ -2223,6 +2223,7 @@ (define_insn "movsidf2_low_rv32" >"TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA" >"fmv.x.w\t%0,%1" >[(set_attr "move_type" "fmove") > + (set_attr "type" "fmove") > (set_attr "mode" "DF")]) > > > @@ -2235,6 +2236,7 @@ (define_insn "movsidf2_high_rv32" >"TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA" >"fmvh.x.d\t%0,%1" >[(set_attr "move_type" "fmove") > + (set_attr "type" "fmove") > (set_attr "mode" "DF")]) > > (define_insn "movdfsisi3_rv32" > @@ -2247,6 +2249,7 @@ (define_insn "movdfsisi3_rv32" >"TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA" >"fmvp.d.x\t%0,%2,%1" >[(set_attr "move_type" "fmove") > + (set_attr "type" "fmove") > (set_attr "mode" "DF")]) > > (define_split > -- > 2.34.1 > >
Re: [PATCH 3/5] RISC-V: Add Types to Un-Typed Zicond Instructions
LGTM Edwin Lu 於 2023年9月7日 週四 01:53 寫道： > This patch creates a new "zicond" type and updates all zicond instructions > with that type. > > gcc/ChangeLog: > > * config/riscv/riscv.md: Add "zicond" type > * config/riscv/zicond.md: Update types > > Signed-off-by: Edwin Lu > --- > gcc/config/riscv/riscv.md | 5 +++-- > gcc/config/riscv/zicond.md | 8 > 2 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md > index 6684ad89cff..c329f55db43 100644 > --- a/gcc/config/riscv/riscv.md > +++ b/gcc/config/riscv/riscv.md > @@ -313,6 +313,7 @@ (define_attr "ext_enabled" "no,yes" > ;; cbocache block instructions > ;; crypto cryptography instructions > ;; csrcode size reduction instructions > +;; zicondzicond instructions > ;; Classification of RVV instructions which will be added to each RVV .md > pattern and used by scheduler. > ;; rdvlenb vector byte length vlenb csrr read > ;; rdvlvector length vl csrr read > @@ -422,8 +423,8 @@ (define_attr "type" > mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul, > fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip, > rotate,clmul,min,max,minu,maxu,clz,ctz,cpop, > - atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl, > - vlde,vste,vldm,vstm,vlds,vsts, > + atomic,condmove,cbo,crypto,csr,zicond,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm, > + vsetvl, vlde,vste,vldm,vstm,vlds,vsts, > vldux,vldox,vstux,vstox,vldff,vldr,vstr, > > vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff, > vialu,viwalu,vext,vicalu,vshift,vnshift,vicmp,viminmax, > diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md > index 1721e1011ea..0269bd14399 100644 > --- a/gcc/config/riscv/zicond.md > +++ b/gcc/config/riscv/zicond.md > @@ -30,7 +30,7 @@ (define_insn "*czero.." >(const_int 0)))] >"TARGET_ZICOND" >"czero.\t%0,%2,%1" > -) > +[(set_attr "type" "zicond")]) > > (define_insn "*czero.." >[(set (match_operand:GPR 0 "register_operand" "=r") > @@ -40,7 +40,7 @@ (define_insn "*czero.." >(match_operand:GPR 2 "register_operand" > "r")))] >"TARGET_ZICOND" >"czero.\t%0,%2,%1" > -) > +[(set_attr "type" "zicond")]) > > ;; Special optimization under eq/ne in primitive semantics > (define_insn "*czero.eqz..opt1" > @@ -51,7 +51,7 @@ (define_insn "*czero.eqz..opt1" >(match_operand:GPR 3 "register_operand" "r")))] >"TARGET_ZICOND && rtx_equal_p (operands[1], operands[2])" >"czero.eqz\t%0,%3,%1" > -) > +[(set_attr "type" "zicond")]) > > (define_insn "*czero.nez..opt2" >[(set (match_operand:GPR 0 "register_operand" "=r") > @@ -61,7 +61,7 @@ (define_insn "*czero.nez..opt2" >(match_operand:GPR 3 "register_operand" "1")))] >"TARGET_ZICOND && rtx_equal_p (operands[1], operands[3])" >"czero.eqz\t%0,%2,%1" > -) > +[(set_attr "type" "zicond")]) > > ;; Combine creates this form in some cases (particularly the coremark > ;; CRC loop. > -- > 2.34.1 > >
[Bug go/111310] BITINT_TYPE unsupported in godump.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111310 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Ian Lance Taylor --- Thanks, fixed.
Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes
On Thu, 7 Sept 2023 at 00:10, Jonathan Wakely wrote: > > On Thu, 7 Sept 2023 at 00:09, Hans-Peter Nilsson wrote: > > > > > From: Jonathan Wakely > > > Date: Wed, 6 Sep 2023 23:30:08 +0100 > > > > > On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely > > > wrote: > > > > > > > > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++ > > > > wrote: > > > > > > > > > > > Date: Fri, 1 Sep 2023 12:16:40 +0100 > > > > > > Reply-To: Jonathan Wakely > > > > > > > > > > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++ > > > > > > wrote: > > > > > > > > > > > > > > Any objections to this? It's a C++23 feture, so should be enabled > > > > > > > by > > > > > > > default. > > > > > > > > > > > > I've pushed this to trunk, so let's see what breaks! > > > > > > > > > > > > > > > > > > > > > > > > > > -- >8 -- > > > > > > > > > > > > > > This causes libstdc++_libbacktrace.a to be built by default. This > > > > > > > might > > > > > > > fail on some targets, in which case we can make the 'auto' choice > > > > > > > expand > > > > > > > to either 'yes' or 'no' depending on the target. > > > > > > > > > > > > > > libstdc++-v3/ChangeLog: > > > > > > > > > > > > > > * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes. > > > > > > > * configure: Regenerate. > > > > > > > > > > Incidentally, should check_effective_target_stacktrace in > > > > > libstdc++.exp also be adjusted to match; removing the > > > > > _GLIBCXX_HOSTED condition? > > > > > > > > No, it should still depend on is_hosted. The acinclude.m4 macro should > > > > check that. > > > > > > Done in r14-3761-g6de5f5a4fe85bd > > > > Aha, that's what you meant. I thought you meant that just > > check_effective_target_stacktrace should be gated on > > $is_hosted. > > > > Yeah, it makes sense not to have backtrace enabled by > > default for ! $is_hosted. On the other hand, bare-iron > > targets like cris-elf apparently *are* hosted, according to > > "#if __STDC_HOSTED__". I guess I'll have to dig into what > > the definition of "hosted" is, because I don't agree by the > > layman obvious definition. Maybe there's a bug to fix. > > I don't think there's a bug. $is_hosted is true for > --enable-hosted-libstdcxx which is on by default. And IIRC __STDC_HOSTED__ is defined unless you compile with -ffreestanding. > > > There sure are many yaks to shave these days. > > > > brgds, H-P > >
Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes
On Thu, 7 Sept 2023 at 00:09, Hans-Peter Nilsson wrote: > > > From: Jonathan Wakely > > Date: Wed, 6 Sep 2023 23:30:08 +0100 > > > On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely wrote: > > > > > > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++ > > > wrote: > > > > > > > > > Date: Fri, 1 Sep 2023 12:16:40 +0100 > > > > > Reply-To: Jonathan Wakely > > > > > > > > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++ > > > > > wrote: > > > > > > > > > > > > Any objections to this? It's a C++23 feture, so should be enabled by > > > > > > default. > > > > > > > > > > I've pushed this to trunk, so let's see what breaks! > > > > > > > > > > > > > > > > > > > > > > -- >8 -- > > > > > > > > > > > > This causes libstdc++_libbacktrace.a to be built by default. This > > > > > > might > > > > > > fail on some targets, in which case we can make the 'auto' choice > > > > > > expand > > > > > > to either 'yes' or 'no' depending on the target. > > > > > > > > > > > > libstdc++-v3/ChangeLog: > > > > > > > > > > > > * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes. > > > > > > * configure: Regenerate. > > > > > > > > Incidentally, should check_effective_target_stacktrace in > > > > libstdc++.exp also be adjusted to match; removing the > > > > _GLIBCXX_HOSTED condition? > > > > > > No, it should still depend on is_hosted. The acinclude.m4 macro should > > > check that. > > > > Done in r14-3761-g6de5f5a4fe85bd > > Aha, that's what you meant. I thought you meant that just > check_effective_target_stacktrace should be gated on > $is_hosted. > > Yeah, it makes sense not to have backtrace enabled by > default for ! $is_hosted. On the other hand, bare-iron > targets like cris-elf apparently *are* hosted, according to > "#if __STDC_HOSTED__". I guess I'll have to dig into what > the definition of "hosted" is, because I don't agree by the > layman obvious definition. Maybe there's a bug to fix. I don't think there's a bug. $is_hosted is true for --enable-hosted-libstdcxx which is on by default. > There sure are many yaks to shave these days. > > brgds, H-P >
Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes
> From: Jonathan Wakely > Date: Wed, 6 Sep 2023 23:30:08 +0100 > On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely wrote: > > > > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++ > > wrote: > > > > > > > Date: Fri, 1 Sep 2023 12:16:40 +0100 > > > > Reply-To: Jonathan Wakely > > > > > > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++ > > > > wrote: > > > > > > > > > > Any objections to this? It's a C++23 feture, so should be enabled by > > > > > default. > > > > > > > > I've pushed this to trunk, so let's see what breaks! > > > > > > > > > > > > > > > > > > -- >8 -- > > > > > > > > > > This causes libstdc++_libbacktrace.a to be built by default. This > > > > > might > > > > > fail on some targets, in which case we can make the 'auto' choice > > > > > expand > > > > > to either 'yes' or 'no' depending on the target. > > > > > > > > > > libstdc++-v3/ChangeLog: > > > > > > > > > > * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes. > > > > > * configure: Regenerate. > > > > > > Incidentally, should check_effective_target_stacktrace in > > > libstdc++.exp also be adjusted to match; removing the > > > _GLIBCXX_HOSTED condition? > > > > No, it should still depend on is_hosted. The acinclude.m4 macro should > > check that. > > Done in r14-3761-g6de5f5a4fe85bd Aha, that's what you meant. I thought you meant that just check_effective_target_stacktrace should be gated on $is_hosted. Yeah, it makes sense not to have backtrace enabled by default for ! $is_hosted. On the other hand, bare-iron targets like cris-elf apparently *are* hosted, according to "#if __STDC_HOSTED__". I guess I'll have to dig into what the definition of "hosted" is, because I don't agree by the layman obvious definition. Maybe there's a bug to fix. There sure are many yaks to shave these days. brgds, H-P
[Bug tree-optimization/111303] [14 Regression] ICE: in type, at value-range.h:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303 Andrew Pinski changed: What|Removed |Added Summary|ICE: in type, at|[14 Regression] ICE: in |value-range.h:869 |type, at value-range.h:869 Keywords||ice-on-valid-code Status|NEW |ASSIGNED Component|c |tree-optimization
[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311 --- Comment #2 from JuzheZhong --- All FAILS in this PR are not a big deal which will be easily addressed (except LTO). We should enable vect.exp tests which have full coverage of vector tests. But we are still have 2 real FAILS (current 46FAILS = 44 dump FAILs and 2 execution FAILs). https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628838.html I am waiting for those 2 real FAILS are fixed then merge that patch.
godump.cc patch committed: Handle _BitInt
This patch to godump.cc adds support for BITINT_TYPE. Bootstrapped
and ran godump and Go tests on x86_64-pc-linux-gnu. Committed to
mainline.
Ian
gcc/
PR go/111310
* godump.cc (go_format_type): Handle BITINT_TYPE.
gcc/testsuite/
PR go/111310
* gcc.misc-tests/godump-1.c: Add _BitInt test cases.
diff --git a/gcc/godump.cc b/gcc/godump.cc
index 0893d5fbc97..bdd2d108d76 100644
--- a/gcc/godump.cc
+++ b/gcc/godump.cc
@@ -760,6 +760,25 @@ go_format_type (class godump_container *container, tree
type,
}
break;
+case BITINT_TYPE:
+ {
+ const char *s;
+ char buf[100];
+
+ s = go_get_uinttype_for_precision (TYPE_PRECISION (type),
+ TYPE_UNSIGNED (type));
+ if (s == NULL)
+ {
+ snprintf (buf, sizeof buf, "INVALID-bitint-%u%s",
+ TYPE_PRECISION (type),
+ TYPE_UNSIGNED (type) ? "u" : "");
+ s = buf;
+ ret = false;
+ }
+ obstack_grow (ob, s, strlen(s));
+ }
+ break;
+
case REAL_TYPE:
{
const char *s;
diff --git a/gcc/testsuite/gcc.misc-tests/godump-1.c
b/gcc/testsuite/gcc.misc-tests/godump-1.c
index 95dabdc0e4c..f359a657827 100644
--- a/gcc/testsuite/gcc.misc-tests/godump-1.c
+++ b/gcc/testsuite/gcc.misc-tests/godump-1.c
@@ -234,6 +234,17 @@ const char cc_v1;
cc_t cc_v2;
/* { dg-final { scan-file godump-1.out "(?n)^var _cc_v2 _cc_t$" } } */
+_BitInt(32) b32_v;
+/* { dg-final { scan-file godump-1.out "(?n)^var _b32_v int32$" } } */
+
+_BitInt(64) b64_v;
+/* { dg-final { scan-file godump-1.out "(?n)^var _b64_v int64$" } } */
+
+unsigned _BitInt(32) b32u_v;
+/* { dg-final { scan-file godump-1.out "(?n)^var _b32u_v uint32$" } } */
+
+_BitInt(33) b33_v;
+/* { dg-final { scan-file godump-1.out "(?n)^// var _b33_v INVALID-bitint-33$"
} } */
/*** pointer and array types ***/
typedef void *vp_t;
[Bug go/111310] BITINT_TYPE unsupported in godump.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111310 --- Comment #1 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:e4775af423a590947a10429b9fa889f5d3d41d40 commit r14-3762-ge4775af423a590947a10429b9fa889f5d3d41d40 Author: Ian Lance Taylor Date: Wed Sep 6 15:09:31 2023 -0700 -fgo-dump-spec: support _BitInt gcc/ PR go/111310 * godump.cc (go_format_type): Handle BITINT_TYPE. gcc/testsuite/ PR go/111310 * gcc.misc-tests/godump-1.c: Add _BitInt test cases.
Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes
On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely wrote: > > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++ > wrote: > > > > > Date: Fri, 1 Sep 2023 12:16:40 +0100 > > > Reply-To: Jonathan Wakely > > > > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++ > > > wrote: > > > > > > > > Any objections to this? It's a C++23 feture, so should be enabled by > > > > default. > > > > > > I've pushed this to trunk, so let's see what breaks! > > > > > > > > > > > > > > -- >8 -- > > > > > > > > This causes libstdc++_libbacktrace.a to be built by default. This might > > > > fail on some targets, in which case we can make the 'auto' choice expand > > > > to either 'yes' or 'no' depending on the target. > > > > > > > > libstdc++-v3/ChangeLog: > > > > > > > > * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes. > > > > * configure: Regenerate. > > > > Incidentally, should check_effective_target_stacktrace in > > libstdc++.exp also be adjusted to match; removing the > > _GLIBCXX_HOSTED condition? > > No, it should still depend on is_hosted. The acinclude.m4 macro should > check that. Done in r14-3761-g6de5f5a4fe85bd
[committed] libstdc++: Disable support by default for freestanding
Tested x86_64-linux and x86_64-elf. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Disable by default
for freestanding.
* configure: Regenerate.
---
libstdc++-v3/acinclude.m4 | 2 +-
libstdc++-v3/configure| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 50c808c6b2d..b7210e09d89 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -5481,7 +5481,7 @@ BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS
-DBACKTRACE_ELF_SIZE=$elfsize"
AC_MSG_CHECKING([whether to build libbacktrace support])
if test "$enable_libstdcxx_backtrace" = "auto"; then
-enable_libstdcxx_backtrace=yes
+enable_libstdcxx_backtrace="$is_hosted"
fi
AC_MSG_RESULT($enable_libstdcxx_backtrace)
if test "$enable_libstdcxx_backtrace" = "yes"; then
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index db1932300c0..dcb9fd6158c 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -73156,7 +73156,7 @@ BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS
-DBACKTRACE_ELF_SIZE=$elfsize"
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to build
libbacktrace support" >&5
$as_echo_n "checking whether to build libbacktrace support... " >&6; }
if test "$enable_libstdcxx_backtrace" = "auto"; then
-enable_libstdcxx_backtrace=yes
+enable_libstdcxx_backtrace="$is_hosted"
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$enable_libstdcxx_backtrace" >&5
$as_echo "$enable_libstdcxx_backtrace" >&6; }
--
2.41.0
[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311 --- Comment #1 from JuzheZhong --- Except the known issue (LTO issue). All other issues are either bugus FAILS or very simple bugs. Fixing them just need a few days (maybe 2 ~ 3days). I will fix them first before sending new feature patches and the future new patches should always pass all regression tests with enablig vector extension.
Re: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]
On Mon, 28 Aug 2023, Jason Merrill wrote:
> On 8/24/23 09:31, Patrick Palka wrote:
> > On Wed, 23 Aug 2023, Jason Merrill wrote:
> >
> > > On 8/21/23 21:51, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
> > > > a reasonable approach? I didn't observe any compile time/memory impact
> > > > of this change.
> > > >
> > > > -- >8 --
> > > >
> > > > As described in detail in the PR, CWG 2369 has the surprising
> > > > consequence of introducing constraint recursion in seemingly valid and
> > > > innocent code.
> > > >
> > > > This patch attempts to fix this surpising behavior for the majority
> > > > of problematic use cases. Rather than checking satisfaction before
> > > > _all_ non-dependent conversions, as specified by the CWG issue,
> > > > this patch makes us first check "safe" non-dependent conversions,
> > > > then satisfaction, then followed by "unsafe" non-dependent conversions.
> > > > In this case, a conversion is "safe" if computing it is guaranteed
> > > > to not induce template instantiation. This patch heuristically
> > > > determines "safety" by checking for a constructor template or conversion
> > > > function template in the (class) parm or arg types respectively.
> > > > If neither type has such a member, then computing the conversion
> > > > should not induce instantiation (modulo satisfaction checking of
> > > > non-template constructor and conversion functions I suppose).
> > > >
> > > > + /* We're checking only non-instantiating conversions.
> > > > +A conversion may instantiate only if it's to/from a
> > > > +class type that has a constructor template/conversion
> > > > +function template. */
> > > > + tree parm_nonref = non_reference (parm);
> > > > + tree type_nonref = non_reference (type);
> > > > +
> > > > + if (CLASS_TYPE_P (parm_nonref))
> > > > + {
> > > > + if (!COMPLETE_TYPE_P (parm_nonref)
> > > > + && CLASSTYPE_TEMPLATE_INSTANTIATION (parm_nonref))
> > > > + return unify_success (explain_p);
> > > > +
> > > > + tree ctors = get_class_binding (parm_nonref,
> > > > + complete_ctor_identifier);
> > > > + for (tree ctor : lkp_range (ctors))
> > > > + if (TREE_CODE (ctor) == TEMPLATE_DECL)
> > > > + return unify_success (explain_p);
> > >
> > > Today we discussed maybe checking CLASSTYPE_NON_AGGREGATE?
> >
> > Done; all dups of this PR seem to use tag types that are aggregates, so this
> > seems like a good simplification. I also made us punt if the arg type has a
> > constrained non-template conversion function.
> >
> > >
> > > Also, instantiation can also happen when checking for conversion to a
> > > pointer
> > > or reference to base class.
> >
> > Oops, I suppose we just need to strip pointer types upfront as well. The
> > !COMPLETE_TYPE_P && CLASSTYPE_TEMPLATE_INSTANTIATION tests will then make
> > sure we deem a potential derived-to-base conversion unsafe if appropriate
> > IIUC.
> >
> > How does the following look?
> >
> > -- >8 --
> >
> > Subject: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs
> > [PR99599]
> >
> > PR c++/99599
> >
> > gcc/cp/ChangeLog:
> >
> > * config-lang.in (gtfiles): Add search.cc.
> > * pt.cc (check_non_deducible_conversions): Add bool parameter
> > passed down to check_non_deducible_conversion.
> > (fn_type_unification): Call check_non_deducible_conversions
> > an extra time before satisfaction with noninst_only_p=true.
> > (check_non_deducible_conversion): Add bool parameter controlling
> > whether to compute only conversions that are guaranteed to
> > not induce template instantiation.
> > * search.cc (conversions_cache): Define.
> > (lookup_conversions): Use it to cache the lookup. Improve cache
> > rate by considering TYPE_MAIN_VARIANT of the type.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/cpp2a/concepts-nondep4.C: New test.
> > ---
> > gcc/cp/config-lang.in | 1 +
> > gcc/cp/pt.cc | 81 +--
> > gcc/cp/search.cc | 14 +++-
> > gcc/testsuite/g++.dg/cpp2a/concepts-nondep4.C | 21 +
> > 4 files changed, 110 insertions(+), 7 deletions(-)
> > create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-nondep4.C
> >
> > @@ -22921,6 +22933,65 @@ check_non_deducible_conversion (tree parm, tree
> > arg, unification_kind_t strict,
> > {
> > bool ok = false;
> > tree conv_arg = TYPE_P (arg) ? NULL_TREE : arg;
> > + if (conv_p && *conv_p)
> > + {
> > + /* This conversion was already computed earlier (when
> > +computing only non-instantiating conversions). */
> > + gcc_checking_assert (!noninst_only_p);
> > + return unify_success
[PATCH] c++: cache conversion function lookup
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? This cache apparently has a 98% hit rate for TYPE_HAS_CONVERSION
types on some test files.
-- >8 --
gcc/cp/ChangeLog:
* config-lang.in (gtfiles): Add search.cc.
* search.cc (lookup_conversions_cache): Define.
(lookup_conversions): Use it to cache he lookup.
Improve cache rate by considering TYPE_MAIN_VARIANT
of the type.
---
gcc/cp/config-lang.in | 1 +
gcc/cp/search.cc | 11 +++
2 files changed, 12 insertions(+)
diff --git a/gcc/cp/config-lang.in b/gcc/cp/config-lang.in
index a6c7883cc24..e34c392d208 100644
--- a/gcc/cp/config-lang.in
+++ b/gcc/cp/config-lang.in
@@ -52,6 +52,7 @@ gtfiles="\
\$(srcdir)/cp/name-lookup.cc \
\$(srcdir)/cp/parser.cc \$(srcdir)/cp/pt.cc \
\$(srcdir)/cp/rtti.cc \
+\$(srcdir)/cp/search.cc \
\$(srcdir)/cp/semantics.cc \
\$(srcdir)/cp/tree.cc \$(srcdir)/cp/typeck2.cc \
\$(srcdir)/cp/vtable-class-hierarchy.cc \
diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
index cd80f285ac9..d5a2c57f59c 100644
--- a/gcc/cp/search.cc
+++ b/gcc/cp/search.cc
@@ -2582,6 +2582,10 @@ lookup_conversions_r (tree binfo, int virtual_depth, int
virtualness,
return my_virtualness;
}
+/* A cache of the result of lookup_conversions. */
+
+static GTY((cache)) type_tree_cache_map *lookup_conversions_cache;
+
/* Return a TREE_LIST containing all the non-hidden user-defined
conversion functions for TYPE (and its base-classes). The
TREE_VALUE of each node is the FUNCTION_DECL of the conversion
@@ -2596,10 +2600,14 @@ lookup_conversions (tree type)
{
tree convs;
+ type = TYPE_MAIN_VARIANT (type);
complete_type (type);
if (!CLASS_TYPE_P (type) || !TYPE_BINFO (type))
return NULL_TREE;
+ if (tree *c = hash_map_safe_get (lookup_conversions_cache, type))
+return *c;
+
lookup_conversions_r (TYPE_BINFO (type), 0, 0, NULL_TREE, NULL_TREE, );
tree list = NULL_TREE;
@@ -2618,6 +2626,7 @@ lookup_conversions (tree type)
}
}
+ hash_map_safe_put (lookup_conversions_cache, type, list);
return list;
}
@@ -2798,3 +2807,5 @@ any_dependent_bases_p (tree type)
return false;
}
+
+#include "gt-cp-search.h"
--
2.42.0.122.g1fc548b2d6
Re: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]
On Mon, 28 Aug 2023, Jason Merrill wrote:
> On 8/24/23 09:31, Patrick Palka wrote:
> > On Wed, 23 Aug 2023, Jason Merrill wrote:
> >
> > > On 8/21/23 21:51, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
> > > > a reasonable approach? I didn't observe any compile time/memory impact
> > > > of this change.
> > > >
> > > > -- >8 --
> > > >
> > > > As described in detail in the PR, CWG 2369 has the surprising
> > > > consequence of introducing constraint recursion in seemingly valid and
> > > > innocent code.
> > > >
> > > > This patch attempts to fix this surpising behavior for the majority
> > > > of problematic use cases. Rather than checking satisfaction before
> > > > _all_ non-dependent conversions, as specified by the CWG issue,
> > > > this patch makes us first check "safe" non-dependent conversions,
> > > > then satisfaction, then followed by "unsafe" non-dependent conversions.
> > > > In this case, a conversion is "safe" if computing it is guaranteed
> > > > to not induce template instantiation. This patch heuristically
> > > > determines "safety" by checking for a constructor template or conversion
> > > > function template in the (class) parm or arg types respectively.
> > > > If neither type has such a member, then computing the conversion
> > > > should not induce instantiation (modulo satisfaction checking of
> > > > non-template constructor and conversion functions I suppose).
> > > >
> > > > + /* We're checking only non-instantiating conversions.
> > > > +A conversion may instantiate only if it's to/from a
> > > > +class type that has a constructor template/conversion
> > > > +function template. */
> > > > + tree parm_nonref = non_reference (parm);
> > > > + tree type_nonref = non_reference (type);
> > > > +
> > > > + if (CLASS_TYPE_P (parm_nonref))
> > > > + {
> > > > + if (!COMPLETE_TYPE_P (parm_nonref)
> > > > + && CLASSTYPE_TEMPLATE_INSTANTIATION (parm_nonref))
> > > > + return unify_success (explain_p);
> > > > +
> > > > + tree ctors = get_class_binding (parm_nonref,
> > > > + complete_ctor_identifier);
> > > > + for (tree ctor : lkp_range (ctors))
> > > > + if (TREE_CODE (ctor) == TEMPLATE_DECL)
> > > > + return unify_success (explain_p);
> > >
> > > Today we discussed maybe checking CLASSTYPE_NON_AGGREGATE?
> >
> > Done; all dups of this PR seem to use tag types that are aggregates, so this
> > seems like a good simplification. I also made us punt if the arg type has a
> > constrained non-template conversion function.
> >
> > >
> > > Also, instantiation can also happen when checking for conversion to a
> > > pointer
> > > or reference to base class.
> >
> > Oops, I suppose we just need to strip pointer types upfront as well. The
> > !COMPLETE_TYPE_P && CLASSTYPE_TEMPLATE_INSTANTIATION tests will then make
> > sure we deem a potential derived-to-base conversion unsafe if appropriate
> > IIUC.
> >
> > How does the following look?
> >
> > -- >8 --
> >
> > Subject: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs
> > [PR99599]
> >
> > PR c++/99599
> >
> > gcc/cp/ChangeLog:
> >
> > * config-lang.in (gtfiles): Add search.cc.
> > * pt.cc (check_non_deducible_conversions): Add bool parameter
> > passed down to check_non_deducible_conversion.
> > (fn_type_unification): Call check_non_deducible_conversions
> > an extra time before satisfaction with noninst_only_p=true.
> > (check_non_deducible_conversion): Add bool parameter controlling
> > whether to compute only conversions that are guaranteed to
> > not induce template instantiation.
> > * search.cc (conversions_cache): Define.
> > (lookup_conversions): Use it to cache the lookup. Improve cache
> > rate by considering TYPE_MAIN_VARIANT of the type.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/cpp2a/concepts-nondep4.C: New test.
> > ---
> > gcc/cp/config-lang.in | 1 +
> > gcc/cp/pt.cc | 81 +--
> > gcc/cp/search.cc | 14 +++-
> > gcc/testsuite/g++.dg/cpp2a/concepts-nondep4.C | 21 +
> > 4 files changed, 110 insertions(+), 7 deletions(-)
> > create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-nondep4.C
> >
> > @@ -22921,6 +22933,65 @@ check_non_deducible_conversion (tree parm, tree
> > arg, unification_kind_t strict,
> > {
> > bool ok = false;
> > tree conv_arg = TYPE_P (arg) ? NULL_TREE : arg;
> > + if (conv_p && *conv_p)
> > + {
> > + /* This conversion was already computed earlier (when
> > +computing only non-instantiating conversions). */
> > + gcc_checking_assert (!noninst_only_p);
> > + return unify_success
[Bug analyzer/110520] -Wanalyzer-null-dereference false nagetive with `*ptr = 10086`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110520 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-06 --- Comment #1 from David Malcolm --- Thanks for filing this bug. With trunk (for gcc 14) I correctly get a NPD warning (true positive): https://godbolt.org/z/a5h38cz7d With gcc 13.2, I don't (false negative): https://godbolt.org/z/PKnToYK8v I've been rewriting C string handling for gcc 14, so it's likely this now working is a side-effect of that. Keeping open to track adding a regression test for this.
[Bug analyzer/111095] -Wanalyzer-out-of-bounds false negative with `return l_1322[9];` at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111095 --- Comment #2 from David Malcolm --- (In reply to David Malcolm from comment #1) [...] > I'll open a bug about that. Filed as bug 111312; made this one block that one.
[Bug analyzer/111213] -Wanalyzer-out-of-bounds false negative with `return arr[9];` at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111213 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-09-06 Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- (In reply to David Malcolm from comment #1) [...] > If that's the case, that's a strong argument that the analyzer should run > earlier. I'm not sure if we have an existing bug about that. Filed as bug 111312; made this one block that one.
[Bug analyzer/111312] New: Should the analyzer run earlier?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111312
Bug ID: 111312
Summary: Should the analyzer run earlier?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Blocks: 111095, 111213
Target Milestone: ---
I made the analyzer run when it does in order to take advantage of the LTO
streaming representation.
But:
I'm having to recommend disabling optimizations for various -fanalyzer
warnings:
* -Wanalyzer-deref-before-check
* -Wanalyzer-infinite-recursion
* -Wanalyzer-tainted-assertion
and eventually:
* -Wanalyzer-infinite-loop (work-in-progess; see bug 106147)
Also, various bugs are showing up where the analyzer fails to warn on clearly
wrong code (presumably due to the optimizer removing code containing undefined
behavior before the analyzer ever sees it; see e.g. bug 111095 and bug 111213).
Also: there's a tension between warnings and optimization: the optimizer takes
advantage of undefined behavior (assuming it's not present), but we want to
complain about the presence of undefined behavior.
Plus it's better to report things to the user in a form closer to that in which
they wrote the code.
When should we run?
* immediately after we reach "generic"
* could give us per-argument locations at call sites
* once we're in gimple-cfg (but no ssa?)
* once we're in gimple-ssa
Costs/Benefits of running at different times
* is inlining saving us?
* do we want to use the callgraph?
* do we want to use the loop information? (see bug 109252)
* do we want to use ranger? (need SSA)
* do we want to use the CFGs?
* do we want to reuse ipa-devirt?
* presumably we don't want to reimplement lowering of OpenMP, exceptions, etc
* PR analyzer/100116 ("analyzer event messages for conditionals have the
sense of the gimple IR rather than the source")
We're not currently analyzing the user's code, we're analyzing the user's code
after the optimizer has manipulated it, taking advantage of undefined behavior.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111095
[Bug 111095] -Wanalyzer-out-of-bounds false negative with `return l_1322[9];`
at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111213
[Bug 111213] -Wanalyzer-out-of-bounds false negative with `return arr[9];` at
-O1 and above
[Bug analyzer/111095] -Wanalyzer-out-of-bounds false negative with `return l_1322[9];` at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111095 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|-Wanalyzer-out-of-bounds|-Wanalyzer-out-of-bounds |false negative with `return |false negative with `return |l_1322[9];` |l_1322[9];` at -O1 and ||above Last reconfirmed||2023-09-06 --- Comment #1 from David Malcolm --- Thanks for filing this bug. This looks similar to bug 111213. Adding -fdump-ipa-analyzer=stderr shows that at -O1 and above, the entire body of the function is optimized away before the analyzer even sees it (presumably due to undefined behavior). My hypothesis is that the optimizer sees the undefined behavior and optimizes the function away (but I haven't checked the details). If that's the case, that's a strong argument that the analyzer should run earlier. I'll open a bug about that.
[Bug target/111311] New: RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable
ill-4.c check-function-bodies spill_5 UNRESOLVED: gcc.target/riscv/rvv/base/spill-4.c check-function-bodies spill_6 UNRESOLVED: gcc.target/riscv/rvv/base/spill-4.c check-function-bodies spill_7 FAIL: gcc.target/riscv/rvv/base/spill-5.c (internal compiler error: in partial_subreg_p, at rtl.h:3186) FAIL: gcc.target/riscv/rvv/base/spill-5.c (test for excess errors) UNRESOLVED: gcc.target/riscv/rvv/base/spill-5.c check-function-bodies spill_3 UNRESOLVED: gcc.target/riscv/rvv/base/spill-5.c check-function-bodies spill_4 UNRESOLVED: gcc.target/riscv/rvv/base/spill-5.c check-function-bodies spill_5 UNRESOLVED: gcc.target/riscv/rvv/base/spill-5.c check-function-bodies spill_6 UNRESOLVED: gcc.target/riscv/rvv/base/spill-5.c check-function-bodies spill_7 FAIL: gcc.target/riscv/rvv/base/spill-6.c (internal compiler error: in partial_subreg_p, at rtl.h:3186) FAIL: gcc.target/riscv/rvv/base/spill-6.c (test for excess errors) UNRESOLVED: gcc.target/riscv/rvv/base/spill-6.c check-function-bodies spill_4 UNRESOLVED: gcc.target/riscv/rvv/base/spill-6.c check-function-bodies spill_5 UNRESOLVED: gcc.target/riscv/rvv/base/spill-6.c check-function-bodies spill_6 UNRESOLVED: gcc.target/riscv/rvv/base/spill-6.c check-function-bodies spill_7 FAIL: gcc.target/riscv/rvv/base/spill-sp-adjust.c (internal compiler error: in partial_subreg_p, at rtl.h:3186) FAIL: gcc.target/riscv/rvv/base/spill-sp-adjust.c (test for excess errors) UNRESOLVED: gcc.target/riscv/rvv/base/spill-sp-adjust.c scan-assembler-not addi\\tsp,sp,0 FAIL: gcc.target/riscv/rvv/base/vector-abi-4.c (test for bogus messages, line 9) === gcc Summary === # of expected passes180698 # of unexpected failures716 # of unexpected successes 7 # of expected failures 1257 # of unresolved testcases 442 # of unsupported tests 3412 /home/rdapp/projects/gcc/build/gcc/xgcc version 14.0.0 20230906 (experimental) (GCC) Host is x86_64-pc-linux-gnu === g++ tests === Running target unix/-march=rv64gcv/--param=riscv-autovec-preference=scalable WARNING: Assuming target board is the local machine (which is probably wrong). FAIL: c-c++-common/opaque-vector.c -std=c++14 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/opaque-vector.c -std=c++14 (test for excess errors) FAIL: c-c++-common/opaque-vector.c -std=c++17 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/opaque-vector.c -std=c++17 (test for excess errors) FAIL: c-c++-common/opaque-vector.c -std=c++20 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/opaque-vector.c -std=c++20 (test for excess errors) FAIL: c-c++-common/opaque-vector.c -std=c++98 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/opaque-vector.c -std=c++98 (test for excess errors) FAIL: c-c++-common/pr105998.c -std=c++14 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/pr105998.c -std=c++14 (test for excess errors) FAIL: c-c++-common/pr105998.c -std=c++17 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/pr105998.c -std=c++17 (test for excess errors) FAIL: c-c++-common/pr105998.c -std=c++20 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/pr105998.c -std=c++20 (test for excess errors) FAIL: c-c++-common/pr105998.c -std=c++98 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/pr105998.c -std=c++98 (test for excess errors) FAIL: c-c++-common/scal-to-vec2.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/scal-to-vec2.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/scal-to-vec2.c -std=gnu++20 (test for excess errors) FAIL: c-c++-common/scal-to-vec2.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/spec-barrier-1.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/spec-barrier-1.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/spec-barrier-1.c -std=gnu++20 (test for excess errors) FAIL: c-c++-common/spec-barrier-1.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/vector-compare-1.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/vector-compare-1.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/vector-compare-1.c -std=gnu++20 (test for excess errors) FAIL: c-c++-common/vector-compare-1.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/vector-compare-2.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/vector-compare-2.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/vector-compare-2.c -std=gnu++20 (test for excess errors) FAIL: c-c++-common/vector-compare-2.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/vector-scalar.c -std=c++14 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/vector-scalar.c -std=c++14 (test for exc
Re: [C PATCH 1/6] c: reorganize recursive type checking
On Sat, 26 Aug 2023, Martin Uecker via Gcc-patches wrote: > -static int > +static bool > comp_target_types (location_t location, tree ttl, tree ttr) The comment above this function should be updated to refer to returning true, not to returning 1. And other comments on common_pointer_type and inside that function should be updated to refer to comp_target_types returning true, not nonzero. > @@ -1395,17 +1382,13 @@ free_all_tagged_tu_seen_up_to (const struct > tagged_tu_seen_cache *tu_til) > > /* Return 1 if two 'struct', 'union', or 'enum' types T1 and T2 are > compatible. If the two types are not the same (which has been > - checked earlier), this can only happen when multiple translation > - units are being compiled. See C99 6.2.7 paragraph 1 for the exact > - rules. ENUM_AND_INT_P and DIFFERENT_TYPES_P are as in > - comptypes_internal. */ > + checked earlier). */ > > -static int > +static bool > tagged_types_tu_compatible_p (const_tree t1, const_tree t2, > - bool *enum_and_int_p, bool *different_types_p) > + struct comptypes_data* data) Similarly, this comment should be updated for the new return type. Also the GNU style is "struct comptypes_data *data" with space before not after '*'. > @@ -1631,9 +1603,9 @@ tagged_types_tu_compatible_p (const_tree t1, const_tree > t2, > Otherwise, the argument types must match. > ENUM_AND_INT_P and DIFFERENT_TYPES_P are as in comptypes_internal. */ > > -static int > +static bool > function_types_compatible_p (const_tree f1, const_tree f2, > - bool *enum_and_int_p, bool *different_types_p) > + struct comptypes_data *data) Another comment to update for a changed return type. > /* Check two lists of types for compatibility, returning 0 for > - incompatible, 1 for compatible, or 2 for compatible with > - warning. ENUM_AND_INT_P and DIFFERENT_TYPES_P are as in > - comptypes_internal. */ > + incompatible, 1 for compatible. ENUM_AND_INT_P and > + DIFFERENT_TYPES_P are as in comptypes_internal. */ > > -static int > +static bool > type_lists_compatible_p (const_tree args1, const_tree args2, > - bool *enum_and_int_p, bool *different_types_p) > + struct comptypes_data *data) This one also needs updating to remove references to parameters that no longer exist. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.
Robin Dapp writes: > Hi Richard, > > I did some testing with the attached v2 that does not restrict to UNARY > anymore. As feared ;) there is some more fallout that I'm detailing below. > > On Power there is one guality fail (pr43051-1.c) that I would take > the liberty of ignoring for now. > > On x86 there are four fails: > > - cond_op_addsubmuldiv__Float16-2.c: assembler error >unsupported masking for `vmovsh'. I guess that's a latent backend >problem. > > - ifcvt-3.c, pr49095.c: Here we propagate into a compare. Before, we had >(cmp (reg/CC) 0) and now we have (cmp (plus (reg1 reg2) 0). >That looks like a costing problem and can hopefully solveable by making >the second compare more expensive, preventing the propagation. >i386 costing (or every costing?) is brittle so that could well break other >things. > > - pr88873.c: This is interesting because even before this patch we >propagated with different register classes (V2DF vs DI). With the patch >we check the register pressure, find the class NO_REGS for V2DF and >abort (because the patch assumes NO_REGS = high pressure). I'm thinking >of keeping the old behavior for reg-reg propagations and only checking >the pressure for more complex operations. > > aarch64 has the most fails: > > - One guality fail (same as Power). > - shrn-combine-[123].c as before. > > - A class of (hopefully, I only checked some) similar cases where we >propagate an unspec_whilelo into an unspec_ptest. Before we would only >set a REG_EQUALS note. >Before we managed to create a while_ultsivnx16bi_cc whereas now we have >while_ultsivnx16bi and while_ultsivnx16bi_ptest that won't be combined. >We create redundant whilelos and I'm not sure how to improve that. I >guess a peephole is out of the question :) > > - pred-combine-and.c: Here the new propagation appears useful at first. >We propagate a "vector mask and" into a while_ultsivnx4bi_ptest and the >individual and registers remain live up to the propagation site (while >being dead before the patch). >With the registers dead, combine could create a single fcmgt before. >Now it only manages a 2->2 combination because we still need the registers >and end up with two fcmgts. >The code is worse but this seems more bad luck than anything. > > - Addressing fails from before: I looked into these and suspect all of >them are a similar. >What happens is that we have a poly_int offset that we shift, negate >and then add to x0. The result is used as load address. >Before, we would pull (combine) the (plus x0 reg) into the load keeping >the neg and shift. >Now we propagate everything into a single (set (minus x0 offset)). >The propagation itself seems worthwhile because we save one insn. >However as we got rid of the base/offset split by lumping everything >together, combine cannot pull the (plus) into the address load and >we require an aarch64_split_add_offset. This will emit the longer >sequence of ashiftl and subtract. The "base" address is x0 here so >we cannot convert (minus x0 ...)) into neg. >I didn't go through all of aarch64_split_add_offset. I suppose we >could re-add the separation of base/offset there but that might be >a loss when the result is not used as an address. > > Again, all in all no fatal problems but pretty annoying :) It's not much > but just gradually worse than with just UNARY. Any idea on how/whether to > continue? Thanks for giving it a go. Can you post the latest version of the regpressure patch too? The previous on-list version I could find seems to be too old. Thanks, Richard > Regards > Robin > > gcc/ChangeLog: > > * fwprop.cc (fwprop_propagation::profitable_p): Add unary > handling. > (fwprop_propagation::update_register_pressure): New function. > (fwprop_propagation::register_pressure_high_p): New function > (reg_single_def_for_src_p): Look through unary expressions. > (try_fwprop_subst_pattern): Check register pressure. > (forward_propagate_into): Call new function. > (fwprop_init): Init register pressure. > (fwprop_done): Clean up register pressure. > (fwprop_insn): Add comment. > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/rvv/autovec/binop/vadd-vx-fwprop.c: New test. > --- > gcc/fwprop.cc | 359 +- > .../riscv/rvv/autovec/binop/vadd-vx-fwprop.c | 64 > 2 files changed, 419 insertions(+), 4 deletions(-) > create mode 100644 > gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-vx-fwprop.c > > diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc > index 0707a234726..ce6f5a74b00 100644 > --- a/gcc/fwprop.cc > +++ b/gcc/fwprop.cc > @@ -36,6 +36,10 @@ along with GCC; see the file COPYING3. If not see > #include "tree-pass.h" > #include "rtl-iter.h" > #include "target.h" > +#include "dominance.h"
Re: [PATCH v2] analyzer: Call off a superseding when diagnostics are unrelated [PR110830]
On Wed, 2023-09-06 at 21:16 +0200, priour...@gmail.com wrote:
[...snip...]
> Signed-off-by: benjamin priour
> Co-authored-by: david malcolm
Please also add:
Signed-off-by: David Malcolm
[...snip...]
>
> +static bool
> +compatible_epath_p (const exploded_path *lhs_path,
> + const exploded_path *rhs_path)
> +{
> + gcc_assert (lhs_path);
> + gcc_assert (rhs_path);
> + gcc_assert (rhs_path->length () > 0);
> + gcc_assert (rhs_path->length () > 0);
> + int lhs_eedge_idx = lhs_path->length () -1;
> + int rhs_eedge_idx = rhs_path->length () -1;
Minor formatting nit: there should be a space between the '-' and the
'1' in the above lines, hence:
int lhs_eedge_idx = lhs_path->length () - 1;
int rhs_eedge_idx = rhs_path->length () - 1;
[...snip...]
OK for trunk with those changes
Thanks
Dave
Re: [PATCH] analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]
On Wed, 2023-09-06 at 15:50 +0200, Benjamin Priour wrote:
> Hi David,
> Thanks for the review.
>
>
>
> On Tue, Sep 5, 2023 at 1:53 PM David Malcolm
> wrote:
>
> > On Mon, 2023-09-04 at 20:00 +0200, priour...@gmail.com wrote:
> >
> >
> [...snip...]
>
>
> > All of these "new" tests (apart from the "-noexcept" ones) look
> > like
> > they're meant to be existing tests that were moved, but where the
> > copy
> > of the test in gcc.dg/analyzer didn't get deleted, so they show up
> > as a
> > duplicate. See the details below.
> >
>
> > > * c-c++-common/analyzer/file-pr58237-noexcept.c: New test.
> >
> > When duplicating a test like this, the test isn't entirely "new",
> > so
> > please say something like this in the ChangeLog entry, to make it
> > clear
> > where it came from:
> >
> >
> I actually wasn't sure about these -noexcept tests. They were part
> of gcc.dg/analyzer, thus only gcc was running them. Exceptions
> were not disabled *explicitly*, but since it was C, they weren't
> enabled
> either.
>
> Therefore, the -noexcept tests are basically a copy, but with an
> explicit
> -fno-exceptions specification.
> When I duplicated them in that way I was thinking about making it
> clear
> that these tests fail in C++ with exceptions enabled, so that we
> would
> already
> have easy-to-spot failing tests to challenge a future exception
> support.
Ah, OK; let's go with your approach.
>
> Though perhaps *not* duplicating the tests but rather simply specify
> -fno-exceptions,
> with a comment "Fails with exceptions" may be better.
[...snip...]
> > > @@ -45,7 +45,7 @@ void test(int n)
> > > struct iter *it = iter_new (0, n, 1);
> > > while (!iter_done_p (it))
> > > {
> > > - __analyzer_eval (it->val < n); /* { dg-warning "TRUE"
> > > "true" {
> > xfail *-*-* } } */
> > > + __analyzer_eval (it->val < n); /* { dg-warning "TRUE"
> > > "true" } */
> > > /* { dg-bogus "UNKNOWN" "unknown" { xfail *-*-* } .-1 } */
> > > /* TODO(xfail^^^): ideally we ought to figure out i > 0
> > > after 1st
> > iteration. */
> > >
> >
> > Presumably due to the change to
> > region_model::add_constraints_from_binop, right?
> > Looking at that dg-bogus "UNKNOWN", do we still get an UNKNOWN
> > here, or
> > can that line be removed?
> > If so, then the 3rd comment can presumably become:
> >
> >
> The bogus here still make sense - without it there is an excess error
> -.
> I had checked for it because I too thought it could be removed.
> If I remember it correctly, we get UNKNOWN during the widening pass.
(nods)
>
>
> > > /* TODO: ideally we ought to figure out i > 0 after 1st
> > iteration. */
> >
> > [...snip...]
> >
> >
> >
> [...snip...]
>
> Thanks for spotting the files I forgot to remove from gcc.dg.
> Sorry about them, I had messed up my test folder when checking for
> arm-eabi,
> and I apparently missed some duplicates when retrieving my save.
>
> As for the files the likes of inlining-*.c, i.e. noted as Moved
> to/...here.
> at the end of the ChangeLog, some tests checking for multiline
> outputs
> are so heavily rewritten than git marks them as Removed/New test
> instead of moved. I've manually edited that, but perhaps I shouldn't
> ?
>
> I have successfully regstrapped the improvements you suggested.
Thanks. Did you want me to doublecheck the updated patch? Otherwise
feel free to push it to trunk.
> Part 3 of this serie of patches I hope will be regstrapped for
> Friday.
Thanks; I'm impressed at how much progress you've made on this problem.
Dave
Re: [PATCH 01/13] [APX EGPR] middle-end: Add insn argument to base_reg_class
On 9/1/23 05:07, Hongyu Wang wrote: Uros Bizjak via Gcc-patches 于2023年8月31日周四 18:16写道： On Thu, Aug 31, 2023 at 10:20 AM Hongyu Wang wrote: From: Kong Lingling Current reload infrastructure does not support selective base_reg_class for backend insn. Add insn argument to base_reg_class for lra/reload usage. I don't think this is the correct approach. Ideally, a memory constraint should somehow encode its BASE/INDEX register class. Instead of passing "insn", simply a different constraint could be used in the constraint string of the relevant insn. We tried constraint only at the beginning, but then we found the reload infrastructure does not work like that. The BASE/INDEX reg classes are determined before choosing alternatives, in process_address under curr_insn_transform. Process_address creates the mem operand according to the BASE/INDEX reg class. Then, the memory operand constraint check will evaluate the mem op with targetm.legitimate_address_p. If we want to make use of EGPR in base/index we need to either extend BASE/INDEX reg class in the backend, or, for specific insns, add a target hook to tell reload that the extended reg class with EGPR can be used to construct memory operand. CC'd Vladimir as git send-mail failed to add recipient. I think the approach proposed by Intel developers is better. In some way we already use such approach when we pass memory mode to get the base reg class. Although we could use different memory constraints for different modes when the possible base reg differs for some memory modes. Using special memory constraints probably can be implemented too (I understand attractiveness of such approach for readability of the machine description). But in my opinion it will require much bigger work in IRA/LRA/reload. It also significantly slow down RA as we need to process insn constraints for processing each memory in many places (e.g. for calculation of reg classes and costs in IRA). Still I think there will be a few cases for this approach resulting in a bigger probability of assigning hard reg out of specific base reg class and this will result in additional reloads. So the approach proposed by Intel is ok for me. Although if x86 maintainers are strongly against this approach and the changes in x86 machine dependent code and Intel developers implement Uros approach, I am ready to review this. But still I prefer the current Intel developers approach for reasons I mentioned above.
[Bug go/111310] New: BITINT_TYPE unsupported in godump.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111310 Bug ID: 111310 Summary: BITINT_TYPE unsupported in godump.cc Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: go Assignee: ian at airs dot com Reporter: pinskia at gcc dot gnu.org CC: adam.warner.nz at gmail dot com, alx at kernel dot org, bergner at gcc dot gnu.org, charlet at gcc dot gnu.org, chfast at gmail dot com, dje at gcc dot gnu.org, dkm at gcc dot gnu.org, ebotcazou at gcc dot gnu.org, fw at gcc dot gnu.org, george at bott dot gg, hjl.tools at gmail dot com, jakub at gcc dot gnu.org, jsm28 at gcc dot gnu.org, leni536 at gmail dot com, rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org, segher at gcc dot gnu.org, sjames at gcc dot gnu.org, tmgross at umich dot edu, unassigned at gcc dot gnu.org, uweigand at gcc dot gnu.org Depends on: 102989, 111308 Target Milestone: --- +++ This bug was initially created as a clone of Bug #111308 +++ +++ This bug was initially created as a clone of Bug #102989 +++ BITINT_TYPE support to godump.cc, as I have no idea what you want to do in go for that. Example of problematic declaration in some header (so far on x86-64) would be extern _BitInt(157) foo (unsigned _BitInt(384) x, signed _BitInt(15) y, int z); Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 [Bug 102989] Implement C2x's n2763 (_BitInt) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111308 [Bug 111308] BITINT_TYPE unsupported in c-ada-spec.cc
[PATCH v2] analyzer: Call off a superseding when diagnostics are unrelated [PR110830]
From: benjamin priour
Hi,
Second version of this patch after David's suggestions.
Thanks David for pointing out how I could implement it using sedges.
I hadn't thought of them being independent of the exploded path taken,
and unique for a conditional block's outcome. I had mistaken them with
eedges, those that we see in the *exploded*-graph, therefore since the
two saved_diagnostics can have arbitrary different paths I had to
use a nested loop.
It is much more efficient this way.
Regstrapped off trunk a7d052b3200c7928d903a0242b8cfd75d131e374 on
x86_64-linux-gnu.
Is it ready for trunk ?
Thanks,
Benjamin.
Patch below.
---
Before this patch, a saved_diagnostic would supersede another at
the same statement if and only its vfunc supercedes_p returned true
for the other diagnostic's kind.
That both warning were unrelated - i.e. resolving one would not fix
the other - was not considered in making the above choice.
This patch makes it so that two saved_diagnostics taking a different
outcome of at least one common conditional branching cannot supersede
each other.
Signed-off-by: benjamin priour
Co-authored-by: david malcolm
gcc/analyzer/ChangeLog:
PR analyzer/110830
* diagnostic-manager.cc
(compatible_epaths_p): New function.
(saved_diagnostic::supercedes_p): Now calls the above
to determine if the diagnostics do overlap and the superseding
may proceed.
gcc/testsuite/ChangeLog:
PR analyzer/110830
* c-c++-common/analyzer/pr110830.c: New test.
---
gcc/analyzer/diagnostic-manager.cc| 90 +-
.../c-c++-common/analyzer/pr110830.c | 111 ++
2 files changed, 200 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/c-c++-common/analyzer/pr110830.c
diff --git a/gcc/analyzer/diagnostic-manager.cc
b/gcc/analyzer/diagnostic-manager.cc
index 10fea486b8c..90c56a350e7 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -887,6 +887,88 @@ saved_diagnostic::add_duplicate (saved_diagnostic *other)
m_duplicates.safe_push (other);
}
+/* Walk up the sedges of each of the two paths.
+ If the two sequences of sedges do not perfectly correspond,
+ then paths are incompatible.
+ If there is at least one sedge that either cannot be paired up
+ or its counterpart is not equal, then the paths are incompatible
+ and this function returns FALSE.
+ Otherwise return TRUE.
+
+ Incompatible paths:
+
+
+ / \
+ /\
+true false
+ | |
+......
+ | |
+... stmt x
+ |
+ stmt x
+
+ Both LHS_PATH and RHS_PATH final enodes should be
+ over the same gimple statement. */
+
+static bool
+compatible_epath_p (const exploded_path *lhs_path,
+ const exploded_path *rhs_path)
+{
+ gcc_assert (lhs_path);
+ gcc_assert (rhs_path);
+ gcc_assert (rhs_path->length () > 0);
+ gcc_assert (rhs_path->length () > 0);
+ int lhs_eedge_idx = lhs_path->length () -1;
+ int rhs_eedge_idx = rhs_path->length () -1;
+ const exploded_edge *lhs_eedge;
+ const exploded_edge *rhs_eedge;
+
+ while (lhs_eedge_idx >= 0 && rhs_eedge_idx >= 0)
+{
+ while (lhs_eedge_idx >= 0)
+ {
+ /* Find LHS_PATH's next superedge. */
+ lhs_eedge = lhs_path->m_edges[lhs_eedge_idx];
+ if (lhs_eedge->m_sedge)
+ break;
+ else
+ lhs_eedge_idx--;
+ }
+ while (rhs_eedge_idx >= 0)
+ {
+ /* Find RHS_PATH's next superedge. */
+ rhs_eedge = rhs_path->m_edges[rhs_eedge_idx];
+ if (rhs_eedge->m_sedge)
+ break;
+ else
+ rhs_eedge_idx--;
+ }
+
+ if (lhs_eedge->m_sedge && rhs_eedge->m_sedge)
+ {
+ if (lhs_eedge->m_sedge != rhs_eedge->m_sedge)
+ /* Both superedges do not match.
+ Superedges are not dependent on the exploded path, so even
+ different epaths will have similar sedges if they follow
+ the same outcome of a conditional node. */
+ return false;
+
+ lhs_eedge_idx--;
+ rhs_eedge_idx--;
+ continue;
+ }
+ else if (lhs_eedge->m_sedge == nullptr && rhs_eedge->m_sedge == nullptr)
+ /* Both paths were drained up entirely.
+ No discriminant was found. */
+ return true;
+
+ /* A superedge was found for only one of the two paths. */
+ return false;
+}
+}
+
+
/* Return true if this diagnostic supercedes OTHER, and that OTHER should
therefore not be emitted. */
@@ -896,7 +978,13 @@ saved_diagnostic::supercedes_p (const saved_diagnostic
) const
/* They should be at the same stmt. */
if (m_stmt != other.m_stmt)
return false;
- return m_d->supercedes_p (*other.m_d);
+ /* return early if OTHER won't be superseded anyway. */
+ if (!m_d->supercedes_p (*other.m_d))
+return false;
+
+ /* If the two
Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion
On Wed, 06 Sep 2023 09:47:05 PDT (-0700), jeffreya...@gmail.com wrote:
On 9/6/23 10:22, Palmer Dabbelt wrote:
On Wed, 06 Sep 2023 09:07:33 PDT (-0700), christoph.muell...@vrull.eu
wrote:
From: Christoph Müllner
This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are
available.
The inserted sequences are:
rv32gc_zbb (RV64 is similar):
add a3,a0,4
li a4,-1
.L1: lw a5,0(a0)
add a0,a0,4
orc.b a5,a5
beq a5,a4,.L1
not a5,a5
ctz a5,a5
srl a5,a5,0x3
add a0,a0,a5
sub a0,a0,a3
rv64gc_xtheadbb (RV32 is similar):
add a4,a0,8
.L2: ld a5,0(a0)
add a0,a0,8
th.tstnbz a5,a5
beqz a5,.L2
th.rev a5,a5
th.ff1 a5,a5
srl a5,a5,0x3
add a0,a0,a5
sub a0,a0,a4
This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test
The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.
Maybe this is more of a Jeff question, but this looks to me like
something that should be target-agnostic -- maybe we need some backend
work to actually emit the special instruction, but IIRC this is a
somewhat common flavor of instruction and is in other ISAs as well. It
looks like there's already a strlen insn, so I guess the core issue is
why we need that unspec?
Sorry if I'm just missing something, though...
The generic strlen expansion in GCC doesn't really expand a strlen loop.
It really just calls into the target code and forces the target to
handle everything.
OK, that explains it.
We could have generic strlen expansion code that kicks in if the target
expander fails. And we could probably create the necessary opcodes to
express the optimized end-of-string comparison instructions that exist
on various architectures. I'm not not sure it's worth that much effort
given targets are already doing their own strlen expansions.
If everyone does it this way then I don't think we need to worry about
it.
jeff
[Bug ada/111308] BITINT_TYPE unsupported in c-ada-spec.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111308 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2023-09-06 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- Thanks for creating the PR. We'll need to think about it indeed.
libgo patch committed: permit $AR to include options
This libgo patch changes the go tool to permit the AR environment
variable to include options. This mirrors the way it already handles
the CC environment variable.
This ports https://go.dev/cl/526275 to the gofrontend repo.
This is needed for gccgo testing because the top-level GCC Makefile
now passes a --plugin option to ar if it supports one.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
dab7163feedc99bd94549ee490031f86f8d0a6ca
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 83ab3e2d64c..30710e856cb 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-d04b024021bb7dbaa434a6d902bd12beb08e315f
+53cdfab53ce79d8dfc1df01a696d4ffc43f17c3d
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
diff --git a/libgo/go/cmd/go/internal/work/gccgo.go
b/libgo/go/cmd/go/internal/work/gccgo.go
index c1026c71e01..3e07f8791eb 100644
--- a/libgo/go/cmd/go/internal/work/gccgo.go
+++ b/libgo/go/cmd/go/internal/work/gccgo.go
@@ -45,12 +45,8 @@ func (gccgoToolchain) linker() string {
return GccgoBin
}
-func (gccgoToolchain) ar() string {
- ar := cfg.Getenv("AR")
- if ar == "" {
- ar = "ar"
- }
- return ar
+func (gccgoToolchain) ar() []string {
+ return envList("AR", "ar")
}
func checkGccgoBin() {
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050
--- Comment #6 from TC ---
The crash is gone if lib2.o is compiled with bits/hashtable_policy.h patched
like so:
--- a/path/to/gcc-13/include/c++/13.2.0/bits/hashtable_policy.h
+++ b/hashtable_policy.h
@@ -327,18 +327,22 @@ namespace __detail
__gnu_cxx::__aligned_buffer<_Value> _M_storage;
+ [[__gnu__::__always_inline__]]
_Value*
_M_valptr() noexcept
{ return _M_storage._M_ptr(); }
+ [[__gnu__::__always_inline__]]
const _Value*
_M_valptr() const noexcept
{ return _M_storage._M_ptr(); }
+ [[__gnu__::__always_inline__]]
_Value&
_M_v() noexcept
{ return *_M_valptr(); }
+ [[__gnu__::__always_inline__]]
const _Value&
_M_v() const noexcept
{ return *_M_valptr(); }
I'm following up with my reporter to see if this also fixes the problem with
their actual code.
[Bug c++/110158] Cannot use union with std::string inside in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110158
--- Comment #6 from danakj at orodu dot net ---
In case it is of help, here's an even smaller repro that clang reports the
error in libstdc++. For whatever reason gcc does not notice the libstdc++ bug
here.
https://gcc.godbolt.org/z/Phndafeoe
```
#include
struct S {
constexpr ~S() {}
std::string s;
};
constexpr std::string foo(const S& s) { return s.s; }
static_assert(foo(S("hi")) == "hi"); // Fails.
static_assert(foo(S("a longer string works")) == "a longer string works");
int main() {}
```
The error:
```
:11:15: error: static assertion expression is not an integral constant
expression
static_assert(foo(S("hi")) == "hi");
^~~~
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/basic_string.h:356:10:
note: assignment to member '_M_local_buf' of union with no active member is not
allowed in a constant expression
__c = _CharT();
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/basic_string.tcc:229:4:
note: in call to '(("hi")).s->_M_use_local_data()'
_M_use_local_data();
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/basic_string.h:642:2:
note: in call to '(("hi")).s->_M_construct(&"hi"[0], &"hi"[2], {{}})'
_M_construct(__s, __end, forward_iterator_tag());
^
:11:21: note: in call to 'basic_string(&"hi"[0],
std::allocator())'
static_assert(foo(S("hi")) == "hi");
^
1 error generated.
```
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050
--- Comment #5 from TC ---
Minimal example:
$ cat lib1.cpp
#include
#include
static std::unordered_set set;
void del(const std::string& s) {
set.erase(s);
}
$ cat lib2.cpp
#include
#include
static std::unordered_set set;
void add(const std::string& s) {
set.emplace(s);
}
const std::string& get(const std::string& s) {
return *set.find(s);
}
$ cat main.cpp
#include
void add(const std::string&);
void del(const std::string&);
const std::string& get(const std::string&);
int main() {
add("foo");
del("bar");
(void) get("foo").size();
}
$ g++-10 -std=c++17 lib1.cpp -c -o lib1.o
$ g++-13 -std=c++17 lib2.cpp -c -o lib2.o
$ g++-13 -std=c++17 main.cpp lib1.o lib2.o -o test
$ ./test
Segmentation fault (core dumped)
[Bug c++/110158] Cannot use union with std::string inside in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110158 --- Comment #5 from danakj at orodu dot net --- As a means to work around #4 in static asserts, making your string long enough that it avoids the SSO will allow the compiler to accept it.
[PATCH 5/5] RISC-V: Remove Assert Protecting Types
This patch turns on the assert which ensures every instruction has type that is not TYPE_UNKNOWN. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_sched_variable_issue): Remove assert Signed-off-by: Edwin Lu --- gcc/config/riscv/riscv.cc | 2 -- 1 file changed, 2 deletions(-) diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc index ef63079de8e..f0576351cda 100644 --- a/gcc/config/riscv/riscv.cc +++ b/gcc/config/riscv/riscv.cc @@ -7330,11 +7330,9 @@ riscv_sched_variable_issue (FILE *, int, rtx_insn *insn, int more) if (get_attr_type (insn) == TYPE_GHOST) return 0; -#if 0 /* If we ever encounter an insn with an unknown type, trip an assert so we can find and fix this problem. */ gcc_assert (get_attr_type (insn) != TYPE_UNKNOWN); -#endif return more - 1; } -- 2.34.1
[PATCH 3/5] RISC-V: Add Types to Un-Typed Zicond Instructions
This patch creates a new "zicond" type and updates all zicond instructions with that type. gcc/ChangeLog: * config/riscv/riscv.md: Add "zicond" type * config/riscv/zicond.md: Update types Signed-off-by: Edwin Lu --- gcc/config/riscv/riscv.md | 5 +++-- gcc/config/riscv/zicond.md | 8 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md index 6684ad89cff..c329f55db43 100644 --- a/gcc/config/riscv/riscv.md +++ b/gcc/config/riscv/riscv.md @@ -313,6 +313,7 @@ (define_attr "ext_enabled" "no,yes" ;; cbocache block instructions ;; crypto cryptography instructions ;; csrcode size reduction instructions +;; zicondzicond instructions ;; Classification of RVV instructions which will be added to each RVV .md pattern and used by scheduler. ;; rdvlenb vector byte length vlenb csrr read ;; rdvlvector length vl csrr read @@ -422,8 +423,8 @@ (define_attr "type" mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul, fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip, rotate,clmul,min,max,minu,maxu,clz,ctz,cpop, - atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl, - vlde,vste,vldm,vstm,vlds,vsts, + atomic,condmove,cbo,crypto,csr,zicond,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm, + vsetvl, vlde,vste,vldm,vstm,vlds,vsts, vldux,vldox,vstux,vstox,vldff,vldr,vstr, vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff, vialu,viwalu,vext,vicalu,vshift,vnshift,vicmp,viminmax, diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md index 1721e1011ea..0269bd14399 100644 --- a/gcc/config/riscv/zicond.md +++ b/gcc/config/riscv/zicond.md @@ -30,7 +30,7 @@ (define_insn "*czero.." (const_int 0)))] "TARGET_ZICOND" "czero.\t%0,%2,%1" -) +[(set_attr "type" "zicond")]) (define_insn "*czero.." [(set (match_operand:GPR 0 "register_operand" "=r") @@ -40,7 +40,7 @@ (define_insn "*czero.." (match_operand:GPR 2 "register_operand" "r")))] "TARGET_ZICOND" "czero.\t%0,%2,%1" -) +[(set_attr "type" "zicond")]) ;; Special optimization under eq/ne in primitive semantics (define_insn "*czero.eqz..opt1" @@ -51,7 +51,7 @@ (define_insn "*czero.eqz..opt1" (match_operand:GPR 3 "register_operand" "r")))] "TARGET_ZICOND && rtx_equal_p (operands[1], operands[2])" "czero.eqz\t%0,%3,%1" -) +[(set_attr "type" "zicond")]) (define_insn "*czero.nez..opt2" [(set (match_operand:GPR 0 "register_operand" "=r") @@ -61,7 +61,7 @@ (define_insn "*czero.nez..opt2" (match_operand:GPR 3 "register_operand" "1")))] "TARGET_ZICOND && rtx_equal_p (operands[1], operands[3])" "czero.eqz\t%0,%2,%1" -) +[(set_attr "type" "zicond")]) ;; Combine creates this form in some cases (particularly the coremark ;; CRC loop. -- 2.34.1
[PATCH 4/5] RISC-V: Update Types for RISC-V Instructions
This patch adds types to riscv instructions that were added or were missed by the original patch https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628996.html gcc/ChangeLog: * config/riscv/riscv.md: Update types Signed-off-by: Edwin Lu --- gcc/config/riscv/riscv.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md index c329f55db43..c1cecd27815 100644 --- a/gcc/config/riscv/riscv.md +++ b/gcc/config/riscv/riscv.md @@ -2223,6 +2223,7 @@ (define_insn "movsidf2_low_rv32" "TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA" "fmv.x.w\t%0,%1" [(set_attr "move_type" "fmove") + (set_attr "type" "fmove") (set_attr "mode" "DF")]) @@ -2235,6 +2236,7 @@ (define_insn "movsidf2_high_rv32" "TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA" "fmvh.x.d\t%0,%1" [(set_attr "move_type" "fmove") + (set_attr "type" "fmove") (set_attr "mode" "DF")]) (define_insn "movdfsisi3_rv32" @@ -2247,6 +2249,7 @@ (define_insn "movdfsisi3_rv32" "TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA" "fmvp.d.x\t%0,%2,%1" [(set_attr "move_type" "fmove") + (set_attr "type" "fmove") (set_attr "mode" "DF")]) (define_split -- 2.34.1
[PATCH 2/5] RISC-V: Add Types for Un-Typed zc Instructions
This patch adds types to the untyped zc instructions. Creates a new
type "csr" for these instructions for now.
gcc/ChangeLog:
* config/riscv/riscv.md: Add "csr" type
* config/riscv/zc.md: Update types
Signed-off-by: Edwin Lu
---
gcc/config/riscv/riscv.md | 3 +-
gcc/config/riscv/zc.md| 102 +++---
2 files changed, 54 insertions(+), 51 deletions(-)
diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index d80b6938f84..6684ad89cff 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -312,6 +312,7 @@ (define_attr "ext_enabled" "no,yes"
;; condmoveconditional moves
;; cbocache block instructions
;; crypto cryptography instructions
+;; csrcode size reduction instructions
;; Classification of RVV instructions which will be added to each RVV .md
pattern and used by scheduler.
;; rdvlenb vector byte length vlenb csrr read
;; rdvlvector length vl csrr read
@@ -421,7 +422,7 @@ (define_attr "type"
mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul,
fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip,
rotate,clmul,min,max,minu,maxu,clz,ctz,cpop,
- atomic,condmove,cbo,crypto,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
+ atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
vlde,vste,vldm,vstm,vlds,vsts,
vldux,vldox,vstux,vstox,vldff,vldr,vstr,
vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff,
diff --git a/gcc/config/riscv/zc.md b/gcc/config/riscv/zc.md
index 77b28adde95..86f1afd66cb 100644
--- a/gcc/config/riscv/zc.md
+++ b/gcc/config/riscv/zc.md
@@ -27,7 +27,7 @@ (define_insn "@gpr_multi_pop_up_to_ra_"
(const_int ]
"TARGET_ZCMP"
"cm.pop {ra}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_pop_up_to_s0_"
[(set (reg:X SP_REGNUM)
@@ -41,7 +41,7 @@ (define_insn "@gpr_multi_pop_up_to_s0_"
(const_int ]
"TARGET_ZCMP"
"cm.pop {ra, s0}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_pop_up_to_s1_"
[(set (reg:X SP_REGNUM)
@@ -58,7 +58,7 @@ (define_insn "@gpr_multi_pop_up_to_s1_"
(const_int ]
"TARGET_ZCMP"
"cm.pop {ra, s0-s1}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_pop_up_to_s2_"
[(set (reg:X SP_REGNUM)
@@ -78,7 +78,7 @@ (define_insn "@gpr_multi_pop_up_to_s2_"
(const_int ]
"TARGET_ZCMP"
"cm.pop {ra, s0-s2}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_pop_up_to_s3_"
[(set (reg:X SP_REGNUM)
@@ -101,7 +101,7 @@ (define_insn "@gpr_multi_pop_up_to_s3_"
(const_int ]
"TARGET_ZCMP"
"cm.pop {ra, s0-s3}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_pop_up_to_s4_"
[(set (reg:X SP_REGNUM)
@@ -127,7 +127,7 @@ (define_insn "@gpr_multi_pop_up_to_s4_"
(const_int ]
"TARGET_ZCMP"
"cm.pop {ra, s0-s4}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_pop_up_to_s5_"
[(set (reg:X SP_REGNUM)
@@ -156,7 +156,7 @@ (define_insn "@gpr_multi_pop_up_to_s5_"
(const_int ]
"TARGET_ZCMP"
"cm.pop {ra, s0-s5}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_pop_up_to_s6_"
[(set (reg:X SP_REGNUM)
@@ -188,7 +188,7 @@ (define_insn "@gpr_multi_pop_up_to_s6_"
(const_int ]
"TARGET_ZCMP"
"cm.pop {ra, s0-s6}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_pop_up_to_s7_"
[(set (reg:X SP_REGNUM)
@@ -223,7 +223,7 @@ (define_insn "@gpr_multi_pop_up_to_s7_"
(const_int ]
"TARGET_ZCMP"
"cm.pop {ra, s0-s7}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_pop_up_to_s8_"
[(set (reg:X SP_REGNUM)
@@ -261,7 +261,7 @@ (define_insn "@gpr_multi_pop_up_to_s8_"
(const_int ]
"TARGET_ZCMP"
"cm.pop {ra, s0-s8}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_pop_up_to_s9_"
[(set (reg:X SP_REGNUM)
@@ -302,7 +302,7 @@ (define_insn "@gpr_multi_pop_up_to_s9_"
(const_int ]
"TARGET_ZCMP"
"cm.pop {ra, s0-s9}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_pop_up_to_s11_"
[(set (reg:X SP_REGNUM)
@@ -349,7 +349,7 @@ (define_insn "@gpr_multi_pop_up_to_s11_"
(const_int ]
"TARGET_ZCMP"
"cm.pop {ra, s0-s11}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_popret_up_to_ra_"
[(set (reg:X SP_REGNUM)
@@ -362,7 +362,7 @@ (define_insn "@gpr_multi_popret_up_to_ra_"
(use (reg:SI RETURN_ADDR_REGNUM))]
"TARGET_ZCMP"
"cm.popret {ra}, %0"
-)
+[(set_attr "type" "csr")])
(define_insn "@gpr_multi_popret_up_to_s0_"
[(set (reg:X SP_REGNUM)
@@ -378,7 +378,7 @@ (define_insn
[PATCH 1/5] RISC-V: Update Types for Vector Instructions
This patch adds types to vector instructions that were added after or were missed by the original patch https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628594.html gcc/ChangeLog: * config/riscv/autovec-opt.md: Update types * config/riscv/autovec.md: likewise Signed-off-by: Edwin Lu --- gcc/config/riscv/autovec-opt.md | 42 ++--- gcc/config/riscv/autovec.md | 28 +++--- 2 files changed, 47 insertions(+), 23 deletions(-) diff --git a/gcc/config/riscv/autovec-opt.md b/gcc/config/riscv/autovec-opt.md index 1ca5ce97193..6cc1a01629c 100644 --- a/gcc/config/riscv/autovec-opt.md +++ b/gcc/config/riscv/autovec-opt.md @@ -728,7 +728,8 @@ (define_insn_and_split "*cond_abs" gen_int_mode (GET_MODE_NUNITS (mode), Pmode), const0_rtx)); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine vlmax neg and UNSPEC_VCOPYSIGN (define_insn_and_split "*copysign_neg" @@ -746,7 +747,8 @@ (define_insn_and_split "*copysign_neg" riscv_vector::emit_vlmax_insn (code_for_pred_ncopysign (mode), riscv_vector::BINARY_OP, operands); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine sign_extend/zero_extend(vf2) and vcond_mask (define_insn_and_split "*cond_" @@ -765,7 +767,8 @@ (define_insn_and_split "*cond_" gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine sign_extend/zero_extend(vf4) and vcond_mask (define_insn_and_split "*cond_" @@ -784,7 +787,8 @@ (define_insn_and_split "*cond_" gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine sign_extend/zero_extend(vf8) and vcond_mask (define_insn_and_split "*cond_" @@ -803,7 +807,8 @@ (define_insn_and_split "*cond_" gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine trunc(vf2) + vcond_mask (define_insn_and_split "*cond_trunc" @@ -823,7 +828,8 @@ (define_insn_and_split "*cond_trunc" gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine FP sign_extend/zero_extend(vf2) and vcond_mask (define_insn_and_split "*cond_extend" @@ -842,7 +848,8 @@ (define_insn_and_split "*cond_extend" gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine FP trunc(vf2) + vcond_mask (define_insn_and_split "*cond_trunc" @@ -862,7 +869,8 @@ (define_insn_and_split "*cond_trunc" gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine convert(FP->INT) + vcond_mask (define_insn_and_split "*cond_" @@ -882,7 +890,8 @@ (define_insn_and_split "*cond_" gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine convert(INT->FP) + vcond_mask (define_insn_and_split "*cond_" @@ -902,7 +911,8 @@ (define_insn_and_split "*cond_" gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine convert(FP->2xINT) + vcond_mask (define_insn_and_split "*cond_" @@ -922,7 +932,8 @@ (define_insn_and_split "*cond_" gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine convert(INT->2xFP) + vcond_mask (define_insn_and_split "*cond_" @@ -942,7 +953,8 @@ (define_insn_and_split "*cond_" gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine convert(2xFP->INT) + vcond_mask (define_insn_and_split "*cond_" @@ -962,7 +974,8 @@ (define_insn_and_split "*cond_" gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} +[(set_attr "type" "vector")]) ;; Combine convert(2xINT->FP) + vcond_mask (define_insn_and_split "*cond_2" @@ -982,4 +995,5 @@ (define_insn_and_split "*cond_2" gen_int_mode (GET_MODE_NUNITS (mode), Pmode)}; riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} +[(set_attr "type" "vector")]) diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md index 0f9d1fe2c8e..047a66b238f 100644 --- a/gcc/config/riscv/autovec.md +++
[PATCH 0/5] RISC-V: Add Types to Untyped Instructions
This series adds types to the remaining untyped instructions. Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ Also enables assert which checks to make sure every instruction has a type All patches were tested with rv32/rv64 linux/newlib multilib Additional extensions tested: gcv gc_zba_zbb_zbc_zbs Edwin Lu (5): RISC-V: Update Types for Vector Instructions RISC-V: Add Types for Un-Typed zc Instructions RISC-V: Add Types to Un-Typed Zicond Instructions RISC-V: Add Types to Un-Typed Zicond Instructions RISC-V: Remove Assert Protecting Types gcc/config/riscv/autovec-opt.md | 42 - gcc/config/riscv/autovec.md | 28 ++--- gcc/config/riscv/riscv.cc | 2 - gcc/config/riscv/riscv.md | 9 ++- gcc/config/riscv/zc.md | 102 gcc/config/riscv/zicond.md | 8 +-- 6 files changed, 110 insertions(+), 81 deletions(-) -- 2.34.1
[Bug c/111309] va_arg alternative for _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309 --- Comment #3 from joseph at codesourcery dot com --- Defined values for 0 are marginally more convenient for implementing the standard operations which have defined results for all arguments, and I think it's appropriate for the type-generic built-in functions to work for all integer types - at least all unsigned integer types (and including unsigned __int128) - rather than just _BitInt types. ( itself - providing both functions and type-generic macros - makes most sense to provide in libc, I think. The type-generic macros there don't actually support bit-precise types whose width doesn't match a standard/extended type, but providing such support, given appropriate built-in functions, certainly makes sense as an extension.)
[Bug c/111309] va_arg alternative for _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309 --- Comment #2 from Jakub Jelinek --- For clz/ctz/parity/popcount/clrsb/ffs, it should be quite easy to implement them, the primary questions are, what the builtin name should be (because __builtin_clz etc. is already taken for unsigned int argument (resp. int for clrsb), so we want some suffix either for all type-generic _BitInt types, or make it type-generic completely and support all integral types in there. And second question for clz/ctz is whether we should preserve the UB behavior for 0 argument, or define return value even for those. For larger _BitInt it will be implemented using loops and so will need to take 0 limbs into account anyway, so the advantage of invoking UB on it is smaller, and for users testing whether _BitInt(32768) is non-zero is already quite expensive if they wanted to have well-defined result in that case.
[Bug fortran/111304] Problem when passing implicit arrays of characters to functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111304 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from anlauf at gcc dot gnu.org --- Looks like a duplicate of pr85547. *** This bug has been marked as a duplicate of bug 85547 ***
[Bug fortran/85547] Run-time error: character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||mailling-lists-bd at posteo dot de --- Comment #7 from anlauf at gcc dot gnu.org --- *** Bug 111304 has been marked as a duplicate of this bug. ***
[Bug c/111309] va_arg alternative for _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309 --- Comment #1 from joseph at codesourcery dot com --- Yes, we should have APIs for building type-generic _BitInt interfaces (also a width-of operation to give the width in bits of an integer type; also type-generic versions of operations such as clz, ctz, parity, popcount that work to the width in bits of any unsigned operand). Though I suspect any library implementations of printf _BitInt support would end up needing architecture-specific workarounds for a while to avoid depending on having GCC new enough to support _BitInt in order to build a library with that support.
Re: Question on aarch64 prologue code.
On 06/09/2023 15:03, Iain Sandoe wrote: > Hi Richard, > >> On 6 Sep 2023, at 13:43, Richard Sandiford via Gcc wrote: >> >> Iain Sandoe writes: > >>> On the Darwin aarch64 port, we have a number of cleanup test fails (pretty >>> much corresponding to the [still open] >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39244). However, let’s assume >>> that bug could be a red herring.. >>> >>> the underlying reason is missing CFI for the set of the FP which [with >>> Darwin’s LLVM libunwind impl.] breaks the unwind through the function that >>> triggers a signal. >> >> Just curious, do you have more details about why that is? If the unwinder >> is sophisticated enough to process CFI, it seems odd that it requires the >> CFA to be defined in terms of the frame pointer. > > Let me see if I can answer that below. > > > >>> <—— >>> >>> I have currently worked around this by defining a >>> TARGET_FRAME_POINTER_REQUIRED which returns true unless the function is a >>> leaf (if that’s the correct solution, then all is fine). >> >> I suppose it depends on why the frame-pointer-based CFA is important >> for Darwin. If it's due to a more general requirement for a frame >> pointer to be used, then yeah, that's probably the right fix. > > The Darwin ABI mandates a frame pointer (although it is omitted by clang for > leaf functions). > >> If it's >> more a quirk of the unwinder. then we could probably expose whatever >> that quirk is as a new status bit. Target-independent code in >> dwarf2cfi.cc would then need to be aware as well. > > (I suspect) it is the interaction between the mandatory FP and the fact that > GCC lays out the stack differently from the other Darwin toolchains at > present [port Issue #19]. > > For the system toolchain, 30 and 29 are always placed first, right below the > SP (other callee saves are made below that in a specified order and always in > pairs - presumably, with an uneccessary spill half the time) - Actually, I > had a look at the weekend, but cannot find specific documentation on this > particular aspect of the ABI (but, of course, the de facto ABI is what the > system toolchain does, regardless of presence/absence of any such doc). > > However (speculation) that means that the FP is not saved where the system > tools expect it, maybe that is confusing the unwinder absent the fp cfa. Of > course, it could also just be an unwinder bug that is never triggered by > clang’s codegen. > > GCC’s different layout currently defeats compact unwinding on all but leaf > frames, so one day I want to fix it ... > .. however making this change is quite heavy lifting and I think there are > higher priorities for the port (so, as long as we have working unwind and no > observable fallout, I am deferring that change). > > Note that Darwin’s ABI also has a red zone (but we have not yet made any use > of this, since there is no existing aarch64 impl. and I’ve not had time to > get to it). However, AFAICS that is an optimisation - we can still be > correct without it. > >>> ——— >>> >>> However, it does seem odd that the existing code sets up the FP, but never >>> produces any CFA for it. >>> >>> So is this a possible bug, or just that I misunderstand the relevant set of >>> circumstances? >> >> emit_frame_chain fulfills an ABI requirement that every non-leaf function >> set up a frame-chain record. When emit_frame_chain && !frame_pointer_needed, >> we set up the FP for ABI purposes only. GCC can still access everything >> relative to the stack pointer, and it can still describe the CFI based >> purely on the stack pointer. > > Thanks that makes sense > - I guess libunwind is never used with aarch64 linux, even in a clang/llvm > toolchain. >> >> glibc-based systems only need the CFA to be based on the frame pointer >> if the stack pointer moves during the body of the function (usually due >> to alloca or VLAs). > > I’d have to poke more at the unwinder code and do some more debugging - it > seems reasonable that it could work for any unwinder that’s based on DWARF > (although, if we have completely missing unwind info, then the different > stack layout would surely defeat any fallback proceedure). > This is only a guess, but it sounds to me like the issue might be that although we create a frame record, we don't use the frame pointer for accessing stack variables unless SP can't be used (eg: because the function calls alloca()). This tends to be more efficient because offset addressing for SP is more flexible. If we wanted to switch to making FP be the canonical frame address register we'd need to change all the code gen to use FP in addressing as well (or end up with some really messy translation when emitting debug information). R. > thanks > Iain > >> >> Thanks, >> Richard >
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 François Dumont changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from François Dumont --- Considering that explosion is taking place in your code built with a gcc post-11 while calling _M_next() on a _Hashtable instance node coming from a .so built with a gcc pre-11 version I think your solution should work. I'll send a patch proposal to mailing list.
[Bug c/111309] New: va_arg alternative for _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309
Bug ID: 111309
Summary: va_arg alternative for _BitInt
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
For https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2858.pdf , I wonder if we
shouldn't have a __builtin_va_arg variant which would allow to read arbitrary
_BitInt
into array of limbs. The builtin IMHO should be passed at least the N from
_BitInt(N), probably whether it is signed vs. unsigned and pointer to the array
of limbs, dunno whether it should only support limb type which it also uses for
the libgcc APIs or whether the type should be e.g. inferred from the scalar
integer type the pointer argument points to. And whether the endianity in
which limbs are ordered should be host endianity, some other argument to the
builtin, or always the _BitInt endianity.
On arches like x86-64 where the passing ABI says for N <= 8 pass like char, for
N <= 16 pass like short, for N <= 32 pass like int, for N <= 64 pass like long
long, otherwise pass like struct { long long a[(N + 63) / 64]; } it would need
to differentiate at runtime (unless N is constant obviously) the different
cases to perform proper VA_ARG for that, plus handle the generic case which
would be always passed in memory.
Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion
On 9/6/23 10:22, Palmer Dabbelt wrote:
On Wed, 06 Sep 2023 09:07:33 PDT (-0700), christoph.muell...@vrull.eu
wrote:
From: Christoph Müllner
This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are
available.
The inserted sequences are:
rv32gc_zbb (RV64 is similar):
add a3,a0,4
li a4,-1
.L1: lw a5,0(a0)
add a0,a0,4
orc.b a5,a5
beq a5,a4,.L1
not a5,a5
ctz a5,a5
srl a5,a5,0x3
add a0,a0,a5
sub a0,a0,a3
rv64gc_xtheadbb (RV32 is similar):
add a4,a0,8
.L2: ld a5,0(a0)
add a0,a0,8
th.tstnbz a5,a5
beqz a5,.L2
th.rev a5,a5
th.ff1 a5,a5
srl a5,a5,0x3
add a0,a0,a5
sub a0,a0,a4
This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test
The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.
Maybe this is more of a Jeff question, but this looks to me like
something that should be target-agnostic -- maybe we need some backend
work to actually emit the special instruction, but IIRC this is a
somewhat common flavor of instruction and is in other ISAs as well. It
looks like there's already a strlen insn, so I guess the core issue is
why we need that unspec?
Sorry if I'm just missing something, though...
The generic strlen expansion in GCC doesn't really expand a strlen loop.
It really just calls into the target code and forces the target to
handle everything.
We could have generic strlen expansion code that kicks in if the target
expander fails. And we could probably create the necessary opcodes to
express the optimized end-of-string comparison instructions that exist
on various architectures. I'm not not sure it's worth that much effort
given targets are already doing their own strlen expansions.
jeff
[Bug ada/111308] New: BITINT_TYPE unsupported in c-ada-spec.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111308 Bug ID: 111308 Summary: BITINT_TYPE unsupported in c-ada-spec.cc Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: adam.warner.nz at gmail dot com, alx at kernel dot org, bergner at gcc dot gnu.org, chfast at gmail dot com, dje at gcc dot gnu.org, dkm at gcc dot gnu.org, fw at gcc dot gnu.org, george at bott dot gg, hjl.tools at gmail dot com, jakub at gcc dot gnu.org, jsm28 at gcc dot gnu.org, leni536 at gmail dot com, rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org, segher at gcc dot gnu.org, sjames at gcc dot gnu.org, tmgross at umich dot edu, uweigand at gcc dot gnu.org Depends on: 102989 Target Milestone: --- +++ This bug was initially created as a clone of Bug #102989 +++ I haven't added BITINT_TYPE support to c-ada-spec.cc, as I have no idea what you want to do in Ada for that. Example of problematic declaration in some header (so far on x86-64) would be extern _BitInt(157) foo (unsigned _BitInt(384) x, signed _BitInt(15) y, int z); Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 [Bug 102989] Implement C2x's n2763 (_BitInt)
Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion
On Wed, 06 Sep 2023 09:07:33 PDT (-0700), christoph.muell...@vrull.eu wrote:
From: Christoph Müllner
This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are available.
The inserted sequences are:
rv32gc_zbb (RV64 is similar):
add a3,a0,4
li a4,-1
.L1: lw a5,0(a0)
add a0,a0,4
orc.b a5,a5
beq a5,a4,.L1
not a5,a5
ctz a5,a5
srl a5,a5,0x3
add a0,a0,a5
sub a0,a0,a3
rv64gc_xtheadbb (RV32 is similar):
add a4,a0,8
.L2: lda5,0(a0)
add a0,a0,8
th.tstnbz a5,a5
beqz a5,.L2
th.reva5,a5
th.ff1a5,a5
srl a5,a5,0x3
add a0,a0,a5
sub a0,a0,a4
This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test
The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.
Maybe this is more of a Jeff question, but this looks to me like
something that should be target-agnostic -- maybe we need some backend
work to actually emit the special instruction, but IIRC this is a
somewhat common flavor of instruction and is in other ISAs as well. It
looks like there's already a strlen insn, so I guess the core issue is
why we need that unspec?
Sorry if I'm just missing something, though...
Tested using the glibc string tests.
Signed-off-by: Christoph Müllner
gcc/ChangeLog:
* config.gcc: Add new object riscv-string.o.
riscv-string.cc.
* config/riscv/riscv-protos.h (riscv_expand_strlen):
New function.
* config/riscv/riscv.md (strlen): New expand INSN.
* config/riscv/riscv.opt: New flag 'minline-strlen'.
* config/riscv/t-riscv: Add new object riscv-string.o.
* config/riscv/thead.md (th_rev2): Export INSN name.
(th_rev2): Likewise.
(th_tstnbz2): New INSN.
* doc/invoke.texi: Document '-minline-strlen'.
* emit-rtl.cc (emit_likely_jump_insn): New helper function.
(emit_unlikely_jump_insn): Likewise.
* rtl.h (emit_likely_jump_insn): New prototype.
(emit_unlikely_jump_insn): Likewise.
* config/riscv/riscv-string.cc: New file.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadbb-strlen-unaligned.c: New test.
* gcc.target/riscv/xtheadbb-strlen.c: New test.
* gcc.target/riscv/zbb-strlen-disabled-2.c: New test.
* gcc.target/riscv/zbb-strlen-disabled.c: New test.
* gcc.target/riscv/zbb-strlen-unaligned.c: New test.
* gcc.target/riscv/zbb-strlen.c: New test.
---
gcc/config.gcc| 3 +-
gcc/config/riscv/riscv-protos.h | 3 +
gcc/config/riscv/riscv-string.cc | 183 ++
gcc/config/riscv/riscv.md | 28 +++
gcc/config/riscv/riscv.opt| 4 +
gcc/config/riscv/t-riscv | 6 +
gcc/config/riscv/thead.md | 9 +-
gcc/doc/invoke.texi | 11 +-
gcc/emit-rtl.cc | 24 +++
gcc/rtl.h | 2 +
.../riscv/xtheadbb-strlen-unaligned.c | 14 ++
.../gcc.target/riscv/xtheadbb-strlen.c| 19 ++
.../gcc.target/riscv/zbb-strlen-disabled-2.c | 15 ++
.../gcc.target/riscv/zbb-strlen-disabled.c| 15 ++
.../gcc.target/riscv/zbb-strlen-unaligned.c | 14 ++
gcc/testsuite/gcc.target/riscv/zbb-strlen.c | 19 ++
16 files changed, 366 insertions(+), 3 deletions(-)
create mode 100644 gcc/config/riscv/riscv-string.cc
create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen-unaligned.c
create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-unaligned.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen.c
diff --git a/gcc/config.gcc b/gcc/config.gcc
index b2fe7c7ceef..aff6b6a5601 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -530,7 +530,8 @@ pru-*-*)
;;
riscv*)
cpu_type=riscv
- extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o riscv-shorten-memrefs.o
riscv-selftests.o riscv-v.o riscv-vsetvl.o riscv-vector-costs.o"
+ extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o riscv-shorten-memrefs.o
riscv-selftests.o riscv-string.o"
+ extra_objs="${extra_objs} riscv-v.o riscv-vsetvl.o riscv-vector-costs.o"
extra_objs="${extra_objs} riscv-vector-builtins.o
riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
[committed 19/12] Additional _BitInt test coverage [PR102989]
On Tue, Sep 05, 2023 at 10:40:26PM +, Joseph Myers wrote:
> Additional tests I think should be added (for things I expect should
> already work):
>
> * Tests for BITINT_MAXWIDTH in . Test that it's defined for
> C2x, but not defined for C11/C17 (the latter independent of whether the
> target has _BitInt support). Test the value as well: _BitInt
> (BITINT_MAXWIDTH) should be OK (both signed and unsigned) but _BitInt
> (BITINT_MAXWIDTH + 1) should not be OK. Also test that BITINT_MAXWIDTH >=
> ULLONG_MAX.
>
> * Test _BitInt (N) where N is a constexpr variable or enum constant (I
> expect these should work - the required call to convert_lvalue_to_rvalue
> for constexpr to work is present - but I don't see such tests in the
> testsuite).
>
> * Test that -funsigned-bitfields does not affect the signedness of _BitInt
> (N) bit-fields (the standard wording isn't entirely clear, but that's
> what's implemented in the patches).
>
> * Test the errors for _Sat used with _BitInt (though such a test might not
> actually run at present because no target supports both features).
Here is a patch which adds that test coverage.
> I looked at places in c-family/ and c/ that refer to INTEGER_TYPE to
> consider whether they should handle BITINT_TYPE and whether that matches
> what the patch does there. I think the following places that don't handle
> it probably should (with appropriate testcases added for the relevant
> functionality, e.g. warnings) unless there is some specific reason in each
> case why that's unnecessary or incorrect. c-pretty-print.cc:
> c_pretty_printer::direct_declarator and c_pretty_printer::declarator.
> c-warn.cc throughout. Maybe c-ada-spec.cc, though it might be best to ask
> the Ada maintainers there. c-common.cc: unsafe_conversion_p,
> c_common_truthvalue_conversion warnings, c_common_get_alias_set,
> check_builtin_function_arguments BUILT_IN_ASSUME_ALIGNED case.
> c-aux-info.cc (might need other support for generating appropriate names
> in output). c-parser.cc:c_parser_omp_clause_schedule. c-fold.cc
> throughout. c-typeck.c: the build_conditional_expr case where one operand
> is EXCESS_PRECISION_EXPR; build_c_cast; convert_for_assignment checks for
> integer/pointer conversions.
As well as what I've managed to come up for the above changes.
2023-09-06 Jakub Jelinek
PR c/102989
* gcc.dg/bitint-2.c (foo): Add tests for constexpr var or enumerator
arguments of _BitInt.
* gcc.dg/bitint-31.c: Remove forgotten 0 &&.
* gcc.dg/bitint-32.c: New test.
* gcc.dg/bitint-33.c: New test.
* gcc.dg/bitint-34.c: New test.
* gcc.dg/bitint-35.c: New test.
* gcc.dg/bitint-36.c: New test.
* gcc.dg/fixed-point/bitint-1.c: New test.
--- gcc/testsuite/gcc.dg/bitint-2.c.jj 2023-09-06 10:57:48.771535739 +0200
+++ gcc/testsuite/gcc.dg/bitint-2.c 2023-09-06 12:17:39.764073758 +0200
@@ -14,6 +14,10 @@ foo (void)
_BitInt(5) unsigned d = (unsigned _BitInt(5)) 4;
_BitInt(32) e = (_BitInt(32)) 5;
_BitInt(32) unsigned f = (unsigned _BitInt(32)) 6;
+ constexpr int g = 43;
+ enum E { F = 44 };
+ _BitInt(g) h;
+ unsigned _BitInt(F) i;
static_assert (expr_has_type (a, signed _BitInt(42)), "");
static_assert (expr_has_type (a, _BitInt(42)), "");
static_assert (!expr_has_type (a, unsigned _BitInt(42)), "");
@@ -66,6 +70,8 @@ foo (void)
static_assert (expr_has_type (-1UWB, unsigned _BitInt(1)), "");
static_assert (expr_has_type (1uWB, unsigned _BitInt(1)), "");
static_assert (expr_has_type (2Uwb, unsigned _BitInt(2)), "");
+ static_assert (expr_has_type (h, signed _BitInt(43)), "");
+ static_assert (expr_has_type (i, unsigned _BitInt(44)), "");
static_assert (0wb == 0, "");
static_assert (-1wb == -1, "");
static_assert (0xwb == 4294967295wb, "");
--- gcc/testsuite/gcc.dg/bitint-31.c.jj 2023-09-06 10:57:48.799535349 +0200
+++ gcc/testsuite/gcc.dg/bitint-31.c2023-09-06 11:52:57.675594550 +0200
@@ -255,7 +255,7 @@ main ()
check_round (testfltu_192 (340282356779733661637539395458142568448uwb),
__builtin_inff (), 0xffp+104f, __builtin_inff (), 0xffp+104f);
check_round (testfltu_192
(627710173538668076383578942320766641610235564034512895uwb), __builtin_inff
(), 0xffp+104f, __builtin_inff (), 0xffp+104f);
#endif
-#if 0 && __BITINT_MAXWIDTH__ >= 575
+#if __BITINT_MAXWIDTH__ >= 575
check_round (testflt_575 (10633823015541376812058405359715352575wb),
0xfep+99f, 0xfep+99f, 0xffp+99f, 0xfep+99f);
check_round (testflt_575 (10633823015541376812058405359715352576wb),
0xfep+99f, 0xfep+99f, 0xffp+99f, 0xfep+99f);
check_round (testflt_575 (10633823015541376812058405359715352577wb),
0xffp+99f, 0xfep+99f, 0xffp+99f, 0xfep+99f);
--- gcc/testsuite/gcc.dg/bitint-32.c.jj 2023-09-06 11:57:24.391907466 +0200
+++ gcc/testsuite/gcc.dg/bitint-32.c2023-09-06 12:00:04.885688154
[PATCH v2 1/2] riscv: Add support for strlen inline expansion
From: Christoph Müllner
This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are available.
The inserted sequences are:
rv32gc_zbb (RV64 is similar):
add a3,a0,4
li a4,-1
.L1: lw a5,0(a0)
add a0,a0,4
orc.b a5,a5
beq a5,a4,.L1
not a5,a5
ctz a5,a5
srl a5,a5,0x3
add a0,a0,a5
sub a0,a0,a3
rv64gc_xtheadbb (RV32 is similar):
add a4,a0,8
.L2: lda5,0(a0)
add a0,a0,8
th.tstnbz a5,a5
beqz a5,.L2
th.reva5,a5
th.ff1a5,a5
srl a5,a5,0x3
add a0,a0,a5
sub a0,a0,a4
This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test
The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.
Tested using the glibc string tests.
Signed-off-by: Christoph Müllner
gcc/ChangeLog:
* config.gcc: Add new object riscv-string.o.
riscv-string.cc.
* config/riscv/riscv-protos.h (riscv_expand_strlen):
New function.
* config/riscv/riscv.md (strlen): New expand INSN.
* config/riscv/riscv.opt: New flag 'minline-strlen'.
* config/riscv/t-riscv: Add new object riscv-string.o.
* config/riscv/thead.md (th_rev2): Export INSN name.
(th_rev2): Likewise.
(th_tstnbz2): New INSN.
* doc/invoke.texi: Document '-minline-strlen'.
* emit-rtl.cc (emit_likely_jump_insn): New helper function.
(emit_unlikely_jump_insn): Likewise.
* rtl.h (emit_likely_jump_insn): New prototype.
(emit_unlikely_jump_insn): Likewise.
* config/riscv/riscv-string.cc: New file.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadbb-strlen-unaligned.c: New test.
* gcc.target/riscv/xtheadbb-strlen.c: New test.
* gcc.target/riscv/zbb-strlen-disabled-2.c: New test.
* gcc.target/riscv/zbb-strlen-disabled.c: New test.
* gcc.target/riscv/zbb-strlen-unaligned.c: New test.
* gcc.target/riscv/zbb-strlen.c: New test.
---
gcc/config.gcc| 3 +-
gcc/config/riscv/riscv-protos.h | 3 +
gcc/config/riscv/riscv-string.cc | 183 ++
gcc/config/riscv/riscv.md | 28 +++
gcc/config/riscv/riscv.opt| 4 +
gcc/config/riscv/t-riscv | 6 +
gcc/config/riscv/thead.md | 9 +-
gcc/doc/invoke.texi | 11 +-
gcc/emit-rtl.cc | 24 +++
gcc/rtl.h | 2 +
.../riscv/xtheadbb-strlen-unaligned.c | 14 ++
.../gcc.target/riscv/xtheadbb-strlen.c| 19 ++
.../gcc.target/riscv/zbb-strlen-disabled-2.c | 15 ++
.../gcc.target/riscv/zbb-strlen-disabled.c| 15 ++
.../gcc.target/riscv/zbb-strlen-unaligned.c | 14 ++
gcc/testsuite/gcc.target/riscv/zbb-strlen.c | 19 ++
16 files changed, 366 insertions(+), 3 deletions(-)
create mode 100644 gcc/config/riscv/riscv-string.cc
create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen-unaligned.c
create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-unaligned.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen.c
diff --git a/gcc/config.gcc b/gcc/config.gcc
index b2fe7c7ceef..aff6b6a5601 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -530,7 +530,8 @@ pru-*-*)
;;
riscv*)
cpu_type=riscv
- extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o
riscv-shorten-memrefs.o riscv-selftests.o riscv-v.o riscv-vsetvl.o
riscv-vector-costs.o"
+ extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o
riscv-shorten-memrefs.o riscv-selftests.o riscv-string.o"
+ extra_objs="${extra_objs} riscv-v.o riscv-vsetvl.o riscv-vector-costs.o"
extra_objs="${extra_objs} riscv-vector-builtins.o
riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
extra_objs="${extra_objs} thead.o"
d_target_objs="riscv-d.o"
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 6dbf6b9f943..b060d047f01 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -517,6 +517,9 @@ const unsigned int RISCV_BUILTIN_SHIFT = 1;
/* Mask that selects the riscv_builtin_class part of a function code. */
const unsigned int RISCV_BUILTIN_CLASS = (1 << RISCV_BUILTIN_SHIFT) - 1;
+/* Routines implemented
[PATCH v2 2/2] riscv: Add support for str(n)cmp inline expansion
From: Christoph Müllner
This patch implements expansions for the cmpstrsi and cmpstrnsi
builtins for RV32/RV64 for xlen-aligned strings if Zbb or XTheadBb
instructions are available. The expansion basically emits a comparison
sequence which compares XLEN bits per step if possible.
This allows to inline calls to strcmp() and strncmp() if both strings
are xlen-aligned. For strncmp() the length parameter needs to be known.
The benefits over calls to libc are:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment tests
The inlining mechanism is gated by a new switches ('-minline-strcmp' and
'-minline-strncmp') and by the variable 'optimize_size'.
The amount of emitted unrolled loop iterations can be controlled by the
parameter '--param=riscv-strcmp-inline-limit=N', which defaults to 64.
The comparision sequence is inspired by the strcmp example
in the appendix of the Bitmanip specification (incl. the fast
result calculation in case the first word does not contain
a NULL byte). Additional inspiration comes from rs6000-string.c.
The emitted sequence is not triggering any readahead pagefault issues,
because only aligned strings are accessed by aligned xlen-loads.
This patch has been tested using the glibc string tests on QEMU:
* rv64gc_zbb/rv64gc_xtheadbb with riscv-strcmp-inline-limit=64
* rv64gc_zbb/rv64gc_xtheadbb with riscv-strcmp-inline-limit=8
* rv32gc_zbb/rv32gc_xtheadbb with riscv-strcmp-inline-limit=64
Signed-off-by: Christoph Müllner
gcc/ChangeLog:
* config/riscv/bitmanip.md (*_not): Export INSN name.
(_not3): Likewise.
* config/riscv/riscv-protos.h (riscv_expand_strcmp): New
prototype.
* config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper
macros.
(GEN_EMIT_HELPER2): Likewise.
(emit_strcmp_scalar_compare_byte): New function.
(emit_strcmp_scalar_compare_subword): Likewise.
(emit_strcmp_scalar_compare_word): Likewise.
(emit_strcmp_scalar_load_and_compare): Likewise.
(emit_strcmp_scalar_call_to_libc): Likewise.
(emit_strcmp_scalar_result_calculation_nonul): Likewise.
(emit_strcmp_scalar_result_calculation): Likewise.
(riscv_expand_strcmp_scalar): Likewise.
(riscv_expand_strcmp): Likewise.
* config/riscv/riscv.md (*slt_): Export
INSN name.
(@slt_3): Likewise.
(cmpstrnsi): Invoke expansion function for str(n)cmp.
(cmpstrsi): Likewise.
* config/riscv/riscv.opt: Add new parameter
'-mstring-compare-inline-limit'.
* doc/invoke.texi: Document new parameter
'-mstring-compare-inline-limit'.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadbb-strcmp-unaligned.c: New test.
* gcc.target/riscv/xtheadbb-strcmp.c: New test.
* gcc.target/riscv/zbb-strcmp-disabled-2.c: New test.
* gcc.target/riscv/zbb-strcmp-disabled.c: New test.
* gcc.target/riscv/zbb-strcmp-unaligned.c: New test.
* gcc.target/riscv/zbb-strcmp.c: New test.
---
gcc/config/riscv/bitmanip.md | 2 +-
gcc/config/riscv/riscv-protos.h | 1 +
gcc/config/riscv/riscv-string.cc | 411 ++
gcc/config/riscv/riscv.md | 44 +-
gcc/config/riscv/riscv.opt| 12 +
gcc/doc/invoke.texi | 20 +-
.../gcc.target/riscv/xtheadbb-strcmp.c| 57 +++
.../gcc.target/riscv/zbb-strcmp-disabled-2.c | 38 ++
.../gcc.target/riscv/zbb-strcmp-disabled.c| 38 ++
.../gcc.target/riscv/zbb-strcmp-limit.c | 57 +++
.../gcc.target/riscv/zbb-strcmp-unaligned.c | 38 ++
gcc/testsuite/gcc.target/riscv/zbb-strcmp.c | 57 +++
12 files changed, 772 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strcmp.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-disabled-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-disabled.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-limit.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-unaligned.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp.c
diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index 1544ef4e125..1e90636dd60 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -206,7 +206,7 @@ (define_expand "popcount2"
(popcount:GPR (match_operand:GPR 1 "register_operand")))]
"TARGET_ZBB")
-(define_insn "*_not"
+(define_insn "_not3"
[(set (match_operand:X 0 "register_operand" "=r")
(bitmanip_bitwise:X (not:X (match_operand:X 1 "register_operand" "r"))
(match_operand:X 2 "register_operand" "r")))]
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index b060d047f01..0006fe0564e 100644
--- a/gcc/config/riscv/riscv-protos.h
+++
[PATCH v2 0/2] riscv: Introduce strlen/strcmp/strncmp inline expansion
From: Christoph Müllner This series introduces strlen/strcmp/strncmp inline expansion for Zbb/XTheadBb. In the last months, glibc as well as the Linux kernel merged changes for optimized string processing for RISC-V. The instruction, which enables optimized string routines is Zbb's orc.b (or T-Head's th.tstnbz) instruction. This patch attempts to add optimized string processing to GCC with the following properties: * strlen: inline a loop if the string is xlen-aligned * strcmp/strncmp: inline a peeled comparison loop sequence if both strings are xlen-aligned I've already posted the idea in a previous series last November (therefore, this series is called 'v2'): * https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605996.html * https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605998.html Back then, there were a couple of comments, which have been addressed, but the str(n)cmp patch has been restructured to make the code easier to digest. In total the following changes are made: * Address Jeff's comments for the strlen patch * Change str(n)cmp flags according to Kito's comments * Ensure that all flags are documented * Break str(n)cmp expansion into several functions * Add support for XTheadBb's th.tstnbz I have not introduced "-minline-str[n]cmp=[bitmanip|vector|auto]" or "-mstringop-strategy=alg" because we only have one bitmanip/scalar expansion. But it is possible to add this in the future (or not and decide based on mtune). By default all optimizations are disabled, so there should be no risk of regressions. Testing was done using the following strategy: * Enablement/flag tests are part of the patches * Correctness was tested using qemu-user with glibc's string tests compiled for: ** rv64gc (baseline) QEMU_CPU=rv64 ** rv64gc_zbb (limit=64) QEMU_CPU=rv64,zbb=false (must fail) ** rv64gc_zbb (limit=64) QEMU_CPU=rv64,zbb=true ** rv64gc_zbb (limit=32) QEMU_CPU=rv64,zbb=true ** rv64gc_xtheadbb (limit=64) QEMU_CPU=rv64 (must fail) ** rv64gc_xtheadbb (limit=64) QEMU_CPU=thead-c906 ** rv64gc_xtheadbb (limit=8) QEMU_CPU=thead-c906 ** rv32gc_zbb (limit=64) QEMU_CPU=rv32,zbb=true * SPEC CPU 2017 intrate base/peak with LTO Christoph Müllner (2): riscv: Add support for strlen inline expansion riscv: Add support for str(n)cmp inline expansion gcc/config.gcc| 3 +- gcc/config/riscv/bitmanip.md | 2 +- gcc/config/riscv/riscv-protos.h | 4 + gcc/config/riscv/riscv-string.cc | 594 ++ gcc/config/riscv/riscv.md | 72 ++- gcc/config/riscv/riscv.opt| 16 + gcc/config/riscv/t-riscv | 6 + gcc/config/riscv/thead.md | 9 +- gcc/doc/invoke.texi | 29 +- gcc/emit-rtl.cc | 24 + gcc/rtl.h | 2 + .../gcc.target/riscv/xtheadbb-strcmp.c| 57 ++ .../riscv/xtheadbb-strlen-unaligned.c | 14 + .../gcc.target/riscv/xtheadbb-strlen.c| 19 + .../gcc.target/riscv/zbb-strcmp-disabled-2.c | 38 ++ .../gcc.target/riscv/zbb-strcmp-disabled.c| 38 ++ .../gcc.target/riscv/zbb-strcmp-limit.c | 57 ++ .../gcc.target/riscv/zbb-strcmp-unaligned.c | 38 ++ gcc/testsuite/gcc.target/riscv/zbb-strcmp.c | 57 ++ .../gcc.target/riscv/zbb-strlen-disabled-2.c | 15 + .../gcc.target/riscv/zbb-strlen-disabled.c| 15 + .../gcc.target/riscv/zbb-strlen-unaligned.c | 14 + gcc/testsuite/gcc.target/riscv/zbb-strlen.c | 19 + 23 files changed, 1137 insertions(+), 5 deletions(-) create mode 100644 gcc/config/riscv/riscv-string.cc create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strcmp.c create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen-unaligned.c create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen.c create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-disabled-2.c create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-disabled.c create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-limit.c create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-unaligned.c create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp.c create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled-2.c create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled.c create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-unaligned.c create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen.c -- 2.41.0
[committed 10/12 v2] C _BitInt support [PR102989]
Hi!
Thanks for the patch reviews (and to Richi and Uros as well) and everyone
who participated in discussions.
Here is the updated version of the C _BitInt support [PR102989] patch
I've committed to trunk in addition to the rest of the series (except the
_BitInt a ? ~b : b match.pd fix patch, which will need to be resolved
eventually).
On Tue, Sep 05, 2023 at 10:40:26PM +, Joseph Myers wrote:
> Maybe c-ada-spec.cc, though it might be best to ask
> the Ada maintainers there.
I've skipped c-ada-spec.cc and will file a PR for Ada maintainers,
it is up to them to decide what they want and how to implement that.
2023-09-06 Jakub Jelinek
PR c/102989
gcc/
* glimits.h (BITINT_MAXWIDTH): Define if __BITINT_MAXWIDTH__ is
predefined.
gcc/c-family/
* c-common.cc (c_common_reswords): Add _BitInt as keyword.
(unsafe_conversion_p): Handle BITINT_TYPE like INTEGER_TYPE.
(c_common_signed_or_unsigned_type): Handle BITINT_TYPE.
(c_common_truthvalue_conversion, c_common_get_alias_set,
check_builtin_function_arguments): Handle BITINT_TYPE like
INTEGER_TYPE.
(sync_resolve_size): Add ORIG_FORMAT argument. If
FETCH && !ORIG_FORMAT, type is BITINT_TYPE, return -1 if size isn't
one of 1, 2, 4, 8 or 16 or if it is 16 but TImode is not supported.
(atomic_bitint_fetch_using_cas_loop): New function.
(resolve_overloaded_builtin): Adjust sync_resolve_size caller. If
-1 is returned, use atomic_bitint_fetch_using_cas_loop to lower it.
Formatting fix.
(keyword_begins_type_specifier): Handle RID_BITINT.
* c-common.h (enum rid): Add RID_BITINT enumerator.
* c-cppbuiltin.cc (c_cpp_builtins): For C call
targetm.c.bitint_type_info and predefine __BITINT_MAXWIDTH__
and for -fbuilding-libgcc also __LIBGCC_BITINT_LIMB_WIDTH__ and
__LIBGCC_BITINT_ORDER__ macros if _BitInt is supported.
* c-lex.cc (interpret_integer): Handle CPP_N_BITINT.
* c-pretty-print.cc (c_pretty_printer::simple_type_specifier,
c_pretty_printer::direct_abstract_declarator,
c_pretty_printer::direct_declarator, c_pretty_printer::declarator):
Handle BITINT_TYPE.
(pp_c_integer_constant): Handle printing of large precision wide_ints
which would buffer overflow digit_buffer.
* c-warn.cc (conversion_warning, warnings_for_convert_and_check,
warnings_for_convert_and_check): Handle BITINT_TYPE like
INTEGER_TYPE.
gcc/c/
* c-convert.cc (c_convert): Handle BITINT_TYPE like INTEGER_TYPE.
* c-decl.cc (check_bitfield_type_and_width): Allow BITINT_TYPE
bit-fields.
(finish_struct): Prefer to use BITINT_TYPE for BITINT_TYPE bit-fields
if possible.
(declspecs_add_type): Formatting fixes. Handle cts_bitint. Adjust
for added union in *specs. Handle RID_BITINT.
(finish_declspecs): Handle cts_bitint. Adjust for added union
in *specs.
* c-parser.cc (c_keyword_starts_typename, c_token_starts_declspecs,
c_parser_declspecs, c_parser_gnu_attribute_any_word): Handle
RID_BITINT.
(c_parser_omp_clause_schedule): Handle BITINT_TYPE like INTEGER_TYPE.
* c-tree.h (enum c_typespec_keyword): Mention _BitInt in comment.
Add cts_bitint enumerator.
(struct c_declspecs): Move int_n_idx and floatn_nx_idx into a union
and add bitint_prec there as well.
* c-typeck.cc (c_common_type, comptypes_internal):
Handle BITINT_TYPE.
(perform_integral_promotions): Promote BITINT_TYPE bit-fields to
their declared type.
(build_array_ref, build_unary_op, build_conditional_expr,
build_c_cast, convert_for_assignment, digest_init, build_binary_op):
Handle BITINT_TYPE.
* c-fold.cc (c_fully_fold_internal): Handle BITINT_TYPE like
INTEGER_TYPE.
* c-aux-info.cc (gen_type): Handle BITINT_TYPE.
libcpp/
* expr.cc (interpret_int_suffix): Handle wb and WB suffixes.
* include/cpplib.h (CPP_N_BITINT): Define.
--- gcc/glimits.h.jj2023-09-05 16:44:32.269305435 +0200
+++ gcc/glimits.h 2023-09-06 09:14:53.950335938 +0200
@@ -157,6 +157,11 @@ see the files COPYING3 and COPYING.RUNTI
# undef BOOL_WIDTH
# define BOOL_WIDTH 1
+# ifdef __BITINT_MAXWIDTH__
+# undef BITINT_MAXWIDTH
+# define BITINT_MAXWIDTH __BITINT_MAXWIDTH__
+# endif
+
# define __STDC_VERSION_LIMITS_H__ 202311L
#endif
--- gcc/c-family/c-common.cc.jj 2023-09-05 16:44:32.110307593 +0200
+++ gcc/c-family/c-common.cc2023-09-06 09:55:30.836992346 +0200
@@ -349,6 +349,7 @@ const struct c_common_resword c_common_r
{ "_Alignas",RID_ALIGNAS, D_CONLY },
{ "_Alignof",RID_ALIGNOF, D_CONLY },
{ "_Atomic", RID_ATOMIC,D_CONLY },
+ { "_BitInt", RID_BITINT,D_CONLY },
{ "_Bool", RID_BOOL, D_CONLY
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #110 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:52e270e847d240fb68a27c88ee60189515a6 commit r14-3759-g52e270e847d240fb68a27c88ee60189515a6 Author: Jakub Jelinek Date: Wed Sep 6 17:52:24 2023 +0200 Additional _BitInt test coverage [PR102989] On Tue, Sep 05, 2023 at 10:40:26PM +, Joseph Myers wrote: > Additional tests I think should be added (for things I expect should > already work): > > * Tests for BITINT_MAXWIDTH in . Test that it's defined for > C2x, but not defined for C11/C17 (the latter independent of whether the > target has _BitInt support). Test the value as well: _BitInt > (BITINT_MAXWIDTH) should be OK (both signed and unsigned) but _BitInt > (BITINT_MAXWIDTH + 1) should not be OK. Also test that BITINT_MAXWIDTH >= > ULLONG_MAX. > > * Test _BitInt (N) where N is a constexpr variable or enum constant (I > expect these should work - the required call to convert_lvalue_to_rvalue > for constexpr to work is present - but I don't see such tests in the > testsuite). > > * Test that -funsigned-bitfields does not affect the signedness of _BitInt > (N) bit-fields (the standard wording isn't entirely clear, but that's > what's implemented in the patches). > > * Test the errors for _Sat used with _BitInt (though such a test might not > actually run at present because no target supports both features). The following patch does that plus for most of the new changes in the C _BitInt support patch requested in patch review it also does testsuite coverage. 2023-09-06 Jakub Jelinek PR c/102989 * gcc.dg/bitint-2.c (foo): Add tests for constexpr var or enumerator arguments of _BitInt. * gcc.dg/bitint-31.c: Remove forgotten 0 &&. * gcc.dg/bitint-32.c: New test. * gcc.dg/bitint-33.c: New test. * gcc.dg/bitint-34.c: New test. * gcc.dg/bitint-35.c: New test. * gcc.dg/bitint-36.c: New test. * gcc.dg/fixed-point/bitint-1.c: New test.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #109 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:dce6f6a974d4ecce8491c989c35e23c59223f762
commit r14-3758-gdce6f6a974d4ecce8491c989c35e23c59223f762
Author: Jakub Jelinek
Date: Wed Sep 6 17:50:49 2023 +0200
Handle BITINT_TYPE in build_{,minus_}one_cst [PR102989]
Recent match.pd changes trigger ICE in build_minus_one_cst, apparently
I forgot to handle BITINT_TYPE in these (while I've handled it in
build_zero_cst).
2023-09-06 Jakub Jelinek
PR c/102989
* tree.cc (build_one_cst, build_minus_one_cst): Handle BITINT_TYPE
like INTEGER_TYPE.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #107 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c62c82dc98dcb7420498b7114bf4cd2ec1a81405 commit r14-3756-gc62c82dc98dcb7420498b7114bf4cd2ec1a81405 Author: Jakub Jelinek Date: Wed Sep 6 17:47:49 2023 +0200 Add further _BitInt <-> floating point tests [PR102989] Here are just the testsuite additions from libgcc _BitInt patch review. On Fri, Sep 01, 2023 at 09:48:22PM +, Joseph Myers wrote: > 1. Test overflowing conversions to integers (including from inf or NaN) > raise FE_INVALID. (Note: it's not specified in the standard whether > inexact conversions to integers raise FE_INEXACT or not, so testing that > seems less important.) This is in gcc.dg/bitint-28.c (FE_INVALID) and gcc.dg/bitint-29.c (FE_INEXACT) for binary and dfp/bitint-8.c new tests. > 2. Test conversions from integers to floating point raise FE_INEXACT when > inexact, together with FE_OVERFLOW when overflowing (while exact > conversions don't raise exceptions). This is in gcc.dg/bitint-30.c new test. > 3. Test conversions from integers to floating point respect the rounding > mode. This is in gcc.dg/bitint-31.c new test. > 4. Test converting floating-point values in the range (-1.0, 0.0] to both > unsigned and signed _BitInt; I didn't see such tests for binary floating > types, only for decimal types, and the decimal tests didn't include tests > of negative zero itself as the value converted to _BitInt. This is done as incremental changes to existing tests. > 5. Test conversions of noncanonical BID zero to integers (these tests > would be specific to BID). See below for a bug in this area. This is done in dfp/bitint-7.c test. 2023-09-06 Jakub Jelinek PR c/102989 * gcc.dg/torture/bitint-21.c (main): Add tests for -1 for signed only, -1 + epsilon, another (-1, 0) range value and -0. * gcc.dg/torture/bitint-22.c (main): Likewise. * gcc.dg/bitint-28.c: New test. * gcc.dg/bitint-29.c: New test. * gcc.dg/bitint-30.c: New test. * gcc.dg/bitint-31.c: New test. * gcc.dg/dfp/bitint-1.c (main): Add tests for -1 for signed only, -1 + epsilon and -0. * gcc.dg/dfp/bitint-2.c (main): Likewise. * gcc.dg/dfp/bitint-3.c (main): Likewise. * gcc.dg/dfp/bitint-7.c: New test. * gcc.dg/dfp/bitint-8.c: New test.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #104 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a2f50aa2c578eb0572935e61818e1f2b18b53fd6 commit r14-3753-ga2f50aa2c578eb0572935e61818e1f2b18b53fd6 Author: Jakub Jelinek Date: Wed Sep 6 17:37:53 2023 +0200 testsuite part 2 for _BitInt support [PR102989] This is second part of the testcase additions in order to fit into mailing lists limits. Most of these tests are for the floating point conversions, atomics, __builtin_*_overflow and -fsanitize=undefined. 2023-09-06 Jakub Jelinek PR c/102989 gcc/testsuite/ * gcc.dg/torture/bitint-20.c: New test. * gcc.dg/torture/bitint-21.c: New test. * gcc.dg/torture/bitint-22.c: New test. * gcc.dg/torture/bitint-23.c: New test. * gcc.dg/torture/bitint-24.c: New test. * gcc.dg/torture/bitint-25.c: New test. * gcc.dg/torture/bitint-26.c: New test. * gcc.dg/torture/bitint-27.c: New test. * gcc.dg/torture/bitint-28.c: New test. * gcc.dg/torture/bitint-29.c: New test. * gcc.dg/torture/bitint-30.c: New test. * gcc.dg/torture/bitint-31.c: New test. * gcc.dg/torture/bitint-32.c: New test. * gcc.dg/torture/bitint-33.c: New test. * gcc.dg/torture/bitint-34.c: New test. * gcc.dg/torture/bitint-35.c: New test. * gcc.dg/torture/bitint-36.c: New test. * gcc.dg/torture/bitint-37.c: New test. * gcc.dg/torture/bitint-38.c: New test. * gcc.dg/torture/bitint-39.c: New test. * gcc.dg/torture/bitint-40.c: New test. * gcc.dg/torture/bitint-41.c: New test. * gcc.dg/torture/bitint-42.c: New test. * gcc.dg/atomic/stdatomic-bitint-1.c: New test. * gcc.dg/atomic/stdatomic-bitint-2.c: New test. * gcc.dg/dfp/bitint-1.c: New test. * gcc.dg/dfp/bitint-2.c: New test. * gcc.dg/dfp/bitint-3.c: New test. * gcc.dg/dfp/bitint-4.c: New test. * gcc.dg/dfp/bitint-5.c: New test. * gcc.dg/dfp/bitint-6.c: New test. * gcc.dg/ubsan/bitint-1.c: New test. * gcc.dg/ubsan/bitint-2.c: New test. * gcc.dg/ubsan/bitint-3.c: New test.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #105 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f76ae4369cb6f38e17510704e5b6e53847d2a648
commit r14-3754-gf76ae4369cb6f38e17510704e5b6e53847d2a648
Author: Jakub Jelinek
Date: Wed Sep 6 17:39:15 2023 +0200
C _BitInt incremental fixes [PR102989]
On Wed, Aug 09, 2023 at 09:17:57PM +, Joseph Myers wrote:
> > - _Complex _BitInt(N) isn't supported; again mainly because none of the
psABIs
> > mention how those should be passed/returned; in a limited way they
are
> > supported internally because the internal functions into which
> > __builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE
as a
> > hack to return 2 values without using references/pointers
>
> What happens when the usual arithmetic conversions are applied to
> operands, one of which is a complex integer type and the other of which
is
> a wider _BitInt type? I don't see anything in the code to disallow this
> case (which would produce an expression with a _Complex _BitInt type), or
> any testcases for it.
I've added a sorry for that case (+ return the narrower COMPLEX_TYPE).
Also added testcase to verify we don't create VECTOR_TYPEs of BITINT_TYPE
even if they have mode precision and suitable size (others were rejected
already before).
> Other testcases I think should be present (along with any corresponding
> changes needed to the code itself):
>
> * Verifying that the new integer constant suffix is rejected for C++.
Done.
> * Verifying appropriate pedwarn-if-pedantic for the new constant suffix
> for versions of C before C2x (and probably for use of _BitInt type
> specifiers before C2x as well) - along with the expected -Wc11-c2x-compat
> handling (in C2x mode) / -pedantic -Wno-c11-c2x-compat in older modes.
Done.
Here is an incremental patch which does that.
2023-09-06 Jakub Jelinek
PR c/102989
gcc/c/
* c-decl.cc (finish_declspecs): Emit pedwarn_c11 on _BitInt.
* c-typeck.cc (c_common_type): Emit sorry for common type between
_Complex integer and larger _BitInt and return the _Complex
integer.
gcc/c-family/
* c-attribs.cc (type_valid_for_vector_size): Reject vector types
with BITINT_TYPE elements even if they have mode precision and
suitable size.
gcc/testsuite/
* gcc.dg/bitint-19.c: New test.
* gcc.dg/bitint-20.c: New test.
* gcc.dg/bitint-21.c: New test.
* gcc.dg/bitint-22.c: New test.
* gcc.dg/bitint-23.c: New test.
* gcc.dg/bitint-24.c: New test.
* gcc.dg/bitint-25.c: New test.
* gcc.dg/bitint-26.c: New test.
* gcc.dg/bitint-27.c: New test.
* g++.dg/ext/bitint1.C: New test.
* g++.dg/ext/bitint2.C: New test.
* g++.dg/ext/bitint3.C: New test.
* g++.dg/ext/bitint4.C: New test.
libcpp/
* expr.cc (cpp_classify_number): Diagnose wb literal suffixes
for -pedantic* before C2X or -Wc11-c2x-compat.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #106 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f6e0ec5696ec5f52baed71fe23f978bcef80d458
commit r14-3755-gf6e0ec5696ec5f52baed71fe23f978bcef80d458
Author: Jakub Jelinek
Date: Wed Sep 6 17:42:37 2023 +0200
libgcc _BitInt helper documentation [PR102989]
On Mon, Aug 21, 2023 at 05:32:04PM +, Joseph Myers wrote:
> I think the libgcc functions (i.e. those exported by libgcc, to which
> references are generated by the compiler) need documenting in
libgcc.texi.
> Internal functions or macros in the libgcc patch need appropriate
comments
> specifying their semantics; especially FP_TO_BITINT and FP_FROM_BITINT
> which have a lot of arguments and no comments saying what the semantics
of
> the macros and their arguments are supposed to me.
Here is an incremental patch which does that.
2023-09-06 Jakub Jelinek
PR c/102989
gcc/
* doc/libgcc.texi (Bit-precise integer arithmetic functions):
Document general rules for _BitInt support library functions
and document __mulbitint3 and __divmodbitint4.
(Conversion functions): Document __fix{s,d,x,t}fbitint,
__floatbitint{s,d,x,t,h,b}f, __bid_fix{s,d,t}dbitint and
__bid_floatbitint{s,d,t}d.
libgcc/
* libgcc2.c (bitint_negate): Add function comment.
* soft-fp/bitint.h (bitint_negate): Add function comment.
(FP_TO_BITINT, FP_FROM_BITINT): Add comment explaining the macros.
