Sorry for disturbing, update the V2 for resolving some typo and/or wording in
commit log.
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618882.html
Pan
-Original Message-
From: Li, Pan2
Sent: Thursday, May 18, 2023 11:17 AM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; ki
From: Pan Li
This patch support the RVV VREINTERPRET from the vbool*_t to the
vint*m1_t. Aka:
vint*m1_t __riscv_vreinterpret_x_x(vbool*_t);
These APIs help the users to convert vector the vbool*_t to the LMUL=1
signed integer vint*_t. According to the RVV intrinsic SPEC as below,
the reinterp
From: Pan Li
This patch support the RVV VREINTERPRET from the vbool*_t to the
vuint*m1_t. Aka:
vuint*m1_t __riscv_vreinterpret_x_x(vbool*_t);
These APIs help the users to convert vector the vbool*_t to the LMUL=1
unsigned integer vint*_t. According to the RVV intrinsic SPEC as below,
the rein
On Wed, May 17, 2023 at 8:44 PM Alexander Monakov via Gcc-patches
wrote:
>
> Since tree-ssa-math-opts may freely contract across statement boundaries
> we should enable it only for -ffp-contract=fast instead of disabling it
> for -ffp-contract=off.
>
> No functional change, since -ffp-contract=on
On Wed, May 17, 2023 at 9:19 AM Kewen.Lin wrote:
>
> Hi Richi,
>
> on 2023/5/17 14:34, Richard Biener wrote:
> > On Wed, May 17, 2023 at 8:09 AM Kewen.Lin wrote:
> >>
> >> Hi,
> >>
> >> This patch is to refactor the handlings for the case (index
> >> == count) in a loop of vect_transform_slp_perm
Thank you for catching this, Thomas!
I modified Makefile.tmp and regenerated Makefile.in.
Here is the patch I pushed:
[PATCH] Disable warnings as errors for STAGEautofeedback.
Compilation during STAGEautofeedback produces additional warnings
since inlining decisions with -fauto-profile are diffe
From: Pan Li
This patch support the RVV VREINTERPRET from the vbool*_t to the
vint*m1_t. Aka:
vint*m1_t __riscv_vreinterpret_x_x(vbool*_t);
These APIs help the users to convert vector the vbool*_t to the LMUL=1
signed integer vint*_t. According to the RVV intrinsic SPEC as below,
the reinterp
On 5/17/23 11:52 AM, Harald Anlauf via Fortran wrote:
Dear all,
the attached patch is neat, because it fixes a bug by removing code ;-)
When generating the initializer for a parameter array, we excepted
the case of size 0, which however prevented the detection of array
bounds violations and lea
WG14 decided to change the printf %B format from a recommended
extension to an optional feature defined in normative text. Thus,
change the format checking to handle %B like %b, so not diagnosing it
with -Wformat -std=c2x -pedantic, just as with other optional
normatively defined features (such as
PR 99451 is about the inability to name tree and rtl dumps by plugin name. And
includes a patch. But then I worked around the problem and forgot about it.
Here it is again, retested against trunk.
ok?
nathan
--
Nathan SidwellFrom e54518bc5e59ef5cdc21c652ceac41bd0c0f436c Mon Sep 17 00:00:00 2
On 5/17/23 03:03, Jin Ma wrote:
For example:
(define_insn "mov_lowpart_sidi2"
[(set (match_operand:SI0 "register_operand" "=r")
(subreg:SI (match_operand:DI 1 "register_operand" " r") 0))]
"TARGET_64BIT"
"mov\t%0,%1")
(define_insn "mov_highpart_sidi2"
[(set (m
On 5/17/23 03:08, Jin Ma wrote:
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Remove
trailing spaces on lines.
* config/riscv/riscv.cc (riscv_legitimize_move): Likewise.
* config/riscv/riscv.h (enum reg_class): Likewise.
* config/riscv/riscv.md:
Ping.
On Sat, 4 Feb 2023, at 10:50, Ed Catmur wrote:
> Per
> http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Variadic_templates
> DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:
>
> 17$: DW_TAG_formal_parameter_pack
> DW_AT_name("args")
> 18$: DW_TAG_fo
Thank you!
On Wed, May 17, 2023 at 8:53 AM Patrick Palka wrote:
>
> On Fri, 12 May 2023, Ken Matsui via Libstdc++ wrote:
>
> > It appears that GCC 13 has been released, but I am wondering if there
> > are any issues preventing this patch from being merged yet. Can you
> > provide any information
Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11.
Committed to trunk.
Dave
---
Add clear_cache expander.
2023-05-17 John David Anglin
gcc/ChangeLog:
* config/pa/pa.md (clear_cache): New.
diff --git a/gcc/config/pa/pa.md b/gcc/config/pa/pa.md
index 7b7d7f776c7..726e12768f8
gcc/ChangeLog:
* doc/extend.texi (C++ Concepts) : Remove extraneous
parenthesis. Fix misnamed index entry.
: Fix misnamed index entry.
---
Pushed as obvious.
gcc/doc/extend.texi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/doc/extend.tex
Le 17/05/2023 à 20:52, Harald Anlauf via Fortran a écrit :
Dear all,
the attached patch is neat, because it fixes a bug by removing code ;-)
When generating the initializer for a parameter array, we excepted
the case of size 0, which however prevented the detection of array
bounds violations an
-template
- _OutputIterator
-__brick_generate_n(_OutputIterator __first, _Size __count, _Generator __g,
/* is_vector = */ std::true_type) noexcept
+template
Missing uglification on Size.
+_RandomAccessIterator
+__brick_generate_n(_RandomAccessIterator __first, Size __count, _Generator
__g,
+
On Wed, 17 May 2023 at 19:18, Jakub Jelinek wrote:
> Hi!
>
> As can be seen on the following testcase, for
>
> std::{atan2,fmod,pow,copysign,fdim,fmax,fmin,hypot,nextafter,remainder,remquo,fma}
> if one operand type is std::float{16,32,64,128}_t or std::bfloat16_t and
> another one some integral
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
I don't know why these checks are disabled.
libstdc++-v3/ChangeLog:
* testsuite/18_support/headers/limits/synopsis.cc: Uncomment
checks for float_round_style and float_denorm_style.
---
libstdc++-v3/testsuite/18_support/header
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
Without this change many tests that depend on an effective-target will
fail when compiled with -pedantic -std=c++98. This happens because the
preprocessor check done by v3_check_preprocessor_condition uses -Werror
and includes directly (rather
Tested powerpc64le-linux. Pushed to trunk.
I'll probably backport this to gcc-13 too.
There are no tests for the changes to and_then and transform, because
LWG 3843 makes that hard to test. Both and_then and transform call
value(), which requires a copy constructible error_type. So we can test
th
On 5/17/23 10:02, Jivan Hakobyan via Gcc-patches wrote:
Subject:
[v2] RISC-V: Remove masking third operand of rotate instructions
From:
Jivan Hakobyan via Gcc-patches
Date:
5/17/23, 10:02
To:
gcc-patches@gcc.gnu.org
Rotate instructions do not need to mask the third operand.
For example, RV
Dear all,
the attached patch is neat, because it fixes a bug by removing code ;-)
When generating the initializer for a parameter array, we excepted
the case of size 0, which however prevented the detection of array
bounds violations and lead to ICEs in various places. The solution
which removes
Since tree-ssa-math-opts may freely contract across statement boundaries
we should enable it only for -ffp-contract=fast instead of disabling it
for -ffp-contract=off.
No functional change, since -ffp-contract=on is not exposed yet.
gcc/ChangeLog:
* tree-ssa-math-opts.cc (convert_mult_to
On Wed, May 17, 2023 at 8:08 PM Jakub Jelinek wrote:
>
> Hi!
>
> When _Float128 support has been added to C++ for 13.1, float128t_type_node
> tree has been added - in C float128_type_node and float128t_type_node is
> the same and represents both _Float128 and __float128, but in C++ they
> are dis
Returned integer vector mode costs of emulated modes in
ix86_multiplication_cost are wrong and do not reflect generated
instruction sequences. Rewrite handling of different integer vector
modes and different target ABIs to return real instruction
counts in order to calculate better costs of variou
Hi!
As can be seen on the following testcase, for
std::{atan2,fmod,pow,copysign,fdim,fmax,fmin,hypot,nextafter,remainder,remquo,fma}
if one operand type is std::float{16,32,64,128}_t or std::bfloat16_t and
another one some integral type or some other floating point type which
promotes to the other
Hi!
When _Float128 support has been added to C++ for 13.1, float128t_type_node
tree has been added - in C float128_type_node and float128t_type_node is
the same and represents both _Float128 and __float128, but in C++ they
are distinct types which have different handling in the FEs.
When doing th
Rotate instructions do not need to mask the third operand.
For example, RV64 the following code:
unsigned long foo1(unsigned long rs1, unsigned long rs2)
{
long shamt = rs2 & (64 - 1);
return (rs1 << shamt) | (rs1 >> ((64 - shamt) & (64 - 1)));
}
Compiles to:
foo1:
andia1,a1,
On Fri, 12 May 2023, Ken Matsui via Libstdc++ wrote:
> It appears that GCC 13 has been released, but I am wondering if there
> are any issues preventing this patch from being merged yet. Can you
> provide any information on this?
Thanks for the reminder, I pushed this to trunk just now
(r14-940-g
On Tue, 16 May 2023 at 00:29, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi Richard,
> > After committing the interleave+zip1 patch for vector initialization,
> > it seems to regress the s32 case for this patch:
> >
> > int32x4_t f_s32(int32_t x)
> > {
> > return (int32x4_t) {
Committed, thanks kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Wednesday, May 17, 2023 6:06 PM
To: juzhe.zh...@rivai.ai
Cc: gcc-patches@gcc.gnu.org; kito.ch...@gmail.com; pal...@dabbelt.com;
pal...@rivosinc.com; jeffreya...@gmail.com; rda
Committed, thanks kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Wednesday, May 17, 2023 11:05 PM
To: 钟居哲
Cc: Jeff Law ; gcc-patches ;
kito.cheng ; palmer ; palmer
; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Introduce rounding mode operand
LGTM, thanks!
钟居哲 於 2023年5月17日 週三，23:02寫道：
> Ping this patch which is the prerequisite of this patch:
>
> https://patchwork.sourceware.org/project/gcc/patch/20230517095818.1285188-1-juzhe.zh...@rivai.ai/
>
> which has been approved by kito.
>
> Is this patch also ok for trunk ?
>
> Thanks.
>
Hi, Kito. The intrinsic doc has updated fixed point enum.
This patch (You have LGTM) should be merged after this patch:
https://patchwork.sourceware.org/project/gcc/patch/20230517052521.405836-1-juzhe.zh...@rivai.ai/
Can you respond this patch ?
Thanks.
juzhe.zh...@rivai.ai
From: Kito Cheng
Committed as the below doc PR updated, thanks kito.
https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Wednesday, May 17, 2023 11:01 AM
To: juzhe.zh...@rivai.ai
Cc: gcc-patches@gcc.gnu.org;
On 5/17/23 16:30, Aldy Hernandez wrote:
This converts the lattice to store ranges in Value_Range instead of
value_range (*) to make it type agnostic, and adjust all users
accordingly.
I think it is a good example on converting from static ranges to more
general, type agnostic ones.
I've been
This converts the lattice to store ranges in Value_Range instead of
value_range (*) to make it type agnostic, and adjust all users
accordingly.
I think it is a good example on converting from static ranges to more
general, type agnostic ones.
I've been careful to make sure Value_Range never ends
This patch encapsulates the ipa_vr internals into an API. It also
makes it type agnostic, in preparation for upcoming changes to IPA.
Interestingly, there's a 0.44% improvement to IPA-cp, which I'm sure
we'll soak up with future changes in this area :).
BTW, there's a note here:
+ // vrange_sto
gcc/ChangeLog:
* value-range.h (Value_Range::operator=): New.
---
gcc/value-range.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index ab982d18402..af81d6080da 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@
The unsupported_range class is provided for completness sake. It is a
way to set VARYING/UNDEFINED ranges for unsupported ranges (currently
anything not float, integer, or pointer). You can't do anything with
them, except set_varying, and set_undefined. We will trap on any
other operation.
This
I'm pushing this in preparation for further changes in this area later today.
Aldy
On Thu, Apr 27, 2023 at 1:36 PM Aldy Hernandez wrote:
>
> Thanks. I will put it aside until I start posting the IPA patches.
>
> Aldy
>
> On Thu, Apr 27, 2023, 13:02 Richard Biener wrote:
>>
>> On Tue, Apr 18, 20
> -Original Message-
> From: Stam Markianos-Wright
> Sent: Wednesday, May 17, 2023 2:41 PM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Andrea Corallo
>
> Subject: [GCC12 backport] arm: MVE testsuite and backend bugfixes
>
>
> On 17/05/2023 10:26, Kyrylo Tka
On 17/05/2023 10:26, Kyrylo Tkachov wrote:
Hi Stam,
-Original Message-
From: Stam Markianos-Wright
Sent: Tuesday, May 16, 2023 2:32 PM
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov ; Richard Earnshaw
; Andrea Corallo
Subject: [GCC12 backport] arm: MVE testsuite and backend bugfixes
> > RISC-V glibc will require corresponding muilti-lib has built there,
> > otherwise will report something like:
> >
> > /usr/include/gnu/stubs.h:11:11: fatal error: gnu/stubs-ilp32d.h: No
> > such file or directory
> >
> > But actually we only require those fixed length types to compile and
> >
> I think to make a difference you need to hit the number of parallel fadd/fmul
> the pipeline can perform. I don't think issue width is ever a problem for
> chains w/o fma and throughput of fma vs fadd + fmul should be similar.
>
Yes, for x86 backend, fadd , fmul and fma have the same TP meanin
From: Lili Cui
Make some changes in reassoc pass to make it more friendly to fma pass later.
Using FMA instead of mult + add reduces register pressure and insruction
retired.
There are mainly two changes
1. Put no-mult ops and mult ops alternately at the end of the queue, which is
conducive to g
> Am 17.05.2023 um 08:55 schrieb Kito Cheng :
>
> RISC-V glibc will require corresponding muilti-lib has built there,
> otherwise will report something like:
>
> /usr/include/gnu/stubs.h:11:11: fatal error: gnu/stubs-ilp32d.h: No
> such file or directory
>
> But actually we only require tho
> Yeah. Like Tami says, this is what the instruction does.
>
> I think all three definitions are equivalent: the extend/operate/truncate
> one, the ?: one above, and the "max - min" one. Probably just personal
> preference as to which seems more natural.
Decided to switch to using the ?: one as
Hi Jakub,
On 16.05.23 13:00, Jakub Jelinek wrote:
On Tue, May 16, 2023 at 11:45:16AM +0200, Frederik Harwath wrote:
The place where different compilers implement the loop transformations
was discussed in an OpenMP loop transformation meeting last year. Two
compilers (another one and GCC with th
The patch has now been committed as r14-931-g80bb0b8a81fdc5
The only change is that I added the &&VAR_P in 'if (sym->ts.deferred &&
VAR_P (length))' in trans-decl.cc just to avoid potential issues in case
length is not a var decl (but e.g. a '0' tree node, cf. code).
Tobias
On 23.03.23 10:28, T
On Wed, 17 May 2023 at 10:38, Nathaniel Shead
wrote:
> On Wed, May 17, 2023 at 10:05:59AM +0100, Jonathan Wakely wrote:
> > On Wed, 17 May 2023 at 09:37, Nathaniel Shead wrote:
> >
> > > Now that GCC13.1 is released is it ok to merge? Thanks!
> > >
> >
> > Yes, I've been testing this locally, but
LGTM, it's really awesome, I know it's kind of blocking due to enum
stuff, so feel free to commit this once it unblock :)
On Wed, May 17, 2023 at 5:58 PM wrote:
>
> From: Juzhe-Zhong
>
> Hi, this patch support the new coming fixed-point intrinsics:
> https://github.com/riscv-non-isa/rvv-intrinsi
On Wed, 17 May 2023 at 10:32, Martin Jambor wrote:
> Hello,
>
> On Tue, May 16 2023, Jonathan Wakely via Gcc-patches wrote:
> > Tested powerpc64le-linux. Builds OK on djgpp too.
> >
> > Pushed to trunk.
> >
> > -- >8 --
> >
> > DJGPP (and maybe other targets) uses MAX_OFILE_ALIGNMENT=16 which mean
From: Juzhe-Zhong
Hi, this patch support the new coming fixed-point intrinsics:
https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222
Insert fixed-point rounding mode configuration by mode switching target hook.
Mode switching target hook is implemented applying LCM (Lazy code Motion).
S
On Wed, May 17, 2023 at 10:05:59AM +0100, Jonathan Wakely wrote:
> On Wed, 17 May 2023 at 09:37, Nathaniel Shead wrote:
>
> > Now that GCC13.1 is released is it ok to merge? Thanks!
> >
>
> Yes, I've been testing this locally, but I think it needs more work (sorry!)
>
> Looking at it again, I'm
Hello,
On Tue, May 16 2023, Jonathan Wakely via Gcc-patches wrote:
> Tested powerpc64le-linux. Builds OK on djgpp too.
>
> Pushed to trunk.
>
> -- >8 --
>
> DJGPP (and maybe other targets) uses MAX_OFILE_ALIGNMENT=16 which means
> that globals (and static objects) can't have alignment greater than
Hi Stam,
> -Original Message-
> From: Stam Markianos-Wright
> Sent: Tuesday, May 16, 2023 2:32 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
> ; Andrea Corallo
> Subject: [GCC12 backport] arm: MVE testsuite and backend bugfixes
>
> Hi all,
>
> We've recently
Hi,
I just want to backport the commit to gcc-13 branch:
commit 203f3060dd363361b172f7295f42bb6bf5ac0b3b
Author: Andreas Schwab
Date: Sat Apr 23 15:48:42 2022 +0200
riscv/linux: Don't add -latomic with -pthread
Now that we have support for inline subword atomic operations, it is no
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Remove
trailing spaces on lines.
* config/riscv/riscv.cc (riscv_legitimize_move): Likewise.
* config/riscv/riscv.h (enum reg_class): Likewise.
* config/riscv/riscv.md: Likewise.
---
gcc/common/config/ris
On Wed, 17 May 2023 at 09:37, Nathaniel Shead wrote:
> Now that GCC13.1 is released is it ok to merge? Thanks!
>
Yes, I've been testing this locally, but I think it needs more work (sorry!)
Looking at it again, I'm not sure why I asked for the additional tests
because if they fail, it's a proble
For example:
(define_insn "mov_lowpart_sidi2"
[(set (match_operand:SI0 "register_operand" "=r")
(subreg:SI (match_operand:DI 1 "register_operand" " r") 0))]
"TARGET_64BIT"
"mov\t%0,%1")
(define_insn "mov_highpart_sidi2"
[(set (match_operand:SI0 "register_ope
Now that GCC13.1 is released is it ok to merge? Thanks!
On Tue, Apr 18, 2023 at 6:48 PM Jonathan Wakely wrote:
>
> On Mon, 17 Apr 2023 at 09:11, Nathaniel Shead
> wrote:
> >
> > Hi, just checking whether there were any issues with this patch?
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-F
Hi!
When looking into _BitInt support, I've noticed unterminated parens in
a function comment.
Fixing thusly.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2023-05-17 Jakub Jelinek
* wide-int.cc (wi::from_array): Add missing closing paren in fu
From: Pan Li
This patch support the RVV VREINTERPRET from the int to the
vbool[2|4|8|16|32|64]_t. Aka:
vbool[2|4|8|16|32|64]_t __riscv_vreinterpret_x_x(v{u}int[8|16|32|64]_t);
These APIs help the users to convert vector LMUL=1 integer to
vbool[2-64]_t. According to the RVV intrinsic SPEC as b
On Mai 16 2023, Vineet Gupta wrote:
> Yes I was seeing similar tcl errors and such - and in my case an even
> higher count.
They are coming from commit d6654a4be3b.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for
Hi Richi,
on 2023/5/17 14:34, Richard Biener wrote:
> On Wed, May 17, 2023 at 8:09 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> This patch is to refactor the handlings for the case (index
>> == count) in a loop of vect_transform_slp_perm_load_1, in
>> order to prepare a subsequent adjustment on *nperm. T
Committed, thanks kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Wednesday, May 17, 2023 3:00 PM
To: Li, Pan2
Cc: juzhe.zh...@rivai.ai; gcc-patches ; Kito.cheng
; Wang, Yanzhang
Subject: Re: [PATCH] RISC-V: Support RVV VREINTERPRET from v{u}int*_t to
vbool1_t
ok, and also ok f
Hi!
On 2023-05-15T09:30:35+0200, Richard Biener via Gcc-patches
wrote:
> On Fri, May 12, 2023 at 10:35 PM Eugene Rozenfeld
> wrote:
>>
>> Thank you, Richard. I went with your suggestion. New patch:
>>
>>
>> [PATCH] Disable warnings as errors for STAGEautofeedback.
>>
>> Compilation during STAGE
ok, and also ok for those small API test in testsuite.
On Tue, May 16, 2023 at 9:10 AM Li, Pan2 via Gcc-patches
wrote:
>
> Kindly ping for this PATCH, 😉.
>
> Pan
>
> From: Li, Pan2
> Sent: Monday, May 15, 2023 11:25 AM
> To: juzhe.zh...@rivai.ai; gcc-patches
> Cc: Kito.cheng ; Wang, Yanzhang
>
71 matches
Mail list logo
