Thank you for your consideration. (Or is that phrase only used negatively?)
> From: Jonathan Wakely
> Date: Fri, 9 Jun 2023 21:40:15 +0100
> test01, test02, test03 and test04 should run almost instantly. On my system
> they take about 5 microseconds each. So I don't think splitting those up
>
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Saturday, June 10, 2023 11:03 AM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; rdapp@gmail.com;
jeffreya...@gmail.com; Wang, Yanzhang
Subject: Re: [PATCH v1] RISC-V: Add test cases for RVV
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Saturday, June 10, 2023 11:03 AM
To: juzhe.zh...@rivai.ai
Cc: gcc-patches@gcc.gnu.org; kito.ch...@sifive.com; pal...@rivosinc.com;
rdapp@gmail.com; jeffreya...@gmail.com
LGTM, thanks for this
On Sat, Jun 10, 2023 at 8:42 AM wrote:
>
> From: Juzhe-Zhong
>
> Consider this following example:
> void vec_add(int32_t *restrict c, int32_t *restrict a, int32_t *restrict b,
> int N) {
> for (long i = 0; i < N; i++) {
> c[i] = a[i] + b[i];
> }
>
LGTM :)
On Sat, Jun 10, 2023 at 7:59 AM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to add more tests for RVV FP16 vreinterpret, aka
>
> vfloat16*_t <==> v{u}int16*_t.
>
> There we allow FP16 vreinterpret in ZVFHMIN consider we have vle FP16 already.
> It doesn't
This is the final shared integer/float opcode.
This patch also removes the floating point table and all references to it.
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From cc4eaf6f1e1958f920007d4cc7cafb635b5dda64 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:41:28 -0400
Subject: [PATCH 11/31] Unify PLUS_EXPR range operator
Move the declaration of the class to
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From: Juzhe-Zhong
Consider this following example:
void vec_add(int32_t *restrict c, int32_t *restrict a, int32_t *restrict b,
int N) {
for (long i = 0; i < N; i++) {
c[i] = a[i] + b[i];
}
}
After this patch:
vec_add:
ble a3,zero,.L5
.L3:
vsetvli
Unify GT_EXPR the range operator
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From e5a4bb7c12d00926e0c7bbf0c77dd1be8f23a39a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:32:25 -0400
Subject: [PATCH 06/31] Unify GT_EXPR range operator
Move
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From ee46a15733524103a9eda433df5dc44cdc055d73 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:39:54 -0400
Subject: [PATCH 10/31] Unify operator_cast range operator
Move the declaration of the class
Unify the LE_EXPR opcode.
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From 9de70a61ca83d50c35f73eafaaa7276d8f0ad211 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:30:56 -0400
Subject: [PATCH 05/31] Unify LE_EXPR range operator
Move the
Unify GE_EXPR the range operator
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From 364b936b8d82e86c73b2b964d4c8a2c16dcbedf8 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:33:33 -0400
Subject: [PATCH 07/31] Unify GE_EXPR range operator
Move
THis patch move the CONST operator into the mixed header. It also sets
REAL_CST to use this instead, as it has no op1_range routines.
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From 35a580f09eaceda5b0dd370b1e39fe05ba0a154f Mon Sep 17 00:00:00 2001
From: Andrew
This unifies the identity operation, which is used by SSA_NAME,
PAREN_EXPR, OBJ_TYPE_REF and REAL_CST.
REAL_CST is using it incorrectly, but preserves current functionality.
There will not be an SSA_NAME in the op1 position, so there is no point
in having an op1_range routine. That will be
Unify the EQ_EXPR opcode
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From 684959c5c058c2368e65c4c308a2cb3e3912782e Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:18:39 -0400
Subject: [PATCH 02/31] Unify EQ_EXPR range operator
Move the
Unify the LT_EXPR opcode
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From f7c1366a89edf1ffdd9c495cff544358f2ff395e Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:29:15 -0400
Subject: [PATCH 04/31] Unify LT_EXPR range operator
Move the
Unify the NE_EXPR opcode
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From cb409a3b3367109944ff332899ec401dc60f678c Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:25:49 -0400
Subject: [PATCH 03/31] Unify NE_EXPR range operator
Move the
With all the operators unified under range_operator, I can now start
moving them into a unified table rather than have them spread around in
various type tables.
This patch creates a range_table for the unified operations, and has
checks to ensure that if the operator comes from the unified
From: Pan Li
This patch would like to add more tests for RVV FP16 vreinterpret, aka
vfloat16*_t <==> v{u}int16*_t.
There we allow FP16 vreinterpret in ZVFHMIN consider we have vle FP16 already.
It doesn't break anything in SPEC as there is no such vreinterpret insn.
>From the user's
Committed with bootstrap and regression test passed, thanks all.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Sandiford via Gcc-patches
Sent: Saturday, June 10, 2023 1:44 AM
To: juzhe.zh...@rivai.ai
Cc: rguenther ; gcc-patches
Subject: Re: [PATCH V6] VECT: Add
On Fri, Jun 9, 2023 at 10:54 AM Patrick Palka wrote:
>
> On Sun, 2 Apr 2023, Ken Matsui via Gcc-patches wrote:
>
> > This patch gets std::is_function to dispatch to new built-in trait
> > __is_function.
>
> For std::is_function and other predicate-like type traits, I think we also
> want to make
+ (VNx16QI "TARGET_MIN_VLEN <= 128")
+ (VNx32QI "TARGET_MIN_VLEN <= 256")
+ (VNx64QI "TARGET_MIN_VLEN >= 64 && TARGET_MIN_VLEN <= 512")
+ (VNx128QI "TARGET_MIN_VLEN >= 128 && TARGET_MIN_VLEN <= 1024")
This not correct, we always use VNx16QI as LMUL = m1 for min_vlen >= 128.
Requirement of
On 5/29/23 04:51, Jin Ma wrote:
Unrecog insns (such as CLOBBER, USE) does not represent real instructions,
but in the
process of pipeline optimization, they will wait for transmission in ready list
like
other insns, without considering resource conflicts and cycles. This results in
a
From: Juzhe-Zhong
Address comments from Jeff.
This patch is to rework Phase 5 && Phase 6 of VSETVL PASS since Phase 5 &&
Phase 6
are quite messy and cause some bugs discovered by my downstream
auto-vectorization
test-generator.
Before this patch.
Phase 5 is cleanup_insns is the function
Ok. Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-09 23:09
To: 钟居哲; gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc; pan2.li
Subject: Re: [PATCH V2] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS
On 6/9/23 08:58, 钟居哲 wrote:
>>> I'd probably adjust the name
PR analyzer/110112 notes that -fanalyzer is extremely slow on a source
file with large read-only static arrays, repeatedly building the
same compound_svalue representing the full initializer, and repeatedly
building svalues representing parts of the the full initialiazer.
This patch adds caches
On 9 June 2023 19:18:45 CEST, Mike Stump via Gcc-patches
wrote:
> simulation ports. Maybe a 20-100x speedup? If you want to go this way I'd
> say do it in python at the bottom as it would be nice to switch over to
> python in the next 5-20 years and away from tcl.
Yes, i guess we have all
On 6/9/23 11:27, Andrew Pinski via Gcc-patches wrote:
So for the attached testcase, we assumed that zero_one_valued_p would
be the value [0,1] but currently zero_one_valued_p matches also
signed 1 bit integers.
This changes that not to match that and fixes the 2 new testcases at
all
On Fri, 9 Jun 2023 at 17:20, Hans-Peter Nilsson wrote:
> Hi!
>
> The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes
> about 10 minutes to run for cris-elf in the "gdb simulator"
> here on my arguably way-past-retirement machine (and it
> looks like it gained a minute with LRA). I've
Hi!
On Wed, Jun 07, 2023 at 04:21:11PM +0800, Jiufu Guo wrote:
> This patch tries to optimize "(X - N * M) / N" to "X / N - M".
> For C code, "/" towards zero (trunc_div), and "X - N * M" maybe
> wrap/overflow/underflow. So, it is valid that "X - N * M" does
> not cross zero and does not
On Fri, 2023-06-09 at 20:28 +0200, Tim Lange wrote:
> This patch adds the reproducers reported in PR 110014 as test cases.
> The
> false positives in those cases are already fixed with PR 109577.
>
> 2023-06-09 Tim Lange
>
> PR analyzer/110014
>
> gcc/testsuite/ChangeLog:
>
>
On Fri, 2023-06-09 at 20:28 +0200, Tim Lange wrote:
[...snip...]
Thanks for the patch.
> diff --git a/gcc/analyzer/constraint-manager.cc
> b/gcc/analyzer/constraint-manager.cc
> index 2c9c435527e..24cd8960098 100644
> --- a/gcc/analyzer/constraint-manager.cc
> +++
This patch adds the reproducers reported in PR 110014 as test cases. The
false positives in those cases are already fixed with PR 109577.
2023-06-09 Tim Lange
PR analyzer/110014
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/pr110014.c: New tests.
---
Currently, the analyzer tries to prove that the allocation size is a
multiple of the pointee's type size. This patch reverses the behavior
to try to prove that the expression is not a multiple of the pointee's
type size. With this change, each unhandled case should be gracefully
considered as
Kyrylo Tkachov via Gcc-patches writes:
> Hi all,
>
> This patch implements RTL constant-folding for the SS_TRUNCATE and
> US_TRUNCATE codes.
> The semantics are a clamping operation on the argument with the min and max
> of the narrow mode,
> followed by a truncation. The signedness of the
On Sun, 2 Apr 2023, Ken Matsui via Gcc-patches wrote:
> This patch gets std::is_function to dispatch to new built-in trait
> __is_function.
For std::is_function and other predicate-like type traits, I think we also
want to make the corresponding variable template is_function_v directly
use the
> From: Mike Stump
> Date: Fri, 9 Jun 2023 10:18:45 -0700
> On Jun 9, 2023, at 9:20 AM, Hans-Peter Nilsson via Gcc-patches
> wrote:
> >
> > The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes
> > about 10 minutes to run for cris-elf in the "gdb simulator"
>
> I'd let the libstdc++
"juzhe.zh...@rivai.ai" writes:
> Thanks, Richi.
>
> Should I wait for Richard ACK gain ?
> Since the last email of this patch, he just asked me to adjust comment no
> codes change.
> I am not sure whether he is ok.
Yeah, OK from my POV too, thanks.
Richard
So for the attached testcase, we assumed that zero_one_valued_p would
be the value [0,1] but currently zero_one_valued_p matches also
signed 1 bit integers.
This changes that not to match that and fixes the 2 new testcases at
all optimization levels.
OK for GCC 13? Bootstrapped and tested on
On Jun 9, 2023, at 9:20 AM, Hans-Peter Nilsson via Gcc-patches
wrote:
>
> The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes
> about 10 minutes to run for cris-elf in the "gdb simulator"
I'd let the libstdc++ people comment on specific things. I'll comment on
general things. We
before casting into an irange, make sure the type being cast into is
also supported by irange.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 6314d76cf87df92a0f7d0fdd48240283e667998a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 10:17:59
THis patch moves range_cast into the header file and makes it inlinable.
I also added a trap so that if you try to cast into an unsupported
type, it traps. It can't return a value of the correct type, so the
caller needs to be doing something else...
Such as using the new variant of
Hi!
The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes
about 10 minutes to run for cris-elf in the "gdb simulator"
here on my arguably way-past-retirement machine (and it
looks like it gained a minute with LRA). I've seen it
timing out every now and then on busy days with load >
`nproc`.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Various spaceship tests failed after r14-1624. This turned out to be
because the comparison category classes return in memory on 32-bit targets,
and the synthesized operator<=> looks something like
if (auto v = a.x <=> b.x, v == 0); else
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We were failing to diagnose this Concepts TS feature that didn't make it
into C++20 because the 'auto' was getting converted to a template parameter
before we checked for it. So also check in cp_parser_simple_type_specifier.
The code in
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The maybe_init_list_as_range optimization is a form of copy elision, but we
can only elide well-formed copies.
PR c++/110102
gcc/cp/ChangeLog:
* call.cc (maybe_init_list_as_array): Check that the element type is
When defining a previously declared class template, we neglect to set
TPARMS_PRIMARY_TEMPLATE for the in-scope template parameters, which the
class members go on to inherit, and so the members' DECL_TEMPLATE_PARMS
will have empty TPARMS_PRIMARY_TEMPLATE at those levels as well. This
causes us to
On 6/8/23 08:56, Kyrylo Tkachov via Gcc-patches wrote:
Hi all,
This patch implements RTL constant-folding for the SS_TRUNCATE and US_TRUNCATE
codes.
The semantics are a clamping operation on the argument with the min and max of
the narrow mode,
followed by a truncation. The signedness of
On 6/9/23 08:58, 钟居哲 wrote:
I'd probably adjust the name as well. There's an important exception to
returning the first vsetvl -- you stop the search if you encounter a
user RVV instruction.
Could you give me a function name of this?
like:
get_first_vsetvl_prior_all_rvv_insns
is it ok?
>> I'd probably adjust the name as well. There's an important exception to
>> returning the first vsetvl -- you stop the search if you encounter a
>> user RVV instruction.
Could you give me a function name of this?
like:
get_first_vsetvl_prior_all_rvv_insns
is it ok? But I think the name is too
Thanks Jeff.
Actually, RTL_SSA framework is a very usefull tool very similar the framwork of
SDnode of LLVM.
which is the framework I am familar with. I just realize that the 2nd build of
RTL_SSA causes bugs
that's why I change it into data-flow.
Address all comments will send V3 soon.
Thanks.
On 6/9/23 08:37, Robin Dapp wrote:
On 6/9/23 16:32, juzhe.zh...@rivai.ai wrote:
From: Juzhe-Zhong
This patch fixes the requirement of V_WHOLE and V_FRACT.
E.g. VNx8QI in V_WHOLE has no requirement which is incorrect.
Actually, VNx8QI should be whole(full) mode when TARGET_MIN_VLEN <
Ok. Thanks Jeff.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-09 22:42
To: juzhe.zh...@rivai.ai; rguenther
CC: gcc-patches; richard.sandiford
Subject: Re: [PATCH V6] VECT: Add SELECT_VL support
On 6/9/23 05:32, juzhe.zh...@rivai.ai wrote:
> Thanks a lot Richi.
>
> Even though last
> I think it shouldn't be with vec_set patch.
> Instead, it obviously should be the separate patch.
Yes, I didn't mean in the actual same patch.
Regards
Robin
On 6/9/23 05:32, juzhe.zh...@rivai.ai wrote:
Thanks a lot Richi.
Even though last time Richard asked me no need to wait for 2nd ACK,
I am still want to wait for Richard final approval since I am not sure this
patch is ok for him.
If Richard had asked you to wait for Richi and you've done
Ok. If you have done this plz go ahead.
I think it shouldn't be with vec_set patch.
Instead, it obviously should be the separate patch.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-09 22:37
To: juzhe.zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; palmer; jeffreyalaw
Subject: Re: [PATCH]
On 6/9/23 16:32, juzhe.zh...@rivai.ai wrote:
> From: Juzhe-Zhong
>
> This patch fixes the requirement of V_WHOLE and V_FRACT.
> E.g. VNx8QI in V_WHOLE has no requirement which is incorrect.
> Actually, VNx8QI should be whole(full) mode when TARGET_MIN_VLEN < 128
> since when
On 6/9/23 04:41, juzhe.zh...@rivai.ai wrote:
From: Juzhe-Zhong
This patch is to rework Phase 5 && Phase 6 of VSETVL PASS since Phase 5 &&
Phase 6
are quite messy and cause some bugs discovered by my downstream
auto-vectorization
test-generator.
Before this patch.
Phase 5 is
From: Juzhe-Zhong
This patch fixes the requirement of V_WHOLE and V_FRACT.
E.g. VNx8QI in V_WHOLE has no requirement which is incorrect.
Actually, VNx8QI should be whole(full) mode when TARGET_MIN_VLEN < 128
since when TARGET_MIN_VLEN == 128, VNx8QI is e8mf2 which is fractional
I stitched together appropriate ChangeLog entries and pushed this to
the
trunk (I don't think Lehua has write access).
Thank you!
Best,
Lehua
Hi,
Richard Biener writes:
> On Wed, 7 Jun 2023, Jiufu Guo wrote:
>
>> Hi,
>>
>> This patch tries to optimize "(X - N * M) / N" to "X / N - M".
>> For C code, "/" towards zero (trunc_div), and "X - N * M" maybe
>> wrap/overflow/underflow. So, it is valid that "X - N * M" does
>> not cross
On 6/9/23 05:56, Richard Biener via Gcc-patches wrote:
On Fri, Jun 9, 2023 at 11:58 AM Lehua Ding wrote:
It's odd that the checksum doesn't depend on the number of iterations done ...
This is because the difference between the calculated result (32063.902344) and
the expected result
Hi,
thanks for looking at this.
On Fri, Jun 02 2023, Richard Biener wrote:
> On Mon, 29 May 2023, Martin Jambor wrote:
>
[...]
>> diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
>> index 27c84e78fcf..33215b5fc82 100644
>> --- a/gcc/tree-ssa-sccvn.cc
>> +++ b/gcc/tree-ssa-sccvn.cc
>>
On Fri, 9 Jun 2023, Jiufu Guo wrote:
>
> Hi,
>
> Richard Biener writes:
>
> > On Fri, 9 Jun 2023, Jiufu Guo wrote:
> >
> >>
> >> Hi,
> >>
> >> Richard Biener writes:
> >>
> >> > On Fri, 9 Jun 2023, Richard Sandiford wrote:
> >> >
> >> >> guojiufu writes:
> >> >> > Hi,
> >> >> >
> >> >> >
On Fri, Jun 9, 2023 at 2:26 PM Alexandre Oliva wrote:
>
> On Jun 9, 2023, Richard Biener wrote:
>
> > On Thu, Jun 8, 2023 at 4:38 PM Alexandre Oliva via Gcc-patches
> > wrote:
>
> >> C++ requires inline functions to be declared inline and defined in
> >> every translation unit that uses them.
On Fri, Jun 09, 2023 at 08:37:20PM +0800, Xi Ruoyao wrote:
> Ping (in hopes that someone can review before the weekend).
>
> On Sat, 2023-06-03 at 19:25 +0800, Xi Ruoyao wrote:
> > We used to skip ifunc check when CX16 is available. But now we use
> > CX16+AVX+Intel/AMD for the "perfect" 16b
Hi,
Richard Biener writes:
> On Fri, 9 Jun 2023, Jiufu Guo wrote:
>
>>
>> Hi,
>>
>> Richard Biener writes:
>>
>> > On Fri, 9 Jun 2023, Richard Sandiford wrote:
>> >
>> >> guojiufu writes:
>> >> > Hi,
>> >> >
>> >> > On 2023-06-09 16:00, Richard Biener wrote:
>> >> >> On Fri, 9 Jun 2023,
Ping (in hopes that someone can review before the weekend).
On Sat, 2023-06-03 at 19:25 +0800, Xi Ruoyao wrote:
> We used to skip ifunc check when CX16 is available. But now we use
> CX16+AVX+Intel/AMD for the "perfect" 16b load implementation, so CX16
> alone is not a sufficient reason not to
On Jun 9, 2023, Richard Biener wrote:
> On Thu, Jun 8, 2023 at 4:38 PM Alexandre Oliva via Gcc-patches
> wrote:
>> C++ requires inline functions to be declared inline and defined in
>> every translation unit that uses them. frange_nextafter is used in
>> gimple-range-op.cc but it's only
Tested powerpc64le-linux, sparc-solaris. Pushed to trunk.
-- >8 --
When long double uses IEEE binary128 representation we define the
_Float128 overload of std::from_chars inline in . My changes
in r14-1431-g7037e7b6e4ac41 cause it to also be defined non-inline in
the library, leading to an
Tested x86_64-linux. Pushed to trunk.
--> 8--
We can't define endpoints and resolvers without the relevant OS support.
If IPPROTO_TCP and IPPROTO_UDP are both udnefined then we won't need
basic_endpoint and basic_resovler anyway, so make them depend on those
macros.
libstdc++-v3/ChangeLog:
On Fri, 9 Jun 2023 at 10:09, Jakub Jelinek wrote:
> On Fri, Jun 09, 2023 at 11:02:48AM +0200, Richard Biener via Gcc-patches
> wrote:
> > > Currently both gcc-13 and trunk are at the same library version,
> > > libstdc++.so.6.0.32
> > >
> > > But with this addition to trunk we need to bump that
Tested x86_64-linux, powerpc64le-linux, sparcv9-solaris. Pushed to
trunk.
There's no new GLIBCXX_3.4.33 symbol version yet, because we have
nothing to put in it. The bump is because of the new CXXABI_1.3.15
version.
-- >8 --
The addition of __cxa_call_terminate@@CXXABI_1.3.15 on trunk means we
Tested powerpc64le-linux. Pushed to trunk.
I'll backport it to gcc-13 later.
-- >8 --
I had intended to support the P2510R3 proposal unconditionally in C++20
mode, but I left it half implemented. The parse function supported the
new extensions, but the format function didn't.
This adds the
Tested powerpc64le-linux. Pushed to trunk.
This makes sense to backport after some soak time on trunk.
-- >8 --
As reported in PR libstdc++/110167, std::to_array compiles extremely
slowly for very large arrays. It needs to instantiate a very large
specialization of std::index_sequence and then
Richard Biener writes:
> On Fri, Jun 9, 2023 at 11:45 AM Andrew Stubbs wrote:
>>
>> On 09/06/2023 10:02, Richard Sandiford wrote:
>> > Andrew Stubbs writes:
>> >> On 07/06/2023 20:42, Richard Sandiford wrote:
>> >>> I don't know if this helps (probably not), but we have a similar
>> >>>
On Fri, Jun 9, 2023 at 11:58 AM Lehua Ding wrote:
>
> > It's odd that the checksum doesn't depend on the number of iterations done
> > ...
>
> This is because the difference between the calculated result (32063.902344)
> and
> the expected result (32000.00) is small. The current check is
On Fri, 9 Jun 2023, Richard Biener wrote:
> On Fri, 9 Jun 2023, Richard Biener wrote:
>
> > The following makes sure that using TYPE_PRECISION on VECTOR_TYPE
> > ICEs when tree checking is enabled. This should avoid wrong-code
> > in cases like PR110182 and instead ICE.
> >
> > Bootstrap and
On Fri, Jun 9, 2023 at 11:45 AM Andrew Stubbs wrote:
>
> On 09/06/2023 10:02, Richard Sandiford wrote:
> > Andrew Stubbs writes:
> >> On 07/06/2023 20:42, Richard Sandiford wrote:
> >>> I don't know if this helps (probably not), but we have a similar
> >>> situation on AArch64: a 64-bit mode
Thanks a lot Richi.
Even though last time Richard asked me no need to wait for 2nd ACK,
I am still want to wait for Richard final approval since I am not sure this
patch is ok for him.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-06-09 19:02
To: Ju-Zhe Zhong
CC: gcc-patches;
On Fri, 9 Jun 2023, Richard Biener wrote:
> The following makes sure that using TYPE_PRECISION on VECTOR_TYPE
> ICEs when tree checking is enabled. This should avoid wrong-code
> in cases like PR110182 and instead ICE.
>
> Bootstrap and regtest pending on x86_64-unknown-linux-gnu, I guess
>
Thanks, Richi.
Should I wait for Richard ACK gain ?
Since the last email of this patch, he just asked me to adjust comment no codes
change.
I am not sure whether he is ok.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-06-09 19:02
To: Ju-Zhe Zhong
CC: gcc-patches;
On Fri, 9 Jun 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Co-authored-by: Richard Sandiford
> Co-authored-by: Richard Biener
>
> This patch address comments from Richard && Richi and rebase to trunk.
>
> This patch is adding SELECT_VL middle-end support
> allow target have
On Fri, 9 Jun 2023, Jiufu Guo wrote:
>
> Hi,
>
> Richard Biener writes:
>
> > On Fri, 9 Jun 2023, Richard Sandiford wrote:
> >
> >> guojiufu writes:
> >> > Hi,
> >> >
> >> > On 2023-06-09 16:00, Richard Biener wrote:
> >> >> On Fri, 9 Jun 2023, Jiufu Guo wrote:
> >> >>
> >> >>> Hi,
> >> >>>
This patch removed 2nd time initialization of RTL_SSA which is the approach we
both hate.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-06-09 18:45
To: juzhe.zhong
CC: gcc-patches; kito.cheng; palmer; palmer; jeffreyalaw; rdapp.gcc; pan2.li
Subject: Re: [PATCH V2] RISC-V: Rework Phase 5
Thankful you send this before weekend, I could run the fuzzy testing
during this weekend :P
On Fri, Jun 9, 2023 at 6:41 PM wrote:
>
> From: Juzhe-Zhong
>
> This patch is to rework Phase 5 && Phase 6 of VSETVL PASS since Phase 5 &&
> Phase 6
> are quite messy and cause some bugs discovered by
From: Juzhe-Zhong
This patch is to rework Phase 5 && Phase 6 of VSETVL PASS since Phase 5 &&
Phase 6
are quite messy and cause some bugs discovered by my downstream
auto-vectorization
test-generator.
Before this patch.
Phase 5 is cleanup_insns is the function remove AVL operand dependency
From: Juzhe-Zhong
This patch is to rework Phase 5 && Phase 6 of VSETVL PASS since Phase 5 &&
Phase 6
are quite messy and cause some bugs discovered by my downstream
auto-vectorization
test-generator.
Before this patch.
Phase 5 is cleanup_insns is the function remove AVL operand dependency
> It's odd that the checksum doesn't depend on the number of iterations done ...
This is because the difference between the calculated result (32063.902344) and
the expected result (32000.00) is small. The current check is that the
result
is considered correct as long as the `value/expected`
Hmmm, I still saw some fail on testsuite after applying this patch,
most are because the testcase has used vector type as argument or
return value, but .. vector-abi-1.c should not fail I think?
For other fails, I would suggest you could just add -Wno-psabi to rvv.exp
=== gcc:
On 09/06/2023 10:02, Richard Sandiford wrote:
Andrew Stubbs writes:
On 07/06/2023 20:42, Richard Sandiford wrote:
I don't know if this helps (probably not), but we have a similar
situation on AArch64: a 64-bit mode like V8QI can be doubled to a
128-bit vector or to a pair of 64-bit vectors.
Just finish running Boostrap on X86 has passed.
Ok for trunk?
Thanks.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-06-09 16:39
To: gcc-patches
CC: richard.sandiford; rguenther; Ju-Zhe Zhong
Subject: [PATCH V6] VECT: Add SELECT_VL support
From: Ju-Zhe Zhong
Co-authored-by: Richard
On Fri, Jun 09, 2023 at 11:06:04AM +0200, Richard Biener via Gcc-patches wrote:
> On Fri, Jun 9, 2023 at 3:48 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > So for the attached testcase, we assumed that zero_one_valued_p would
> > be the value [0,1] but currently zero_one_valued_p matches also
Hi,
Richard Biener writes:
> On Fri, 9 Jun 2023, Richard Sandiford wrote:
>
>> guojiufu writes:
>> > Hi,
>> >
>> > On 2023-06-09 16:00, Richard Biener wrote:
>> >> On Fri, 9 Jun 2023, Jiufu Guo wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> As checking the code, there is a "gcc_assert
On Fri, Jun 09, 2023 at 11:02:48AM +0200, Richard Biener via Gcc-patches wrote:
> > Currently both gcc-13 and trunk are at the same library version,
> > libstdc++.so.6.0.32
> >
> > But with this addition to trunk we need to bump that .32 to .33, meaning
> > that gcc-13 and trunk diverge. If we
On Fri, 9 Jun 2023 at 10:03, Richard Biener
wrote:
> On Thu, Jun 8, 2023 at 3:14 PM Jonathan Wakely via Gcc-patches
> wrote:
> >
> > On Fri, 26 May 2023 at 10:58, Jonathan Wakely wrote:
> >
> > >
> > >
> > > On Wed, 24 May 2023 at 19:56, Jason Merrill via Libstdc++ <
> > >
On Fri, Jun 9, 2023 at 3:48 AM Andrew Pinski via Gcc-patches
wrote:
>
> So for the attached testcase, we assumed that zero_one_valued_p would
> be the value [0,1] but currently zero_one_valued_p matches also
> signed 1 bit integers.
> This changes that not to match that and fixes the 2 new
1 - 100 of 136 matches
Mail list logo
