On Thu, Apr 13, 2023 at 4:25 PM Andre Vieira (lists)
wrote:
>
>
>
> On 13/04/2023 15:00, Richard Biener wrote:
> > On Thu, Apr 13, 2023 at 3:00 PM Andre Vieira (lists) via Gcc-patches
> > wrote:
> >>
> >>
> >>
> >> On 13/04/2023 11:01, Andrew Stubbs wrote:
> >>> Hi Andre,
> >>>
> >>> I don't have
On Fri, 14 Apr 2023, juzhe.zh...@rivai.ai wrote:
> And also I already decided to make remove WHILE_LEN pattern since it seems to
> be unnecessary.
> And as Richard said, it's just a simple airthmetic and it's not worthwhile to
> do that.
>
> So, I plan to replace WHILE_LEN into MIN_EXPR and mak
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 Mes
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,
>> Yeah, MIN_EXPR is enough for IBM ports, but with seeing the special semantic
>> of vsetvli on
>> "vl = ceil(AVL / 2) for VLMAX < AVL < 2*VLMAX", I'm not sure if it's a good
>> idea for RV, it seems
>> to put the burden to RV backend. For one case that the iteration count is
>> known, on the
Hi Juzhe,
on 2023/4/14 11:39, juzhe.zh...@rivai.ai wrote:
> And also I already decided to make remove WHILE_LEN pattern since it seems to
> be unnecessary.
> And as Richard said, it's just a simple airthmetic and it's not worthwhile to
> do that.
> > So, I plan to replace WHILE_LEN into MIN_EXPR
Hi Juzhe,
>>> Yes, we just wants to add the whole vector register length in bytes.
> OK, I learn it and appreciate you give me the information.
>
>>> I wonder if you also want WHILE_LEN to have the implicit effect
>>>to update vector length register?
>>>From this perspective, Richi's
>>>suggestio
Hi Haochen,
on 2023/4/14 09:34, HAO CHEN GUI wrote:
> Hi Kewen,
>
> 在 2023/4/13 16:32, Kewen.Lin 写道:
>> xfail all powerpc*-*-* can have some XPASSes on those ENVs with
>> software emulation. Since the related hw insn xscmpuqp is guarded
>> with TARGET_FLOAT128_HW, could we use the effective targ
This also implements the approved follow-up LWG issues 3765, 3766, 3769,
3770, 3811, 3850, 3853, 3862 and 3872.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (const_iterator_t): Define for C++23.
(const_sentinel_t
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h: Include for C++23.
(__cpp_lib_fold): Define for C++23.
(in_value_result): Likewise.
(__detail::__flipped): Likewise.
(__detail::__indirectly_b
This moves down the definitions of the const range access CPOs to after
the definition of input_range in preparation for implementing P2287R4
which redefines these CPOs in a way that indirectly uses input_range.
tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
And also I already decided to make remove WHILE_LEN pattern since it seems to
be unnecessary.
And as Richard said, it's just a simple airthmetic and it's not worthwhile to
do that.
So, I plan to replace WHILE_LEN into MIN_EXPR and make everything RVV specific
done in RISC-V port.
I think it's m
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. Wa
From: Pan Li
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
Hi,
On 2023-04-13 20:08, Segher Boessenkool wrote:
On Thu, Apr 13, 2023 at 07:39:01AM +, Richard Biener wrote:
On Thu, 13 Apr 2023, Jiufu Guo wrote:
I think this should be fixed in the analyzer, "stripping" malloc
tracking from fopen/fclose since it does this manually. I've adjusted
the bu
>> Yes, we just wants to add the whole vector register length in bytes.
OK, I learn it and appreciate you give me the information.
>> I wonder if you also want WHILE_LEN to have the implicit effect
>>to update vector length register?
>>From this perspective, Richi's
>>suggestion on "tieing the sca
Hi Juzhe,
on 2023/4/13 21:44, 钟居哲 wrote:
> Thanks Kewen.
>
> Current flow in this patch like you said:
>
> len = WHILE_LEN (n,vf);
> ...
> v = len_load (addr,len);
> ..
> addr = addr + vf (in byte align);
>
>
> This patch is just keep adding address with a vector factor (adjust as byte
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
There are sorts of shortcut codegen for th
From: Pan Li
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
Sure thing, let me update it ASAP.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, April 14, 2023 10:35 AM
To: Li, Pan2 ; gcc-patches
Cc: Kito.cheng ; Wang, Yanzhang
; Li, Pan2
Subject: Re: [PATCH] RISC-V: Add test cases for the RVV mask insn shortcut.
+/* { dg-final { scan-assembler-not {vman
+/* { dg-final { scan-assembler-not {vmand\.mm\s+v[0-9]+,\s*v[0-9]+} } } */
+/* { dg-final { scan-assembler-not {vmnand\.mm\s+v[0-9]+,\s*v[0-9]+} } } */
+/* { dg-final { scan-assembler-not {vmnandn\.mm\s+v[0-9]+,\s*v[0-9]+} } } */
+/* { dg-final { scan-assembler-not {vmxor\.mm\s+v[0-9]+,\s*v[0-9]+
From: Pan Li
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
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/gcc/zh_CN.po
(This file, 'gcc-13.1-
Thanks for catch this, I didn't enable multilib for linux toolchain
for a while,
I guess we should implement TARGET_COMPUTE_MULTILIB for linux targets
to simplify the damm multilib files, but I agree it's too late in the
release cycle, so let's fix that in this way for now.
So LGTM and OK for trun
From: Juzhe-Zhong
gcc/ChangeLog:
* config/riscv/riscv-modes.def (FLOAT_MODE): Add chunk 128 support.
(VECTOR_BOOL_MODE): Ditto.
(ADJUST_NUNITS): Ditto.
(ADJUST_ALIGNMENT): Ditto.
(ADJUST_BYTESIZE): Ditto.
(ADJUST_PRECISION): Ditto.
(RVV_MOD
Hi Kewen,
在 2023/4/13 16:32, Kewen.Lin 写道:
> xfail all powerpc*-*-* can have some XPASSes on those ENVs with
> software emulation. Since the related hw insn xscmpuqp is guarded
> with TARGET_FLOAT128_HW, could we use the effective target
> ppc_float128_hw instead?
Thanks for your review comments
AmpereOne (-mcpu=ampere1) breaks LDP instructions into two uops.
Given the chance that this causes instructions to slip into the next
decoding cycle and the additional overheads when handling
cacheline-crossing LDP instructions, we disable the generation of LDP
isntructions through the tuning struc
Hi all, Janne!
On Wed, 19 Sep 2018 16:40:01 +0200
Bernhard Reutner-Fischer wrote:
> On Fri, 7 Sep 2018 at 10:07, Bernhard Reutner-Fischer
> wrote:
> >
> > On Wed, 5 Sep 2018 at 20:57, Janne Blomqvist
> > wrote:
> > >
> > > On Wed, Sep 5, 2018 at 5:58 PM Bernhard Reutner-Fischer
> > > wrote
Dear all,
I've committed the attached patch which fixes a portability issue
when bootstrapping on Solaris. Discussed and confirmed in the PR
by Jonathan for Solaris and regtested by me on x86_64-pc-linux-gnu.
https://gcc.gnu.org/g:43816633afd275a9057232a6ebfdc19e441f09ec
(Unfortunately the comm
It looks like multilib-generator hasn't been run for t-linux-multilib in
a while and it's pretty broken. In order to regenerate the stub with
support for V I needed a pair of fixes:
* All extensions were being prefixed with an underscore, which leads to
some odd combinations like "rv32gc_v", th
GCC maintainers:
The following patch adds an overloaded builtin. There are two possible
arguments for the builtin. The builtin definitions are:
double __builtin_mffscrn (unsigned long int);
double __builtin_mffscrn (double);
The patch has been tested on Power 10 with no regressions.
P
GCC maintainers:
The following patch fixes the dg-options for test powerpc/rs600-
fpint.c. The test now works correctly on Power 10. The patch has been
tested on Power10 with no regressions.
Please let me know if the patch is acceptable for mainline. Thanks.
Carl
-
On 4/13/23 07:45, Jakub Jelinek wrote:
On Thu, Apr 13, 2023 at 06:35:07AM -0600, Jeff Law wrote:
Bootstrap was successful with v3, but there's hundreds of testsuite failures
due to the simplify-rtx hunk. compile/20070520-1.c for example when
compiled with: -O3 -funroll-loops -march=rv64gc -
On 4/5/23 13:31, Patrick Palka wrote:
On Wed, 5 Apr 2023, Patrick Palka wrote:
r13-6098-g46711ff8e60d64 made make_typename_type no longer ignore
non-types during the lookup, unless the TYPENAME_TYPE in question was
followed by the :: scope resolution operator. But there is another
exception to
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
An incomplete type argument to several traits is specified to be undefined
behavior in the library; since it's a compile-time property, we diagnose
it. But apparently some code was relying on the previous behavior of not
diagnosing. So let
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Like other diagnostic functions that might be silenced by options, it should
return whether or not it actually emitted a diagnostic.
gcc/cp/ChangeLog:
* typeck2.cc (cxx_incomplete_type_diagnostic): Return bool.
* cp-tree.h
GCC maintainers:
The following fix updates the expected instruction counts for the
test int_128bit-runnable.c test. The counts changed as a result of a
commit to support 128-bit integer divide and modulus. The change
resulted in two of the tests using vdivsq instructions rather than the
vextsd
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Croatian team of translators. The file is available at:
https://translationproject.org/latest/gcc/hr.po
(This file, 'gcc-13.1-b20230409.hr.po
> Am 13.04.2023 um 17:49 schrieb Andrew MacLeod :
>
>
>> On 4/13/23 09:56, Richard Biener wrote:
>>> On Wed, Apr 12, 2023 at 10:55 PM Andrew MacLeod wrote:
>>>
>>> On 4/12/23 07:01, Richard Biener wrote:
On Wed, Apr 12, 2023 at 12:59 PM Jakub Jelinek wrote:
> Would be nice.
>
> Am 13.04.2023 um 17:49 schrieb Andrew MacLeod :
>
>
>> On 4/13/23 09:56, Richard Biener wrote:
>>> On Wed, Apr 12, 2023 at 10:55 PM Andrew MacLeod wrote:
>>>
>>> On 4/12/23 07:01, Richard Biener wrote:
On Wed, Apr 12, 2023 at 12:59 PM Jakub Jelinek wrote:
> Would be nice.
>
Ok, thanks :)
Palmer Dabbelt 於 2023年4月13日 週四，23:12寫道：
> The RVV test harness currently sets the ISA according to the target
> tuple, but doesn't also set the ABI. This just sets the ABI to match
> the ISA, though we should really also be respecting the user's specific
> ISA to test.
>
> gcc/test
The aarch64 PCS rules ignore user alignment for scalars and
vectors and use the "natural" alignment of the type. GCC tried
to calculate that natural alignment using:
TYPE_ALIGN (TYPE_MAIN_VARIANT (type))
But as discussed in the PR, it's possible that the main variant
of a pointer type is an ov
On 4/13/23 09:56, Richard Biener wrote:
On Wed, Apr 12, 2023 at 10:55 PM Andrew MacLeod wrote:
On 4/12/23 07:01, Richard Biener wrote:
On Wed, Apr 12, 2023 at 12:59 PM Jakub Jelinek wrote:
Would be nice.
Though, I'm afraid it still wouldn't fix the PR101912 testcase, because
it has exactl
The RVV test harness currently sets the ISA according to the target
tuple, but doesn't also set the ABI. This just sets the ABI to match
the ISA, though we should really also be respecting the user's specific
ISA to test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.exp (gcc_mabi)
On 4/13/23 07:45, Jakub Jelinek wrote:
On Thu, Apr 13, 2023 at 06:35:07AM -0600, Jeff Law wrote:
Bootstrap was successful with v3, but there's hundreds of testsuite failures
due to the simplify-rtx hunk. compile/20070520-1.c for example when
compiled with: -O3 -funroll-loops -march=rv64gc -
On 13/04/2023 15:00, Richard Biener wrote:
On Thu, Apr 13, 2023 at 3:00 PM Andre Vieira (lists) via Gcc-patches
wrote:
On 13/04/2023 11:01, Andrew Stubbs wrote:
Hi Andre,
I don't have a cascadelake device to test on, nor any knowledge about
what makes it different from regular x86_64.
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
> > over
On Thu, Apr 13, 2023 at 3:00 PM Andre Vieira (lists) via Gcc-patches
wrote:
>
>
>
> On 13/04/2023 11:01, Andrew Stubbs wrote:
> > Hi Andre,
> >
> > I don't have a cascadelake device to test on, nor any knowledge about
> > what makes it different from regular x86_64.
>
> Not sure you need one, but
On Wed, Apr 12, 2023 at 10:55 PM Andrew MacLeod wrote:
>
>
> On 4/12/23 07:01, Richard Biener wrote:
> > On Wed, Apr 12, 2023 at 12:59 PM Jakub Jelinek wrote:
> >>
> >> Would be nice.
> >>
> >> Though, I'm afraid it still wouldn't fix the PR101912 testcase, because
> >> it has exactly what happen
On Thu, Apr 13, 2023 at 06:35:07AM -0600, Jeff Law wrote:
> Bootstrap was successful with v3, but there's hundreds of testsuite failures
> due to the simplify-rtx hunk. compile/20070520-1.c for example when
> compiled with: -O3 -funroll-loops -march=rv64gc -mabi=lp64d
>
> Thursdays are my hell d
Thanks Kewen.
Current flow in this patch like you said:
len = WHILE_LEN (n,vf);
...
v = len_load (addr,len);
..
addr = addr + vf (in byte align);
This patch is just keep adding address with a vector factor (adjust as byte
align).
For example, if your vector length = 512bit. Then this p
I've tried my hands on this first patch, to add new warnings for
name-hiding, i.e.
when a derived class's field shares the name of a base class's field.
I have currently put it under -Wshadow, but I could instead add a
-Wname-hiding warning, what do you think about this ?
At the moment, I'm using
钟居哲 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 prob
At some point I elided the NULL pointer check in expressions_equal_p
because it shouldn't be necessary not realizing that for example
TARGET_MEM_REF has optional operands we cannot substitute with
something non-NULL with the same semantics. The following does the
simple thing and restore the check
On 13/04/2023 11:01, Andrew Stubbs wrote:
Hi Andre,
I don't have a cascadelake device to test on, nor any knowledge about
what makes it different from regular x86_64.
Not sure you need one, but yeah I don't know either, it looks like it
fails because:
in-branch vector clones are not yet
On 4/13/23 04:57, Segher Boessenkool wrote:
On Wed, Apr 12, 2023 at 10:05:08PM -0600, Jeff Law wrote:
On 4/12/23 10:58, Jakub Jelinek wrote:
Seems my cross defaulted to 32-bit compilation, reproduced it with
additional -mabi=lp64 -march=rv64gv even on the pr108947.c test.
So, let's include t
在 2023/4/13 下午8:24, Xi Ruoyao 写道:
On Thu, 2023-04-13 at 19:51 +0800, Lulu Cheng wrote:
In some cases, setting this macro as the default can reduce the number of
conditional
branch instructions.
gcc/ChangeLog:
* config/loongarch/loongarch.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Remove
th
From: Juzhe-Zhong
Since multiple conflicts with previous patch.
Rebase to the trunk and resend it.
gcc/ChangeLog:
* config/riscv/riscv-modes.def (FLOAT_MODE): Add chunk 128 modes.
(VECTOR_BOOL_MODE): Ditto.
(ADJUST_NUNITS): Ditto.
(ADJUST_ALIGNMENT): Ditto.
On Thu, 2023-04-13 at 19:51 +0800, Lulu Cheng wrote:
> In some cases, setting this macro as the default can reduce the number of
> conditional
> branch instructions.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Remove
> the macro
> defini
On Thu, Apr 13, 2023 at 07:39:01AM +, Richard Biener wrote:
> On Thu, 13 Apr 2023, Jiufu Guo wrote:
> I think this should be fixed in the analyzer, "stripping" malloc
> tracking from fopen/fclose since it does this manually. I've adjusted
> the bug accordingly.
Yeah.
> > > +/* This case chec
In some cases, setting this macro as the default can reduce the number of
conditional
branch instructions.
gcc/ChangeLog:
* config/loongarch/loongarch.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Remove
the macro
definition.
---
gcc/config/loongarch/loongarch.h | 1 -
1 file changed, 1 de
Thank you very much for your comments. Since a long time has passed and this is
an initial version, I will update this patch.
--
From:Christoph Müllner
Sent At:2023 Apr. 13 (Thu.) 17:22
To:Jin Ma
Cc:gcc-patches ; kito.cheng ;
kito.
On Wed, Apr 12, 2023 at 10:05:08PM -0600, Jeff Law wrote:
> On 4/12/23 10:58, Jakub Jelinek wrote:
> >Seems my cross defaulted to 32-bit compilation, reproduced it with
> >additional -mabi=lp64 -march=rv64gv even on the pr108947.c test.
> >So, let's include that test in the patch too:
> >
> >2023-0
Hi Andre,
I don't have a cascadelake device to test on, nor any knowledge about
what makes it different from regular x86_64.
If the cascadelake device is supposed to work the same as other x86_64
devices for these vectors then the test has found a bug in the compiler
and you should be lookin
Thank you Richard.
>> But the issue is the same in the reverse with WHILE_LEN, no?
>>WHILE_LEN just computes a scalar value - you seem to suggest
>>there's a hidden side-effect of "coalescing" the result with
>>a hardware vector length register? I don't think that's good design.
No, I don't plan
On Fri, Mar 10, 2023 at 1:41 PM Jin Ma via Gcc-patches
wrote:
>
> This patch adds the 'Zfa' extension for riscv, which is based on:
>
> https://github.com/riscv/riscv-isa-manual/commit/d74d99e22d5f68832f70982d867614e2149a3bd7
> latest 'Zfa' change on the master branch of the RISC-V ISA Manual as
Hi,
@Andrew: Could you have a look at these? I had a quick look at 17f.c and it
looks to me like the target selectors aren't specific enough. Unfortunately I
am not familiar enough with target selectors (or targets for that matter) for
x86_64. From what I could tell with -m32 gcc decides to unr
Hi Haochen,
on 2023/4/12 10:27, HAO CHEN GUI wrote:
> Hi,
> This patch xfails a float128 comparison test case on powerpc64 that
> fails due to a longstanding issue with floating-point compares.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more
> information.
>
> The patch
Hi Jeff,
on 2023/4/13 15:45, guojiufu wrote:
> Hi,
>
> On 2023-04-12 20:47, Kewen.Lin wrote:
>> Hi Segher & Jeff,
>>
>> on 2023/4/11 23:13, Segher Boessenkool wrote:
>>> On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
on 2023/4/11 17:14, guojiufu wrote:
> Thanks for raising th
Hi Juzhe,
on 2023/4/12 21:22, 钟居哲 wrote:
> Thanks Kewen.
>
> It seems that this proposal WHILE_LEN can help s390 when using --param
> vect-partial-vector-usage=2 compile option.
>
Yeah, IMHO, the previous sequence vs. the proposed sequence are like:
int
foo (int *__restrict a, int *__restric
Hi,
On 2023-04-12 20:47, Kewen.Lin wrote:
Hi Segher & Jeff,
on 2023/4/11 23:13, Segher Boessenkool wrote:
On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
on 2023/4/11 17:14, guojiufu wrote:
Thanks for raising this concern.
The behavior to check about bif on FLOAT128_HW and emit an
on 2023/4/12 20:47, Kewen.Lin wrote:
> Hi Segher & Jeff,
>
> on 2023/4/11 23:13, Segher Boessenkool wrote:
>> On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
>>> on 2023/4/11 17:14, guojiufu wrote:
Thanks for raising this concern.
The behavior to check about bif on FLOAT128_HW
On Thu, 13 Apr 2023, Jiufu Guo wrote:
>
> Add more reviewers. :)
>
> Jiufu Guo writes:
>
> > Hi,
> >
> > The case file-CWE-1341-example.c checkes [CWE-1341](`double-fclose`).
> > While on some systems, besides [CWE-1341], a message of [CWE-415] is
> > also reported. On those systems, attribute
73 matches
Mail list logo
