Re: Re: [PATCH] LoongArch: fix MUSL_DYNAMIC_LINKER

[樊鹏]

Yes, https://wiki.musl-libc.org/guidelines-for-distributions.html, 
"Multilib/multi-arch" section of this
introduces it.


> -Original Messages-
> From: "Xi Ruoyao" 
> Sent Time:2023-04-17 14:36:52 (星期一)
> To: "Peng Fan" , gcc-patches@gcc.gnu.org
> Cc: chengl...@loongson.cn
> Subject: Re: [PATCH] LoongArch: fix MUSL_DYNAMIC_LINKER
> 
> On Mon, 2023-04-17 at 10:39 +0800, Peng Fan wrote:
> > The system based on musl has no '/lib64', so change it.
> 
> I like the change.  IMO Glibc-based systems should avoid /lib64 as well
> but it's too late to change it now.
> 
> Could you provide a link to the Musl doc as a reference?  I'd like to
> include the link in the commit message.
> 
> > gcc/
> > * config/loongarch/gnu-user.h (MUSL_DYNAMIC_LINKER): Redefine.
> > 
> > Signed-off-by: Peng Fan 
> > ---
> >  gcc/config/loongarch/gnu-user.h | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/gcc/config/loongarch/gnu-user.h
> > b/gcc/config/loongarch/gnu-user.h
> > index aecaa02a199..fa1a5211419 100644
> > --- a/gcc/config/loongarch/gnu-user.h
> > +++ b/gcc/config/loongarch/gnu-user.h
> > @@ -33,9 +33,14 @@ along with GCC; see the file COPYING3.  If not see
> >  #define GLIBC_DYNAMIC_LINKER \
> >    "/lib" ABI_GRLEN_SPEC "/ld-linux-loongarch-" ABI_SPEC ".so.1"
> >  
> > +#define MUSL_ABI_SPEC \
> > +  "%{mabi=lp64d:-lp64d}" \
> > +  "%{mabi=lp64f:-lp64f}" \
> > +  "%{mabi=lp64s:-lp64s}"
> > +
> >  #undef MUSL_DYNAMIC_LINKER
> >  #define MUSL_DYNAMIC_LINKER \
> > -  "/lib" ABI_GRLEN_SPEC "/ld-musl-loongarch-" ABI_SPEC ".so.1"
> > +  "/lib/ld-musl-loongarch" ABI_GRLEN_SPEC MUSL_ABI_SPEC ".so.1"
> >  
> >  #undef GNU_USER_TARGET_LINK_SPEC
> >  #define GNU_USER_TARGET_LINK_SPEC \
> 
> -- 
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University


本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。
 
This email and its attachments contain confidential information from Loongson 
Technology , which is intended only for the person or entity whose address is 
listed above. Any use of the information contained herein in any way 
(including, but not limited to, total or partial disclosure, reproduction or 
dissemination) by persons other than the intended recipient(s) is prohibited. 
If you receive this email in error, please notify the sender by phone or email 
immediately and delete it. 

Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit

[Richard Biener via Gcc-patches]

On Fri, 14 Apr 2023, Hans-Peter Nilsson wrote:

> On Thu, 13 Apr 2023, Richard Biener via Gcc-patches wrote:
> 
> > On Thu, 13 Apr 2023, Richard Sandiford wrote:
> > 
> > > ???  writes:
> > > > Yeah, like kito said.
> > > > Turns out the tuple type model in ARM SVE is the optimal solution for 
> > > > RVV.
> > > > And we like ARM SVE style implmentation.
> > > >
> > > > And now we see swapping rtx_code and mode in rtx_def can make rtx_def 
> > > > overal not exceed 64 bit.
> > > > But it seems that there is still problem in tree_type_common and 
> > > > tree_decl_common, is that right?
> > > 
> > > I thought upthread we had a way forward for tree_type_common and
> > > tree_decl_common too, but maybe I only convinced myself. :)
> > > 
> > > > After several trys (remove all redundant TI/TF vector modes and FP16 
> > > > vector mode), now there are 252 modes
> > > > in RISC-V port. Basically, I can keep supporting new RVV intrinsisc 
> > > > features recently.
> > > > However, we can't support more in the future, for example, FP16 vector, 
> > > > BF16 vector, matrix modes, VLS modes,...etc.
> > > 
> > > I agree it doesn't make sense to try to squeeze modes out like this.
> > > It's a bit artificial, and like you say, it's likely only putting
> > > off the inevitable.
> > 
> > Agreed.  Let's do the proposed TYPE_PRECISION change first and then
> > see how bad 16bit mode will be.
> 
> (I don't see the following obvious having been pointed out, or 
> why it doesn't apply, but if so, I hope you don't mind repeating 
> it, so:)
> 
> If after all, a change to the size of the code and mode 
> bit-fields in rtx_def is necessary, like to still fit 64 bytes 
> such become non-byte sizes *and* that matters for compilation 
> time, can that change please be made target-dependent?  Not as 
> in set by a target macro, but rather deduced from the number of 
> modes defined by the target?
> 
> After all, that number is readily available (or if there's an 
> order problem seems likely to easily be made available to the 
> rtx_def build-time definition (as opposed to a gen-* -time 
> definition).

But it gets us in the "wrong" direction with the goal of having
pluggable targets (aka a multi-target compiler)?

Anyway, I suggest we'll see how the space requirements work out.
We should definitely try hard to put the fields on a byte
boundary so accesses become at most a load + and.

Richard.

Re: [PATCH] LoongArch: fix MUSL_DYNAMIC_LINKER

[Xi Ruoyao via Gcc-patches]

On Mon, 2023-04-17 at 10:39 +0800, Peng Fan wrote:
> The system based on musl has no '/lib64', so change it.

I like the change.  IMO Glibc-based systems should avoid /lib64 as well
but it's too late to change it now.

Could you provide a link to the Musl doc as a reference?  I'd like to
include the link in the commit message.

> gcc/
> * config/loongarch/gnu-user.h (MUSL_DYNAMIC_LINKER): Redefine.
> 
> Signed-off-by: Peng Fan 
> ---
>  gcc/config/loongarch/gnu-user.h | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config/loongarch/gnu-user.h
> b/gcc/config/loongarch/gnu-user.h
> index aecaa02a199..fa1a5211419 100644
> --- a/gcc/config/loongarch/gnu-user.h
> +++ b/gcc/config/loongarch/gnu-user.h
> @@ -33,9 +33,14 @@ along with GCC; see the file COPYING3.  If not see
>  #define GLIBC_DYNAMIC_LINKER \
>    "/lib" ABI_GRLEN_SPEC "/ld-linux-loongarch-" ABI_SPEC ".so.1"
>  
> +#define MUSL_ABI_SPEC \
> +  "%{mabi=lp64d:-lp64d}" \
> +  "%{mabi=lp64f:-lp64f}" \
> +  "%{mabi=lp64s:-lp64s}"
> +
>  #undef MUSL_DYNAMIC_LINKER
>  #define MUSL_DYNAMIC_LINKER \
> -  "/lib" ABI_GRLEN_SPEC "/ld-musl-loongarch-" ABI_SPEC ".so.1"
> +  "/lib/ld-musl-loongarch" ABI_GRLEN_SPEC MUSL_ABI_SPEC ".so.1"
>  
>  #undef GNU_USER_TARGET_LINK_SPEC
>  #define GNU_USER_TARGET_LINK_SPEC \

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH] tree-optimization/109304 - properly handle instrumented aliases

[Richard Biener via Gcc-patches]

On Fri, 14 Apr 2023, Jan Hubicka wrote:

> > On Tue, 4 Apr 2023, Jan Hubicka wrote:
> > 
> > > > On Tue, 28 Mar 2023, Richard Biener wrote:
> > > > 
> > > > > When adjusting calls to reflect instrumentation we failed to handle
> > > > > calls to aliases since they appear to have no body.  Instead resort
> > > > > to symtab node availability.  The patch also avoids touching
> > > > > internal function calls in a more obvious way (builtins might
> > > > > have a body available).
> > > > > 
> > > > > profiledbootstrap & regtest running on x86_64-unknown-linux-gnu.
> > > > > 
> > > > > Honza - does this look OK?
> > > > >   PR tree-optimization/109304
> > > > >   * tree-profile.cc (tree_profiling): Use symtab node
> > > > >   availability to decide whether to skip adjusting calls.
> > > > >   Do not adjust calls to internal functions.
> > > > > @@ -842,12 +842,15 @@ tree_profiling (void)
> > > > >   for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next 
> > > > > (&gsi))
> > > > > {
> > > > >   gcall *call = dyn_cast  (gsi_stmt (gsi));
> > > > > - if (!call)
> > > > > + if (!call || gimple_call_internal_p (call))
> > > > > continue;
> > > > >  
> > > > >   /* We do not clear pure/const on decls without body.  */
> > > > >   tree fndecl = gimple_call_fndecl (call);
> > > > > - if (fndecl && !gimple_has_body_p (fndecl))
> > > > > + cgraph_node *callee;
> > > > > + if (fndecl
> > > > > + && (callee = cgraph_node::get (fndecl))
> > > > > + && callee->get_availability (node) == 
> > > > > AVAIL_NOT_AVAILABLE)
> > > 
> > > As discussed earlier, the testcase I posted can be adjusted to put the
> > > const declared wrapper into another translation unit, so I think we will
> > > need to drop the visibility check completely.  But as discussed, it is
> > > wrong code issue, but not a regression, so we may go with the
> > > availability check as you suggest. So the patch is OK. 
> > > 
> > > 
> > > I wonder if we do not want to drop it everywhere (as we plan for next
> > > stage1 anyway).  I think similar ICE as in the PR can be produced with
> > > LTO. In normal situation declaration merging will do the right thing:
> > > If you have unit A calling const foo externally, it won't get processed
> > > by the code above.  However unit B declaring foo will get it downgraded
> > > to non-const.
> > > 
> > > Now at WPA time we will read both A and B and in declaration merging B's
> > > definition will prevail.  This won't happen if lto_symtab_merge_p
> > > returns false which can probably be triggered by adding warning/error
> > > attribute to B's declaration but not to A's.
> > > 
> > > It is however really side case and I am worried about dropping
> > > pure/const from builtin declarations...
> > 
> > Yeah, that's what I'm worried about as well.  I guess we'd need to
> > do the demotion to non-const/pure at WPA time and have a flag
> > in the cgraph node indicating instrument_add_{read,write}?  But
> > then how should we deal with C++ comdats instrumented in one TU
> > but not in another?  Does this mean we should do instrumentation
> > at IPA time instead of as small IPA pass before IPA?
> 
> I do not think LTO is of any help here.  You can allways call non-LTO
> const function from outer-world and that function can will end up
> calling back to instrumented const function in your unit which
> effectively makes the extenral const function non-const.

Hmm, true.

> > 
> > That said, when there's a definition of say strlen in a TU and
> > that's instrumented we do want to drop pure from calls but if
> > not then we shouldn't worry.
> > 
> > Without LTO we'd still run into coverage issues but at least
> > with LTO we shouldn't ICE?
> 
> I am not sure I see your point here...
> We could avoid demoting builtins to avoid ICEs and have coverage
> mismathces, but how LTO makes difference?

At least we get more functions local, but yes, we can still trigger
the issue.

So what's the solution?  All functions that are not leaf or possibly
instrumented have to be called as if they were not pure/const,
including builtins?  As we've said we're going to ICE quite a bit
when const/pure builtins suddenly are no longer const/pure.

Richard.

[PATCH] libstdc++: Adding missing feature-test macros for C++23 ranges algos

[Patrick Palka via Gcc-patches]

This patch also renames __cpp_lib_fold to __cpp_lib_ranges_fold
as per the current draft standard.

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__cpp_lib_ranges_contains):
Define for C++23.
(__cpp_lib_ranges_iota): Likewise.
(__cpp_lib_ranges_find_last): Likewise.
(__cpp_lib_fold): Rename to ...
(__cpp_lib_ranges_fold): ... this.
* include/std/version: As above.
* testsuite/25_algorithms/fold_left/1.cc: Adjust after
renaming __cpp_lib_fold.
* testsuite/std/ranges/version_c++23.cc: Verify values
of the above feature-test macros.
---
 libstdc++-v3/include/bits/ranges_algo.h  |  9 -
 libstdc++-v3/include/std/version |  5 -
 .../testsuite/25_algorithms/fold_left/1.cc   |  4 ++--
 .../testsuite/std/ranges/version_c++23.cc| 16 
 4 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index f041ff16b0e..410d3ae1dd8 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -3468,6 +3468,9 @@ namespace ranges
   inline constexpr __prev_permutation_fn prev_permutation{};
 
 #if __cplusplus > 202002L
+
+#define __cpp_lib_ranges_contains 202207L
+
   struct __contains_fn
   {
 template _Sent,
@@ -3521,6 +3524,8 @@ namespace ranges
 
   inline constexpr __contains_subrange_fn contains_subrange{};
 
+#define __cpp_lib_ranges_iota 202202L
+
   template
 struct out_value_result
 {
@@ -3569,6 +3574,8 @@ namespace ranges
 
   inline constexpr __iota_fn iota{};
 
+#define __cpp_lib_ranges_find_last 202207L
+
   struct __find_last_fn
   {
 template _Sent, typename _Tp, 
typename _Proj = identity>
@@ -3695,7 +3702,7 @@ namespace ranges
 
   inline constexpr __find_last_if_not_fn find_last_if_not{};
 
-#define __cpp_lib_fold 202207L
+#define __cpp_lib_ranges_fold 202207L
 
   template
 struct in_value_result
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 9f31f25f1e9..027e5711ec5 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -341,7 +341,10 @@
 #define __cpp_lib_ranges_as_rvalue 202207L
 #define __cpp_lib_ranges_as_const 202207L
 #define __cpp_lib_ranges_enumerate 202302L
-#define __cpp_lib_fold 202207L
+#define __cpp_lib_ranges_contains 202207L
+#define __cpp_lib_ranges_iota 202202L
+#define __cpp_lib_ranges_find_last 202207L
+#define __cpp_lib_ranges_fold 202207L
 #if __cpp_constexpr_dynamic_alloc
 # if _GLIBCXX_HOSTED
 #  define __cpp_lib_constexpr_bitset 202202L
diff --git a/libstdc++-v3/testsuite/25_algorithms/fold_left/1.cc 
b/libstdc++-v3/testsuite/25_algorithms/fold_left/1.cc
index 5cc91b67d27..4041d13315f 100644
--- a/libstdc++-v3/testsuite/25_algorithms/fold_left/1.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/fold_left/1.cc
@@ -5,8 +5,8 @@
 #include 
 #include 
 
-#if __cpp_lib_fold != 202207L
-# error "Feature-test macro __cpp_lib_fold has wrong value in "
+#if __cpp_lib_ranges_fold != 202207L
+# error "Feature-test macro __cpp_lib_ranges_fold has wrong value in 
"
 #endif
 
 namespace ranges = std::ranges;
diff --git a/libstdc++-v3/testsuite/std/ranges/version_c++23.cc 
b/libstdc++-v3/testsuite/std/ranges/version_c++23.cc
index e2c14edc8ef..04609bb602c 100644
--- a/libstdc++-v3/testsuite/std/ranges/version_c++23.cc
+++ b/libstdc++-v3/testsuite/std/ranges/version_c++23.cc
@@ -52,3 +52,19 @@
 #if __cpp_lib_ranges_enumerate != 202302L
 # error "Feature-test macro __cpp_lib_ranges_enumerate has wrong value in 
"
 #endif
+
+#if __cpp_lib_ranges_contains != 202207L
+# error "Feature-test macro __cpp_lib_ranges_contains has wrong value in 
"
+#endif
+
+#if __cpp_lib_ranges_iota != 202202L
+# error "Feature-test macro __cpp_lib_ranges_iota has wrong value in "
+#endif
+
+#if __cpp_lib_ranges_find_last != 202207L
+# error "Feature-test macro __cpp_lib_ranges_find_last has wrong value in 
"
+#endif
+
+#if __cpp_lib_ranges_fold != 202207L
+# error "Feature-test macro __cpp_lib_ranges_fold has wrong value in "
+#endif
-- 
2.40.0.335.g9857273be0

[PATCH] libstdc++: Fix typo in views::as_const's operator() [PR109525]

[Patrick Palka via Gcc-patches]

PR libstdc++/109525

libstdc++-v3/ChangeLog:

* include/std/ranges (views::_AsConst::operator()): Add
missing const to constant_range test.
* testsuite/std/ranges/adaptors/as_const/1.cc (test02):
Improve formatting.  Adjust expected type of v2.
(test03): New test.
---
 libstdc++-v3/include/std/ranges   |  2 +-
 .../std/ranges/adaptors/as_const/1.cc | 37 ---
 2 files changed, 24 insertions(+), 15 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 283d757faa4..1714f3fb16c 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -9025,7 +9025,7 @@ namespace views::__adaptor
  return ref_view(static_cast
  (std::forward<_Range>(__r).base()));
else if constexpr (is_lvalue_reference_v<_Range>
-  && constant_range<_Tp>
+  && constant_range
   && !view<_Tp>)
  return ref_view(static_cast(__r));
else
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/as_const/1.cc 
b/libstdc++-v3/testsuite/std/ranges/adaptors/as_const/1.cc
index d04645f047e..ac1be7440e4 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/as_const/1.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/as_const/1.cc
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -36,29 +37,37 @@ test01()
 constexpr bool
 test02()
 {
-  std::same_as> auto v1
-= views::empty | views::as_const;
-
   int x[] = {1, 2, 3};
-  std::same_as>> auto v2
-= x | views::as_const;
-  std::same_as> auto v3
-= std::as_const(x) | views::as_const;
-  std::same_as> auto v4
-= std::as_const(x) | views::all | views::as_const;
-  std::same_as> auto v5
-= std::span{x, x+3} | views::as_const;
-
-  
std::same_as>>>
 auto v6
- = x | views::chunk(2) | views::as_const;
+  std::same_as>
+auto v1 = views::empty | views::as_const;
+  std::same_as>
+auto v2 = x | views::as_const;
+  std::same_as>
+auto v3 = std::as_const(x) | views::as_const;
+  std::same_as>
+auto v4 = std::as_const(x) | views::all | views::as_const;
+  std::same_as>
+auto v5 = std::span{x, x+3} | views::as_const;
+  
std::same_as>>>
+auto v6 = x | views::chunk(2) | views::as_const;
   VERIFY( v6.size() == 2 );
 
   return true;
 }
 
+void
+test03()
+{
+  // PR libstdc++/109525
+  std::vector v;
+  std::same_as>>
+auto r = views::as_const(v);
+}
+
 int
 main()
 {
   static_assert(test01());
   static_assert(test02());
+  test03();
 }
-- 
2.40.0.335.g9857273be0

Re: [PATCH 2/2] libstdc++: Implement range_adaptor_closure from P2387R3 [PR108827]

[Patrick Palka via Gcc-patches]

On Fri, 14 Apr 2023, Patrick Palka wrote:

> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> 
>   PR libstdc++/108827
> 
> libstdc++-v3/ChangeLog:
> 
>   * include/bits/ranges_cmp.h (__cpp_lib_ranges): Bump value
>   for C++23.
>   * include/std/ranges (range_adaptor_closure): Define for C++23.
>   * include/std/version (__cpp_lib_ranges): Bump value for
>   C++23.
>   * testsuite/std/ranges/version_c++23.cc: Bump expected value
>   of __cpp_lib_ranges.
>   * testsuite/std/ranges/range_adaptor_closure.cc: New test.

Here's a standalone version of this patch (not dependent on the first
patch in the series) it terms of the current non-CRTP representation
of _RangeAdaptorClosure:

-- >8 --

Subject: [PATCH] libstdc++: Implement range_adaptor_closure from P2387R3
 [PR108827]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

PR libstdc++/108827

libstdc++-v3/ChangeLog:

* include/bits/ranges_cmp.h (__cpp_lib_ranges): Bump value
for C++23.
* include/std/ranges (range_adaptor_closure): Define for C++23.
* include/std/version (__cpp_lib_ranges): Bump value for
C++23.
* testsuite/std/ranges/version_c++23.cc: Bump expected value
of __cpp_lib_ranges.
* testsuite/std/ranges/range_adaptor_closure.cc: New test.
---
 libstdc++-v3/include/bits/ranges_cmp.h|  4 ++
 libstdc++-v3/include/std/ranges   |  8 
 libstdc++-v3/include/std/version  |  3 ++
 .../std/ranges/range_adaptor_closure.cc   | 46 +++
 .../testsuite/std/ranges/version_c++23.cc |  2 +-
 5 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/range_adaptor_closure.cc

diff --git a/libstdc++-v3/include/bits/ranges_cmp.h 
b/libstdc++-v3/include/bits/ranges_cmp.h
index 85c1a77ccf7..6710d829a37 100644
--- a/libstdc++-v3/include/bits/ranges_cmp.h
+++ b/libstdc++-v3/include/bits/ranges_cmp.h
@@ -57,7 +57,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #ifdef __cpp_lib_concepts
 // Define this here, included by all the headers that need to define it.
+#if __cplusplus > 202002L
+#define __cpp_lib_ranges 202202L
+#else
 #define __cpp_lib_ranges 202110L
+#endif
 
 namespace ranges
 {
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 1714f3fb16c..c4d4d85bf90 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -1122,6 +1122,14 @@ namespace views::__adaptor
 };
 } // namespace views::__adaptor
 
+#if __cplusplus > 202002L
+  template
+requires is_class_v<_Derived> && same_as<_Derived, remove_cv_t<_Derived>>
+class range_adaptor_closure
+: public views::__adaptor::_RangeAdaptorClosure
+{ };
+#endif
+
   template requires is_object_v<_Range>
 class ref_view : public view_interface>
 {
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 027e5711ec5..02ead8f1443 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -265,8 +265,10 @@
 #define __cpp_lib_interpolate 201902L
 #if __cpp_lib_concepts
 # define __cpp_lib_move_iterator_concept 202207L
+#if __cplusplus <= 202002L // N.B. updated value in C++23
 # define __cpp_lib_ranges 202110L
 #endif
+#endif
 #define __cpp_lib_shift 201806L
 
 #if _GLIBCXX_HOSTED
@@ -330,6 +332,7 @@
 #define __cpp_lib_reference_from_temporary 202202L
 #define __cpp_lib_to_underlying 202102L
 #define __cpp_lib_unreachable 202202L
+#define __cpp_lib_ranges 202202L
 #define __cpp_lib_ranges_zip 202110L
 #define __cpp_lib_ranges_chunk 202202L
 #define __cpp_lib_ranges_slide 202202L
diff --git a/libstdc++-v3/testsuite/std/ranges/range_adaptor_closure.cc 
b/libstdc++-v3/testsuite/std/ranges/range_adaptor_closure.cc
new file mode 100644
index 000..6221f071331
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/ranges/range_adaptor_closure.cc
@@ -0,0 +1,46 @@
+// { dg-options "-std=gnu++23" }
+// { dg-do run { target c++23 } }
+
+#include 
+#include 
+#include 
+
+namespace ranges = std::ranges;
+namespace views = std::views;
+
+struct _Negate : ranges::range_adaptor_closure<_Negate>
+{
+  template
+  constexpr auto
+  operator()(_Range&& __r) const
+  requires requires { views::transform(std::declval<_Range>(), std::negate{}); 
}
+  { return views::transform(std::forward<_Range>(__r), std::negate{}); }
+};
+
+constexpr _Negate negate;
+
+constexpr bool
+test01()
+{
+  int x[] = {1, 2, 3};
+  VERIFY( ranges::equal(x | negate, (int[]){-1, -2, -3}) );
+  VERIFY( ranges::equal(x | negate | negate, x) );
+  VERIFY( ranges::equal(x | (negate | negate), x) );
+  VERIFY( ranges::equal(x | views::reverse | negate, x | negate | 
views::reverse) );
+  VERIFY( ranges::equal(x | (views::reverse | negate), x | (negate | 
views::reverse)) );
+#if 0
+  // These asserts currently fail for the same reason as the disabled asserts
+  // in std/ranges/adaptors/all.cc.
+  static_asser

Re: [PATCH 1/2] libstdc++: Convert _RangeAdaptorClosure into a CRTP class [PR108827]

[Patrick Palka via Gcc-patches]

On Fri, 14 Apr 2023, Patrick Palka wrote:

> Using the CRTP idiom for this base class avoids bloating the size of a
> pipeline when adding distinct empty range adaptor closure objects to it,
> as detailed in section 4.1 of P2387R3.
> 
> But it means we can no longer define its operator| overloads as hidden
> friends, since each instantiation of _RangeAdaptorClosure would then
> introduce its own logically different hidden friends.  So for example
> during overload resolution for the outer pipe operator in
> 
>  :x | (views::reverse | views::join)
> 
> we'd have to consider 6 different hidden operator| friends:
> 
>   2 from _RangeAdaptorClosure<_Reverse>
>   2 from _RangeAdaptorClosure<_Join>
>   2 from _RangeAdaptorClosure<_Pipe<_Reverse, _Join>>
> 
> which is wasteful and can even cause hard errors in some cases.  So we
> instead define the operator| overloads at namespace scope in an isolated
> namespace.

On second thought, since this doesn't fix a bug or add new functionality
it seems more like GCC 14 material.  The size reduction is nice but it's
probably not a big deal in practice since adaptor pipelines are usually
very transient objects that don't get passed around as function
arguments etc.

But perhaps the second patch implementing range_adaptor_closure would be
desirable for GCC 13?  I'll post an updated standalone version of that
patch for separate consideration.

> 
>   PR libstdc++/108827
> 
> libstdc++-v3/ChangeLog:
> 
>   * include/std/ranges (__adaptor::_RangeAdaptorClosure): Move ...
>   (__adaptor::__closure::_RangeAdaptorClosure): ... here and turn
>   it into a CRTP class template.  Move hidden operator| friends
>   into namespace scope and adjust their constraints.  Add a
>   using-declaration for this at __adaptor::_RangeAdaptorClosure.
>   (__closure::__is_range_adaptor_closure_fn): Define.
>   (__closure::__is_range_adaptor_closure): Define.
>   (__adaptor::_Partial): Adjust use of _RangeAdaptorClosure.
>   (__adaptor::_Pipe): Likewise.
>   (views::_All): Likewise.
>   (views::_Join): Likewise.
>   (views::_Common): Likewise.
>   (views::_Reverse): Likewise.
>   (views::_Elements): Likewise.
>   (views::_Adjacent): Likewise.
>   (views::_AsRvalue): Likewise.
>   (views::_Enumerate): Likewise.
>   (views::_AsConst): Likewise.
>   * testsuite/std/ranges/adaptors/all.cc: Reintroduce
>   static_assert expecting that adding empty range adaptor
>   closure objects to a pipeline doesn't increase the size of a
>   pipeline.
> ---
>  libstdc++-v3/include/std/ranges   | 69 +++
>  .../testsuite/std/ranges/adaptors/all.cc  |  7 --
>  2 files changed, 42 insertions(+), 34 deletions(-)
> 
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index 283d757faa4..531ec6f68b3 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -872,30 +872,45 @@ namespace views::__adaptor
>template
>  struct _Pipe;
>  
> -  // The base class of every range adaptor closure.
> -  //
> -  // The derived class should define the optional static data member
> -  // _S_has_simple_call_op to true if the behavior of this adaptor is
> -  // independent of the constness/value category of the adaptor object.
> -  struct _RangeAdaptorClosure
> +  namespace __closure
>{
> +// The base class of every range adaptor closure.
> +//
> +// The derived class should define the optional static data member
> +// _S_has_simple_call_op to true if the behavior of this adaptor is
> +// independent of the constness/value category of the adaptor object.
> +template
> +  struct _RangeAdaptorClosure
> +  { };
> +
> +template
> +  requires (!same_as<_Tp, _RangeAdaptorClosure<_Up>>)
> +  void __is_range_adaptor_closure_fn
> + (const _Tp&, const _RangeAdaptorClosure<_Up>&); // not defined
> +
> +template
> +  concept __is_range_adaptor_closure
> + = requires (_Tp __t) { __closure::__is_range_adaptor_closure_fn(__t, 
> __t); };
> +
>  // range | adaptor is equivalent to adaptor(range).
>  template
> -  requires derived_from, _RangeAdaptorClosure>
> +  requires __is_range_adaptor_closure<_Self>
>   && __adaptor_invocable<_Self, _Range>
> -  friend constexpr auto
> +  constexpr auto
>operator|(_Range&& __r, _Self&& __self)
>{ return std::forward<_Self>(__self)(std::forward<_Range>(__r)); }
>  
>  // Compose the adaptors __lhs and __rhs into a pipeline, returning
>  // another range adaptor closure object.
>  template
> -  requires derived_from<_Lhs, _RangeAdaptorClosure>
> - && derived_from<_Rhs, _RangeAdaptorClosure>
> -  friend constexpr auto
> +  requires __is_range_adaptor_closure<_Lhs>
> + && __is_range_adaptor_closure<_Rhs>
> +  constexpr auto
>operator|(_Lhs __lhs, _Rhs __rhs)
>{ return _Pip

Re: [PATCH] testsuite: update builtins-5-p9-runnable.c for BE

[guojiufu via Gcc-patches]

On 2023-04-14 17:09, Kewen.Lin wrote:

Hi Jeff,

on 2023/4/14 16:01, guojiufu wrote:

On 2023-04-14 15:30, Jiufu Guo wrote:

Hi,

As PR108809 mentioned, vec_xl_len_r and vec_xst_len_r are tested
in gcc.target/powerpc/builtins-5-p9-runnable.c.
The vector operand of these two bifs are different from the view
of v16_int8 between BE and LE, even it is same from the view of
128bits(uint128/V1TI).

The test case gcc.target/powerpc/builtins-5-p9-runnable.c was
written for LE environment, this patch updates it for BE.

Tested on ppc64 BE and LE.
Is this ok for trunk?

BR,
Jeff (Jiufu)

gcc/testsuite/ChangeLog:


    PR target/108809


s/target/testsuite/


* gcc.target/powerpc/builtins-5-p9-runnable.c: Updated.




s/Updated/Update for BE/

OK with these two nits fixed, thanks!


Thanks for the very helpful comments!
Committed via r13-7202-ga1f25e04b8d10b.


BR,
Jeff (Jiufu)



BR,
Kewen

[PATCH] LoongArch: fix MUSL_DYNAMIC_LINKER

[Peng Fan]

The system based on musl has no '/lib64', so change it.

gcc/
* config/loongarch/gnu-user.h (MUSL_DYNAMIC_LINKER): Redefine.

Signed-off-by: Peng Fan 
---
 gcc/config/loongarch/gnu-user.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/config/loongarch/gnu-user.h b/gcc/config/loongarch/gnu-user.h
index aecaa02a199..fa1a5211419 100644
--- a/gcc/config/loongarch/gnu-user.h
+++ b/gcc/config/loongarch/gnu-user.h
@@ -33,9 +33,14 @@ along with GCC; see the file COPYING3.  If not see
 #define GLIBC_DYNAMIC_LINKER \
   "/lib" ABI_GRLEN_SPEC "/ld-linux-loongarch-" ABI_SPEC ".so.1"
 
+#define MUSL_ABI_SPEC \
+  "%{mabi=lp64d:-lp64d}" \
+  "%{mabi=lp64f:-lp64f}" \
+  "%{mabi=lp64s:-lp64s}"
+
 #undef MUSL_DYNAMIC_LINKER
 #define MUSL_DYNAMIC_LINKER \
-  "/lib" ABI_GRLEN_SPEC "/ld-musl-loongarch-" ABI_SPEC ".so.1"
+  "/lib/ld-musl-loongarch" ABI_GRLEN_SPEC MUSL_ABI_SPEC ".so.1"
 
 #undef GNU_USER_TARGET_LINK_SPEC
 #define GNU_USER_TARGET_LINK_SPEC \
-- 
2.38.1

RE: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.

[Li, Pan2 via Gcc-patches]

Cool, thank you!

Pan

-Original Message-
From: Kito Cheng  
Sent: Monday, April 17, 2023 9:52 AM
To: Li, Pan2 
Cc: juzhe.zh...@rivai.ai; gcc-patches ; Kito.cheng 
; Wang, Yanzhang 
Subject: Re: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.

Pushed to trunk :)

On Mon, Apr 17, 2023 at 9:47 AM Li, Pan2 via Gcc-patches 
 wrote:
>
> BTW, this patch will be in GCC 13 or master? The underlying patches may 
> depend on this tests for ensuring correctness.
>
> Pan
>
> -Original Message-
> From: Li, Pan2
> Sent: Friday, April 14, 2023 2:47 PM
> To: Kito Cheng 
> Cc: juzhe.zh...@rivai.ai; gcc-patches ; 
> Kito.cheng ; Wang, Yanzhang 
> 
> Subject: RE: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.
>
> You're very welcome!
>
> Looks vmorn(v,v) doesn't perform any shortcut, while vmandn(v, v) will be 
> converted to vmclr in upstream. As I understand, there should be no 
> difference between vmORn and vmANDn excepts the operator, will take a look 
> from RTL CSE for more details, 😊!
>
> Pan
>
> -Original Message-
> From: Kito Cheng 
> Sent: Friday, April 14, 2023 2:42 PM
> To: Li, Pan2 
> Cc: juzhe.zh...@rivai.ai; gcc-patches ; 
> Kito.cheng ; Wang, Yanzhang 
> 
> Subject: Re: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.
>
> OK, thanks for the patch :)
>
> On Fri, Apr 14, 2023 at 11:27 AM Li, Pan2 via Gcc-patches 
>  wrote:
> >
> > Thanks juzhe, update new version [PATCH v3] for even more checks.
> >
> > Pan
> >
> > From: juzhe.zh...@rivai.ai 
> > Sent: Friday, April 14, 2023 10:46 AM
> > To: Li, Pan2 ; gcc-patches 
> > 
> > Cc: Kito.cheng ; Wang, Yanzhang 
> > ; Li, Pan2 
> > Subject: Re: [PATCH v2] RISC-V: Add test cases for the RVV mask insn 
> > shortcut.
> >
> > LGTM. Wait for Kito more comments.
> >
> > 
> > juzhe.zh...@rivai.ai
> >
> > From: pan2.li
> > Date: 2023-04-14 10:45
> > To: gcc-patches
> > CC: juzhe.zhong;
> > kito.cheng;
> > yanzhang.wang;
> > pan2.li
> > Subject: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.
> > From: Pan Li mailto:pan2...@intel.com>>
> >
> > There are sorts of shortcut codegen for the RVV mask insn. For 
> > example.
> >
> > vmxor vd, va, va => vmclr vd.
> >
> > We would like to add more optimization like this but first of all we 
> > must add the tests for the existing shortcut optimization, to ensure 
> > we don't break existing optimization from underlying shortcut 
> > optimization.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/rvv/base/mask_insn_shortcut.c: New test.
> >
> > Signed-off-by: Pan Li mailto:pan2...@intel.com>>
> > ---
> > .../riscv/rvv/base/mask_insn_shortcut.c   | 239 ++
> > 1 file changed, 239 insertions(+)
> > create mode 100644
> > gcc/testsuite/gcc.target/riscv/rvv/base/mask_insn_shortcut.c
> >
> > diff --git
> > a/gcc/testsuite/gcc.target/riscv/rvv/base/mask_insn_shortcut.c
> > b/gcc/testsuite/gcc.target/riscv/rvv/base/mask_insn_shortcut.c
> > new file mode 100644
> > index 000..efc3af39fc3
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/mask_insn_shortcut.c
> > @@ -0,0 +1,239 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-march=rv64gcv -mabi=lp64 -O3" } */
> > +
> > +#include "riscv_vector.h"
> > +
> > +vbool1_t test_shortcut_for_riscv_vmand_case_0(vbool1_t v1, size_t 
> > +vl) {
> > +  return __riscv_vmand_mm_b1(v1, v1, vl); }
> > +
> > +vbool2_t test_shortcut_for_riscv_vmand_case_1(vbool2_t v1, size_t 
> > +vl) {
> > +  return __riscv_vmand_mm_b2(v1, v1, vl); }
> > +
> > +vbool4_t test_shortcut_for_riscv_vmand_case_2(vbool4_t v1, size_t 
> > +vl) {
> > +  return __riscv_vmand_mm_b4(v1, v1, vl); }
> > +
> > +vbool8_t test_shortcut_for_riscv_vmand_case_3(vbool8_t v1, size_t 
> > +vl) {
> > +  return __riscv_vmand_mm_b8(v1, v1, vl); }
> > +
> > +vbool16_t test_shortcut_for_riscv_vmand_case_4(vbool16_t v1, size_t
> > +vl) {
> > +  return __riscv_vmand_mm_b16(v1, v1, vl); }
> > +
> > +vbool32_t test_shortcut_for_riscv_vmand_case_5(vbool32_t v1, size_t
> > +vl) {
> > +  return __riscv_vmand_mm_b32(v1, v1, vl); }
> > +
> > +vbool64_t test_shortcut_for_riscv_vmand_case_6(vbool64_t v1, size_t
> > +vl) {
> > +  return __riscv_vmand_mm_b64(v1, v1, vl); }
> > +
> > +vbool1_t test_shortcut_for_riscv_vmnand_case_0(vbool1_t v1, size_t
> > +vl) {
> > +  return __riscv_vmnand_mm_b1(v1, v1, vl); }
> > +
> > +vbool2_t test_shortcut_for_riscv_vmnand_case_1(vbool2_t v1, size_t
> > +vl) {
> > +  return __riscv_vmnand_mm_b2(v1, v1, vl); }
> > +
> > +vbool4_t test_shortcut_for_riscv_vmnand_case_2(vbool4_t v1, size_t
> > +vl) {
> > +  return __riscv_vmnand_mm_b4(v1, v1, vl); }
> > +
> > +vbool8_t test_shortcut_for_riscv_vmnand_case_3(vbool8_t v1, size_t
> > +vl) {
> > +  retur

[committed] RISC-V: Fix testsuite fail on RV32

[Kito Cheng via Gcc-patches]

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/scalar_move-2.c: Adjust include way
for riscv_vector.h
* gcc.target/riscv/rvv/base/spill-sp-adjust.c: Add missing
-mabi.
---
 gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-2.c   | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/spill-sp-adjust.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-2.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-2.c
index 39fc107c657..5b538ba6aab 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-2.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
 
-#include 
+#include "riscv_vector.h"
 
 /*
 ** foo1:
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/spill-sp-adjust.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/spill-sp-adjust.c
index f8c9f6313e8..a6598a5ca88 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/spill-sp-adjust.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/spill-sp-adjust.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-march=rv64gcv" } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d" } */
 
 #include "spill-1.c"
 
-- 
2.39.2

Re: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.

[Kito Cheng via Gcc-patches]

Pushed to trunk :)

On Mon, Apr 17, 2023 at 9:47 AM Li, Pan2 via Gcc-patches
 wrote:
>
> BTW, this patch will be in GCC 13 or master? The underlying patches may 
> depend on this tests for ensuring correctness.
>
> Pan
>
> -Original Message-
> From: Li, Pan2
> Sent: Friday, April 14, 2023 2:47 PM
> To: Kito Cheng 
> Cc: juzhe.zh...@rivai.ai; gcc-patches ; Kito.cheng 
> ; Wang, Yanzhang 
> Subject: RE: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.
>
> You're very welcome!
>
> Looks vmorn(v,v) doesn't perform any shortcut, while vmandn(v, v) will be 
> converted to vmclr in upstream. As I understand, there should be no 
> difference between vmORn and vmANDn excepts the operator, will take a look 
> from RTL CSE for more details, 😊!
>
> Pan
>
> -Original Message-
> From: Kito Cheng 
> Sent: Friday, April 14, 2023 2:42 PM
> To: Li, Pan2 
> Cc: juzhe.zh...@rivai.ai; gcc-patches ; Kito.cheng 
> ; Wang, Yanzhang 
> Subject: Re: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.
>
> OK, thanks for the patch :)
>
> On Fri, Apr 14, 2023 at 11:27 AM Li, Pan2 via Gcc-patches 
>  wrote:
> >
> > Thanks juzhe, update new version [PATCH v3] for even more checks.
> >
> > Pan
> >
> > From: juzhe.zh...@rivai.ai 
> > Sent: Friday, April 14, 2023 10:46 AM
> > To: Li, Pan2 ; gcc-patches
> > 
> > Cc: Kito.cheng ; Wang, Yanzhang
> > ; Li, Pan2 
> > Subject: Re: [PATCH v2] RISC-V: Add test cases for the RVV mask insn 
> > shortcut.
> >
> > LGTM. Wait for Kito more comments.
> >
> > 
> > juzhe.zh...@rivai.ai
> >
> > From: pan2.li
> > Date: 2023-04-14 10:45
> > To: gcc-patches
> > CC: juzhe.zhong;
> > kito.cheng;
> > yanzhang.wang;
> > pan2.li
> > Subject: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.
> > From: Pan Li mailto:pan2...@intel.com>>
> >
> > There are sorts of shortcut codegen for the RVV mask insn. For
> > example.
> >
> > vmxor vd, va, va => vmclr vd.
> >
> > We would like to add more optimization like this but first of all we
> > must add the tests for the existing shortcut optimization, to ensure
> > we don't break existing optimization from underlying shortcut
> > optimization.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/rvv/base/mask_insn_shortcut.c: New test.
> >
> > Signed-off-by: Pan Li mailto:pan2...@intel.com>>
> > ---
> > .../riscv/rvv/base/mask_insn_shortcut.c   | 239 ++
> > 1 file changed, 239 insertions(+)
> > create mode 100644
> > gcc/testsuite/gcc.target/riscv/rvv/base/mask_insn_shortcut.c
> >
> > diff --git
> > a/gcc/testsuite/gcc.target/riscv/rvv/base/mask_insn_shortcut.c
> > b/gcc/testsuite/gcc.target/riscv/rvv/base/mask_insn_shortcut.c
> > new file mode 100644
> > index 000..efc3af39fc3
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/mask_insn_shortcut.c
> > @@ -0,0 +1,239 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-march=rv64gcv -mabi=lp64 -O3" } */
> > +
> > +#include "riscv_vector.h"
> > +
> > +vbool1_t test_shortcut_for_riscv_vmand_case_0(vbool1_t v1, size_t vl)
> > +{
> > +  return __riscv_vmand_mm_b1(v1, v1, vl); }
> > +
> > +vbool2_t test_shortcut_for_riscv_vmand_case_1(vbool2_t v1, size_t vl)
> > +{
> > +  return __riscv_vmand_mm_b2(v1, v1, vl); }
> > +
> > +vbool4_t test_shortcut_for_riscv_vmand_case_2(vbool4_t v1, size_t vl)
> > +{
> > +  return __riscv_vmand_mm_b4(v1, v1, vl); }
> > +
> > +vbool8_t test_shortcut_for_riscv_vmand_case_3(vbool8_t v1, size_t vl)
> > +{
> > +  return __riscv_vmand_mm_b8(v1, v1, vl); }
> > +
> > +vbool16_t test_shortcut_for_riscv_vmand_case_4(vbool16_t v1, size_t
> > +vl) {
> > +  return __riscv_vmand_mm_b16(v1, v1, vl); }
> > +
> > +vbool32_t test_shortcut_for_riscv_vmand_case_5(vbool32_t v1, size_t
> > +vl) {
> > +  return __riscv_vmand_mm_b32(v1, v1, vl); }
> > +
> > +vbool64_t test_shortcut_for_riscv_vmand_case_6(vbool64_t v1, size_t
> > +vl) {
> > +  return __riscv_vmand_mm_b64(v1, v1, vl); }
> > +
> > +vbool1_t test_shortcut_for_riscv_vmnand_case_0(vbool1_t v1, size_t
> > +vl) {
> > +  return __riscv_vmnand_mm_b1(v1, v1, vl); }
> > +
> > +vbool2_t test_shortcut_for_riscv_vmnand_case_1(vbool2_t v1, size_t
> > +vl) {
> > +  return __riscv_vmnand_mm_b2(v1, v1, vl); }
> > +
> > +vbool4_t test_shortcut_for_riscv_vmnand_case_2(vbool4_t v1, size_t
> > +vl) {
> > +  return __riscv_vmnand_mm_b4(v1, v1, vl); }
> > +
> > +vbool8_t test_shortcut_for_riscv_vmnand_case_3(vbool8_t v1, size_t
> > +vl) {
> > +  return __riscv_vmnand_mm_b8(v1, v1, vl); }
> > +
> > +vbool16_t test_shortcut_for_riscv_vmnand_case_4(vbool16_t v1, size_t
> > +vl) {
> > +  return __riscv_vmnand_mm_b16(v1, v1, vl); }
> > +
> > +vbool32_t test_shortcut_for_riscv_vmnand_case_5(vbool32_t v1, size_t
> > +vl) {
> > +  return __

RE: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.

[Li, Pan2 via Gcc-patches]

BTW, this patch will be in GCC 13 or master? The underlying patches may depend 
on this tests for ensuring correctness.

Pan

-Original Message-
From: Li, Pan2 
Sent: Friday, April 14, 2023 2:47 PM
To: Kito Cheng 
Cc: juzhe.zh...@rivai.ai; gcc-patches ; Kito.cheng 
; Wang, Yanzhang 
Subject: RE: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.

You're very welcome!

Looks vmorn(v,v) doesn't perform any shortcut, while vmandn(v, v) will be 
converted to vmclr in upstream. As I understand, there should be no difference 
between vmORn and vmANDn excepts the operator, will take a look from RTL CSE 
for more details, 😊!

Pan

-Original Message-
From: Kito Cheng 
Sent: Friday, April 14, 2023 2:42 PM
To: Li, Pan2 
Cc: juzhe.zh...@rivai.ai; gcc-patches ; Kito.cheng 
; Wang, Yanzhang 
Subject: Re: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.

OK, thanks for the patch :)

On Fri, Apr 14, 2023 at 11:27 AM Li, Pan2 via Gcc-patches 
 wrote:
>
> Thanks juzhe, update new version [PATCH v3] for even more checks.
>
> Pan
>
> From: juzhe.zh...@rivai.ai 
> Sent: Friday, April 14, 2023 10:46 AM
> To: Li, Pan2 ; gcc-patches 
> 
> Cc: Kito.cheng ; Wang, Yanzhang 
> ; Li, Pan2 
> Subject: Re: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.
>
> LGTM. Wait for Kito more comments.
>
> 
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-04-14 10:45
> To: gcc-patches
> CC: juzhe.zhong;
> kito.cheng;
> yanzhang.wang;
> pan2.li
> Subject: [PATCH v2] RISC-V: Add test cases for the RVV mask insn shortcut.
> From: Pan Li mailto:pan2...@intel.com>>
>
> There are sorts of shortcut codegen for the RVV mask insn. For 
> example.
>
> vmxor vd, va, va => vmclr vd.
>
> We would like to add more optimization like this but first of all we 
> must add the tests for the existing shortcut optimization, to ensure 
> we don't break existing optimization from underlying shortcut 
> optimization.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/mask_insn_shortcut.c: New test.
>
> Signed-off-by: Pan Li mailto:pan2...@intel.com>>
> ---
> .../riscv/rvv/base/mask_insn_shortcut.c   | 239 ++
> 1 file changed, 239 insertions(+)
> create mode 100644
> gcc/testsuite/gcc.target/riscv/rvv/base/mask_insn_shortcut.c
>
> diff --git
> a/gcc/testsuite/gcc.target/riscv/rvv/base/mask_insn_shortcut.c
> b/gcc/testsuite/gcc.target/riscv/rvv/base/mask_insn_shortcut.c
> new file mode 100644
> index 000..efc3af39fc3
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/mask_insn_shortcut.c
> @@ -0,0 +1,239 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gcv -mabi=lp64 -O3" } */
> +
> +#include "riscv_vector.h"
> +
> +vbool1_t test_shortcut_for_riscv_vmand_case_0(vbool1_t v1, size_t vl) 
> +{
> +  return __riscv_vmand_mm_b1(v1, v1, vl); }
> +
> +vbool2_t test_shortcut_for_riscv_vmand_case_1(vbool2_t v1, size_t vl) 
> +{
> +  return __riscv_vmand_mm_b2(v1, v1, vl); }
> +
> +vbool4_t test_shortcut_for_riscv_vmand_case_2(vbool4_t v1, size_t vl) 
> +{
> +  return __riscv_vmand_mm_b4(v1, v1, vl); }
> +
> +vbool8_t test_shortcut_for_riscv_vmand_case_3(vbool8_t v1, size_t vl) 
> +{
> +  return __riscv_vmand_mm_b8(v1, v1, vl); }
> +
> +vbool16_t test_shortcut_for_riscv_vmand_case_4(vbool16_t v1, size_t
> +vl) {
> +  return __riscv_vmand_mm_b16(v1, v1, vl); }
> +
> +vbool32_t test_shortcut_for_riscv_vmand_case_5(vbool32_t v1, size_t
> +vl) {
> +  return __riscv_vmand_mm_b32(v1, v1, vl); }
> +
> +vbool64_t test_shortcut_for_riscv_vmand_case_6(vbool64_t v1, size_t
> +vl) {
> +  return __riscv_vmand_mm_b64(v1, v1, vl); }
> +
> +vbool1_t test_shortcut_for_riscv_vmnand_case_0(vbool1_t v1, size_t
> +vl) {
> +  return __riscv_vmnand_mm_b1(v1, v1, vl); }
> +
> +vbool2_t test_shortcut_for_riscv_vmnand_case_1(vbool2_t v1, size_t
> +vl) {
> +  return __riscv_vmnand_mm_b2(v1, v1, vl); }
> +
> +vbool4_t test_shortcut_for_riscv_vmnand_case_2(vbool4_t v1, size_t
> +vl) {
> +  return __riscv_vmnand_mm_b4(v1, v1, vl); }
> +
> +vbool8_t test_shortcut_for_riscv_vmnand_case_3(vbool8_t v1, size_t
> +vl) {
> +  return __riscv_vmnand_mm_b8(v1, v1, vl); }
> +
> +vbool16_t test_shortcut_for_riscv_vmnand_case_4(vbool16_t v1, size_t
> +vl) {
> +  return __riscv_vmnand_mm_b16(v1, v1, vl); }
> +
> +vbool32_t test_shortcut_for_riscv_vmnand_case_5(vbool32_t v1, size_t
> +vl) {
> +  return __riscv_vmnand_mm_b32(v1, v1, vl); }
> +
> +vbool64_t test_shortcut_for_riscv_vmnand_case_6(vbool64_t v1, size_t
> +vl) {
> +  return __riscv_vmnand_mm_b64(v1, v1, vl); }
> +
> +vbool1_t test_shortcut_for_riscv_vmandn_case_0(vbool1_t v1, size_t
> +vl) {
> +  return __riscv_vmandn_mm_b1(v1, v1, vl); }
> +
> +vbool2_t test_shortcut_for_riscv_vmandn_case_1(vbool2_t v1, 

[PATCH] c++: Additional warning for name-hiding [PR12341]

[Benjamin Priour via Gcc-patches]

Hi everyone,

My first patch, and I don't have write access yet.

This patch add a new warning under -Wshadow, to warn when a class
field hides another inherited.

At the moment, I'm looking for a similarly
named field independently of its visibility (whether it is public,
protected or private within the base class).
However, if the inheritance itself is not visible from the current
class, then I dismiss the warning
(e.g. Grandparent class is inherited privately by Parent, then Child
won't collide).

Note that ChangeLogs were generated without the script `git gcc-mklog`.

Bootstrapped and regtested on x86_64-pc-linux-gnu.
Diff is with 20230413-trunk, I checked in with today 20230416 trunk though.
I tried to follow the contribute page down to the letter, still if
I've missed anything, please tell me how I could improve the
submission.
Great thanks,
Benjamin.

c++: Additional warning for name-hiding [PR12341]

Add a new warning for name-hiding. When a class's field
is named similarly to one inherited, a warning should
be issued.

2023-04-13 Benjamin Priour vutlk...@gcc.gnu.org

gcc/cp/ChangeLog:

* search.cc (lookup_member):
New optional parameter to preempt too deep inheritance
tree processing.
(lookup_field): Likewise.
(dfs_walk_all): Likewise.
* cp-tree.h: Complete the above declarations.
* class.cc (warn_name_hiding): New function.
(finish_struct_1): Call warn_name_hiding if -Wshadow.

gcc/testsuite/ChangeLog:

* g++.dg/warn/pr12341-1.C: New file.
* g++.dg/warn/pr12341-2.C: New file.

---

diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index 68b62086340..1e3efc028a6 100644
--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
@@ -3080,6 +3080,80 @@ warn_hidden (tree t)
   }
 }

+/* Warn about non-static fields name hiding. */
+static void
+warn_name_hiding (tree t)
+{
+  if (is_empty_class (t) || CLASSTYPE_NEARLY_EMPTY_P (t))
+return;
+
+  for (tree field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field))
+{
+/* Skip if field is not a user-defined non-static data member. */
+if (TREE_CODE (field) != FIELD_DECL || DECL_ARTIFICIAL (field))
+  continue;
+
+unsigned j;
+tree name = DECL_NAME (field);
+/* Skip if field is anonymous. */
+if (!name || !identifier_p (name))
+  continue;
+
+auto_vec base_vardecls;
+tree binfo;
+tree base_binfo;
+  /* Iterate through all of the base classes looking for possibly
+  shadowed non-static data members. */
+for (binfo = TYPE_BINFO (t), j = 0;
+BINFO_BASE_ITERATE (binfo, j, base_binfo); j++)
+{
+  tree basetype = BINFO_TYPE (base_binfo);
+  tree candidate = lookup_field (basetype,
+name,
+/* protect */ 2,
+/* want_type */ 0,
+/* once_suffices */ true);
+  if (candidate)
+  {
+/*
+if we went up the hierarchy to a base class with multiple inheritance,
+there could be multiple matches, in which case a TREE_LIST is returned
+*/
+if (TREE_TYPE (candidate) == error_mark_node)
+{
+  for (; candidate; candidate = TREE_CHAIN (candidate))
+  {
+tree candidate_field = TREE_VALUE (candidate);
+tree candidate_klass = DECL_CONTEXT (candidate_field);
+if (accessible_base_p (t, candidate_klass, true))
+  base_vardecls.safe_push (candidate_field);
+  }
+}
+else if (accessible_base_p (t, DECL_CONTEXT (candidate), true))
+  base_vardecls.safe_push (candidate);
+  }
+}
+
+/* field was not found among the base classes */
+if (base_vardecls.is_empty ())
+  continue;
+
+/* Emit a warning for each field similarly named
+found in the base class hierarchy */
+for (tree base_vardecl : base_vardecls)
+  if (base_vardecl)
+  {
+auto_diagnostic_group d;
+if (warning_at (location_of (field),
+OPT_Wshadow,
+"%qD might shadow %qD", field, base_vardecl))
+inform (location_of (base_vardecl),
+"  %qD name already in use here", base_vardecl);
+  }
+}
+}
+
+
 /* Recursive helper for finish_struct_anon.  */

 static void
@@ -7654,6 +7728,8 @@ finish_struct_1 (tree t)

   if (warn_overloaded_virtual)
 warn_hidden (t);
+  if (warn_shadow)
+warn_name_hiding (t);

   /* Class layout, assignment of virtual table slots, etc., is now
  complete.  Give the back end a chance to tweak the visibility of
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 622752ae4e6..e56e85d93cc 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7519,11 +7519,11 @@ extern tree lookup_base
 (tree, tree, base_access,
 extern tree dcast_base_hint(tree, tree);
 extern int accessible_p(tree, tree, bool);
 extern int accessible_in_template_p(tree, tree);
-extern tree lookup_field  

Re: [PATCH 2/3] RISC-V: optimize stack manipulation in save-restore

[Jeff Law via Gcc-patches]

On 12/1/22 03:03, Fei Gao wrote:

The stack that save-restore reserves is not well accumulated in stack 
allocation and deallocation.
This patch allows less instructions to be used in stack allocation and 
deallocation if save-restore enabled.
Haha!  I should have read the whole series before commenting on the 
first patch.  I think this addresses the precise issue I was asking 
about in my prior message.


Jeff

Re: [PATCH 1/3] RISC-V: add a new parameter in riscv_first_stack_step.

[Jeff Law via Gcc-patches]

On 12/1/22 03:03, Fei Gao wrote:

frame->total_size to remaining_size conversion is done as an independent patch 
without
functionality change as per review comment.

gcc/ChangeLog:

 * config/riscv/riscv.cc (riscv_first_stack_step): add a new function 
parameter remaining_size.
 (riscv_compute_frame_info): adapt new riscv_first_stack_step interface.
 (riscv_expand_prologue): likewise.
 (riscv_expand_epilogue): likewise.
---
  gcc/config/riscv/riscv.cc | 48 +++
  1 file changed, 24 insertions(+), 24 deletions(-)







@@ -5037,7 +5037,7 @@ riscv_expand_prologue (void)
/* Save the registers.  */
if ((frame->mask | frame->fmask) != 0)
  {
-  HOST_WIDE_INT step1 = riscv_first_stack_step (frame);
+  HOST_WIDE_INT step1 = riscv_first_stack_step (frame, frame->total_size);
if (size.is_constant ())
step1 = MIN (size.to_constant(), step1);
Hmm.  I generally agree that this patch has no functional changes in 
behavior.   But I wonder if there's a latent bug in the prologue code.


It seems to me that if we are optimizing for size and need to save both 
GPRs and FPRs that we don't want to be using frame->total_size as the 
libcall path to save the GPRs will have done a partial allocation, thus 
reducing the amount of stack still to allocate.  Or am I missing 
something here?




Jeff

[committed] [PR target/109508] Adjust conditional move expansion for SFB

[Jeff Law]

Recently the conditional move expander's predicates were loosened for 
the benefit of the THEAD processors.  In particular one operand that was 
previously "register_operand" is now "reg_or_0_operand".  That's fine 
for THEAD, but breaks for SFB which requires a register for that operand.


This results in an ICE when compiling the testcase an SFB target such as 
the sifive s76.


This change adjusts the expansion code slightly to copy the value into a 
register for SFB.


Bootstrapped and regression tested (c,c++,fortran only) with a toolchain 
configured to enable SFB by default.


Installing on the trunk momentarily.

Jeffcommit a647198fcf7463a42c8e035a429200e7998735dc
Author: Jeff Law 
Date:   Sun Apr 16 09:55:32 2023 -0600

[committed] [PR target/109508] Adjust conditional move expansion for SFB

Recently the conditional move expander's predicates were loosened for the
benefit of the THEAD processors.  In particular one operand that was
previously "register_operand" is now "reg_or_0_operand".  That's fine for
THEAD, but breaks for SFB which requires a register for that operand.

This results in an ICE when compiling the testcase an SFB target such as
the sifive s76.

This change adjusts the expansion code slightly to copy the value into
a register for SFB.

Bootstrapped and regression tested (c,c++,fortran only) with a toolchain
configured to enable SFB by default.

PR target/109508
gcc/

* config/riscv/riscv.cc (riscv_expand_conditional_move): For
TARGET_SFB_ALU, force the true arm into a register.

gcc/testsuite
* gcc.target/riscv/pr109508.c: New test.

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index dc47434fac4..e88fa2d6337 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -3419,6 +3419,12 @@ riscv_expand_conditional_move (rtx dest, rtx op, rtx 
cons, rtx alt)
 {
   riscv_emit_int_compare (&code, &op0, &op1);
   rtx cond = gen_rtx_fmt_ee (code, GET_MODE (op0), op0, op1);
+
+  /* The expander allows (const_int 0) for CONS for the benefit of
+TARGET_XTHEADCONDMOV, but that case isn't supported for
+TARGET_SFB_ALU.  So force that operand into a register if
+necessary.  */
+  cons = force_reg (GET_MODE (dest), cons);
   emit_insn (gen_rtx_SET (dest, gen_rtx_IF_THEN_ELSE (GET_MODE (dest),
  cond, cons, alt)));
   return true;
diff --git a/gcc/testsuite/gcc.target/riscv/pr109508.c 
b/gcc/testsuite/gcc.target/riscv/pr109508.c
new file mode 100644
index 000..65f291e17ed
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/pr109508.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-mcpu=sifive-s76" } */
+
+typedef char __attribute__((__vector_size__ (1))) V;
+
+V v;
+
+void
+foo (void)
+{
+  (char) __builtin_shuffle (0 % v, (V){6}, v);
+}

[PATCH] tree-ssa-sink: Improve code sinking pass.

[Ajit Agarwal via Gcc-patches]

Hello All:

This patch improves code sinking pass to sink the blocks before calls
in the use blocks or immediate dominator blocks that reduces register pressure.

Bootstrapped and regtested on powerpc64-linux-gnu.

Thanks & Regards
Ajit

tree-ssa-sink: Improve code sinking pass.

Code Sinking sinks the blocks after call. This increases
register pressure for callee-saved registers. Improves
code sinking before call in the use blocks or immediate
dominator of use blocks.

2023-04-16  Ajit Kumar Agarwal  

gcc/ChangeLog:

* tree-ssa-sink.cc (statement_sink_location): Modifed to
move statements before calls.
(block_call_p): New function.
(def_use_same_block): New function.
(select_best_block): Add heuristics to select the best
blocks in the immediate post dominator.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/ssa-sink-20.c: New testcase.
* gcc.dg/tree-ssa/ssa-sink-21.c: New testcase.
---
 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-20.c |  16 +++
 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c |  20 +++
 gcc/tree-ssa-sink.cc| 134 +++-
 3 files changed, 164 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-20.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-20.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-20.c
new file mode 100644
index 000..716bc1f9257
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-20.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-sink -fdump-tree-optimized 
-fdump-tree-sink-stats" } */
+
+void bar();
+int j;
+void foo(int a, int b, int c, int d, int e, int f)
+{
+  int l;
+  l = a + b + c + d +e + f;
+  if (a != 5)
+{
+  bar();
+  j = l;
+}
+}
+/* { dg-final { scan-tree-dump-times "Sunk statements: 5" 1 "sink" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c
new file mode 100644
index 000..ff41e2ea8ae
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */ 
+/* { dg-options "-O2 -fdump-tree-sink-stats -fdump-tree-sink-stats" } */
+
+void bar();
+int j, x;
+void foo(int a, int b, int c, int d, int e, int f)
+{
+  int l;
+  l = a + b + c + d +e + f;
+  if (a != 5)
+{
+  bar();
+  if (b != 3)
+x = 3;
+  else
+x = 5;
+  j = l;
+}
+}
+/* { dg-final { scan-tree-dump-times "Sunk statements: 5" 1 "sink" } } */
diff --git a/gcc/tree-ssa-sink.cc b/gcc/tree-ssa-sink.cc
index 87b1d40c174..12babf73321 100644
--- a/gcc/tree-ssa-sink.cc
+++ b/gcc/tree-ssa-sink.cc
@@ -171,6 +171,70 @@ nearest_common_dominator_of_uses (def_operand_p def_p, 
bool *debug_stmts)
   return commondom;
 }
 
+/* Check def and use stmts are in same block.  */
+
+bool
+def_use_same_block (gimple *use)
+{
+  use_operand_p use_p;
+  def_operand_p def_p;
+  imm_use_iterator imm_iter;
+  ssa_op_iter iter;
+
+  FOR_EACH_SSA_DEF_OPERAND (def_p, use, iter, SSA_OP_DEF)
+{
+  FOR_EACH_IMM_USE_FAST (use_p, imm_iter, DEF_FROM_PTR (def_p))
+   {
+ if (is_gimple_debug (USE_STMT (use_p)))
+   continue;
+
+ if (use_p
+ && (gimple_bb(USE_STMT (use_p)) == gimple_bb (use)))
+   return true;
+   }
+ }
+  return false;
+}
+
+/* Check if the block has only calls.  */
+
+bool
+block_call_p (basic_block bb)
+{
+  int i = 0;
+  bool is_call = false;
+  gimple_stmt_iterator gsi = gsi_last_bb (bb);
+  gimple *last_stmt = gsi_stmt (gsi);
+
+  if (last_stmt && gimple_code (last_stmt) == GIMPLE_COND)
+{
+  if (!gsi_end_p (gsi))
+   gsi_prev (&gsi);
+
+   for (; !gsi_end_p (gsi);)
+{
+  gimple *stmt = gsi_stmt (gsi);
+
+  if (is_gimple_debug (stmt))
+return false;
+
+  if (is_gimple_call (stmt))
+is_call = true;
+  else
+return false;
+
+  if (!gsi_end_p (gsi))
+gsi_prev (&gsi);
+
+   ++i;
+   }
+ }
+  if (is_call && i == 1)
+return true;
+
+  return false;
+}
+
 /* Given EARLY_BB and LATE_BB, two blocks in a path through the dominator
tree, return the best basic block between them (inclusive) to place
statements.
@@ -190,7 +254,8 @@ nearest_common_dominator_of_uses (def_operand_p def_p, bool 
*debug_stmts)
 static basic_block
 select_best_block (basic_block early_bb,
   basic_block late_bb,
-  gimple *stmt)
+  gimple *stmt,
+  gimple *use = 0)
 {
   basic_block best_bb = late_bb;
   basic_block temp_bb = late_bb;
@@ -230,7 +295,28 @@ select_best_block (basic_block early_bb,
   if (threshold > 100)
threshold = 100;
 }
+  if (bb_loop_depth (best_bb) == bb_loop_depth (early_bb)
+  && !(best_bb->count * 100 >= earl

[Committed] New test case gcc.target/avr/pr54816.c

[Roger Sayle]

PR target/54816 is now fixed on mainline.  This adds a test case to
check that it doesn't regress in future.  Tested with a cross compiler
to avr-elf.  Committed as obvious.


2023-04-16  Roger Sayle  

gcc/testsuite/ChangeLog
PR target/54816
* gcc.target/avr/pr54816.c: New test case.


diff --git a/gcc/testsuite/gcc.target/avr/pr54816.c 
b/gcc/testsuite/gcc.target/avr/pr54816.c
new file mode 100644
index 000..56be780
--- /dev/null
+++ b/gcc/testsuite/gcc.target/avr/pr54816.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-Os -mmcu=atmega8" } */
+int wmul (char a, char b)
+{
+return a * (char) (b << 3);
+}
+
+/* { dg-final { scan-assembler-times "lsl" 3 } } */
+/* { dg-final { scan-assembler-times "muls" 1 } } */