On Mon, Mar 4, 2024 at 12:13 AM Fangrui Song wrote:
>
> From: Fangrui Song
>
> -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
> for FDPIC (absolute addressing for symbol references and no function
> descriptor). The sh port simply upgrades -fno-pic to -fpie by setting
> f
Hi, Robin.
I saw vwadd/vwsub.wx have same issue. Could you change them and add test too ?
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-05-14 04:15
To: gcc-patches
CC: rdapp.gcc; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
Subject: [PATCH] RISC-V: Do not allow v0 as dest
>> Seems a bit odd on first sight. If all we want to do is to
>> select between two masks why do we need a large Pmode mode?
Since we are lowering final mask = vcond_mask_len (mask, 1s, 0s, len, bias),
into:
vid.v v1
vcmp v2
vmsltu.vx v2, v1, len, TUMU
Then len is Pmode, so we only allow to low
The validator warns about as deprecated; use instead.
Pushed.
Gerald
---
htdocs/projects/cxx-dr-status.html | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/htdocs/projects/cxx-dr-status.html
b/htdocs/projects/cxx-dr-status.html
index c70cdf21..e29d2407 100644
LGTM
juzhe.zh...@rivai.ai
On Mon, May 13, 2024 at 02:46:32PM -0600, Jeff Law wrote:
>
>
> On 5/13/24 1:48 PM, Qing Zhao wrote:
> > -Warray-bounds is an important option to enable linux kernal to keep
> > the array out-of-bound errors out of the source tree.
> >
> > However, due to the false positive warnings reported in
On 5/13/24 3:13 PM, Vineet Gupta wrote:
On 5/13/24 11:49, Vineet Gupta wrote:
500.perlbench_r-0 | 1,214,534,029,025 | 1,212,887,959,387 |
500.perlbench_r-1 |740,383,419,739 | 739,280,308,163 |
500.perlbench_r-2 |692,074,638,817 | 691,118,734,547 |
502.gcc_r-0 |1
On 5/13/24 15:47, Jeff Law wrote:
>> On 5/13/24 11:49, Vineet Gupta wrote:
>>> 500.perlbench_r-0 | 1,214,534,029,025 | 1,212,887,959,387 |
>>> 500.perlbench_r-1 |740,383,419,739 | 739,280,308,163 |
>>> 500.perlbench_r-2 |692,074,638,817 | 691,118,734,547 |
>>> 502.gcc_r-0
On 12/19/23 10:28 PM, Jeff Law wrote:
On 12/19/23 02:53, Sergei Lewis wrote:
gcc/ChangeLog
* config/riscv/riscv.md (movmem): Use
riscv_vector::expand_block_move,
if and only if we know the entire operation can be performed
using one vector
load followed by one vector stor
On Mon, May 13, 2024, 11:41 PM Kees Cook wrote:
> On Mon, May 13, 2024 at 02:46:32PM -0600, Jeff Law wrote:
> >
> >
> > On 5/13/24 1:48 PM, Qing Zhao wrote:
> > > -Warray-bounds is an important option to enable linux kernal to keep
> > > the array out-of-bound errors out of the source tree.
> > >
On Tue, May 14, 2024 at 01:38:49AM +0200, Andrew Pinski wrote:
> On Mon, May 13, 2024, 11:41 PM Kees Cook wrote:
> > But it makes no sense to warn about:
> >
> > void sparx5_set (int * ptr, struct nums * sg, int index)
> > {
> >if (index >= 4)
> > warn ();
> >*ptr = 0;
> >*val = s
On 5/13/24 13:28, Jeff Law wrote:
On 5/13/24 12:49 PM, Vineet Gupta wrote:
If the constant used for stack offset can be expressed as sum of two S12
values, the constant need not be materialized (in a reg) and instead the
two S12 bits can be added to instructions involved with frame pointer.
This patch folds vget_low_* intrinsics to BIT_FILED_REF to open up more
optimization opportunities for gimple optimizers.
While we are here, we also remove the vget_low_* definitions from arm_neon.h and
use the new intrinsics framework.
PR target/102171
gcc/ChangeLog:
* config/a
Ack, thanks Jeff and will fix it ASAP.
Pan
-Original Message-
From: Jeff Law
Sent: Tuesday, May 14, 2024 2:10 AM
To: Li, Pan2 ; Kito Cheng ;
juzhe.zh...@rivai.ai
Cc: gcc-patches
Subject: Re: [PATCH v1] RISC-V: Bugfix ICE for RVV intrinisc vfw on _Float16
scalar
On 5/13/24 9:00 AM,
From: Pan Li
This patch would like to fix below format issue of trailing operator.
=== ERROR type #1: trailing operator (4 error(s)) ===
gcc/config/riscv/riscv-vector-builtins.cc:4641:39: if ((exts &
RVV_REQUIRE_ELEN_FP_16) &&
gcc/config/riscv/riscv-vector-builtins.cc:4651:39: if ((exts &
RVV_
> That's just a matter of matching the overflow as an additional case no?
> i.e. you can add an overload for unsigned_integer_sat_add matching the
> IFN_ ADD_OVERFLOW and using the realpart and imagpart helpers.
> I think that would be better as it avoid visiting all the statements twice
> but
Hi,
on 2024/4/20 05:17, Carl Love wrote:
> rs6000, remove duplicated built-ins of vecmergl and vec_mergeh
>
> The following undocumented built-ins are same as existing documented
> overloaded builtins.
>
> const vf __builtin_vsx_xxmrghw (vf, vf);
> same as vf __builtin_vec_mergeh (vf, vf);
Hi Aldy,
Thanks for your review comments.
在 2024/5/13 19:18, Aldy Hernandez 写道:
> On Thu, May 9, 2024 at 10:05 AM Mikael Morin wrote:
>>
>> Hello,
>>
>> Le 07/05/2024 à 04:37, HAO CHEN GUI a écrit :
>>> Hi,
>>>The former patch adds isfinite optab for __builtin_isfinite.
>>> https://gcc.gnu.
Do you have any advice?
BRs,
Lin
-Original Message-
From: Hu, Lin1
Sent: Wednesday, May 8, 2024 9:38 AM
To: gcc-patches@gcc.gnu.org
Cc: Liu, Hongtao ; ubiz...@gmail.com
Subject: [PATCH] vect: generate suitable convert insn for int -> int, float ->
float and int <-> float.
Hi, all
Thi
Hi,
Thanks for your helpful comments!
Segher Boessenkool writes:
> Hi!
>
> On Mon, May 13, 2024 at 10:57:12AM +0800, Jiufu Guo wrote:
>> For PR96866, when gcc print asm code for modifier "%a" which requires
>> an address operand,
>
> It requires a *memory* operand, and it outputs its address.
Hi,
on 2024/4/20 05:17, Carl Love wrote:
> rs6000, add overloaded vec_sel with int128 arguments
>
> Extend the vec_sel built-in to take three signed/unsigned int128 arguments
> and return a signed/unsigned int128 result.
>
> Extending the vec_sel built-in makes the existing buit-ins
> __builtin_
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove the vec_xxsel built-ins, they are duplicates
>
> The following undocumented built-ins are covered by the existing overloaded
> vec_sel built-in definitions.
>
> const vsc __builtin_vsx_xxsel_16qi (vsc, vsc, vsc);
> same as vsc __builtin
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove __builtin_vsx_vperm_* built-ins
>
> The undocumented built-ins:
> __builtin_vsx_vperm_16qi_uns,
> __builtin_vsx_vperm_1ti,
> __builtin_vsx_vperm_1ti_uns,
> __builtin_vsx_vperm_2df,
> __builtin_vsx_vperm_2di,
> __builtin_vsx_vpe
Hi,
Thanks a lot for your helpful review!
"Kewen.Lin" writes:
> Hi,
>
> on 2024/5/13 10:57, Jiufu Guo wrote:
>> Hi,
>>
>> For PR96866, when gcc print asm code for modifier "%a" which requires
>> an address operand, while the operand is with the constraint "X" which
>> allow non-address form.
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove __builtin_vsx_xvnegdp and __builtin_vsx_xvnegsp built-ins
>
> The undocumented __builtin_vsx_xvnegdp and __builtin_vsx_xvnegsp are
> redundant. The overloaded vec_neg built-in provides the same
> functionality. The two buit-ins are not d
Hi,
on 2024/5/14 11:00, Jiufu Guo wrote:
> Hi,
>
> Thanks a lot for your helpful review!
>
> "Kewen.Lin" writes:
>
>> Hi,
>>
>> on 2024/5/13 10:57, Jiufu Guo wrote:
>>> Hi,
>>>
>>> For PR96866, when gcc print asm code for modifier "%a" which requires
>>> an address operand, while the operand i
Hi,
"Kewen.Lin" writes:
> Hi,
>
> on 2024/5/14 11:00, Jiufu Guo wrote:
>> Hi,
>>
>> Thanks a lot for your helpful review!
>>
>> "Kewen.Lin" writes:
>>
>>> Hi,
>>>
>>> on 2024/5/13 10:57, Jiufu Guo wrote:
Hi,
For PR96866, when gcc print asm code for modifier "%a" which requires
On 5/13/24 6:54 PM, Patrick O'Neill wrote:
On 5/13/24 13:28, Jeff Law wrote:
On 5/13/24 12:49 PM, Vineet Gupta wrote:
If the constant used for stack offset can be expressed as sum of two S12
values, the constant need not be materialized (in a reg) and instead the
two S12 bits can be added
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, extend vec_xxpermdi built-in for __int128 args
>
> Add a new overloaded instance for vec_xxpermdi
>
>__int128 vec_xxpermdi (__int128, __int128, const int);
>
> Update the documentation to include a reference to the new built-in
> instance.
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove __builtin_vsx_xvcmpeqsp built-in
>
> The built-in __builtin_vsx_xvcmpeqsp is a duplicate of the overloaded
> vec_cmpeq built-in. The built-in is undocumented. The built-in and
> the test cases are removed.
>
> gcc/ChangeLog:
> * c
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove vector set and vector init built-ins.
>
> The vector init built-ins:
>
> __builtin_vec_init_v16qi, __builtin_vec_init_v8hi,
> __builtin_vec_init_v4si, __builtin_vec_init_v4sf,
> __builtin_vec_init_v2di, __builtin_vec_init_v2df,
>
On Thu, May 9, 2024 at 11:12 AM Levy Hsu wrote:
>
> Hi All
>
> We've introduced a new subroutine in ix86_expand_vec_perm_const_1
> to optimize vector shifting for the V16QI type on x86.
> This patch uses a three-instruction sequence psrlw, psllw, and por
> to handle specific vector shuffle operati
101 - 132 of 132 matches
Mail list logo
