On 8/14/23 14:33, Edwin Lu wrote:
On 8/11/2023 6:29 AM, Jeff Law via Gcc-patches wrote:
On 8/10/23 21:45, Palmer Dabbelt wrote:
This seems pretty mechinacial: just scrub through our MDs to check
for any un-typed insns, then add the assert and fix the failures.
You're more than welcome
On 8/14/23 00:10, Jin Ma wrote:
Additional links：
v10, the patch that needs to be reviewed again:
http://patchwork.ozlabs.org/project/gcc/patch/20230814055033.1995-1-ji...@linux.alibaba.com/
v9 and the previous review comments:
http://patchwork.ozlabs.org/project/gcc/patch/20230515131628.953-
Hi, Sid,
For the following testing case:
#include
#define noinline __attribute__((__noinline__))
static void noinline alloc_buf_more (int index)
{
struct annotated {
long foo;
char b;
char array[index];
long c;
} q, *p;
p = &q;
printf("the__bdos of p->array whole max
On 8/11/23 17:04, Jeff Law wrote:
I'm wondering (naively) if there is some way to tune this - for a
given backend. In general it would make sense to do the replacement,
but not if the cost changes (e.g. consts could be embedded in x86
insn freely, but not for RISC-V where this is costly and
Committed, thanks Kito.
Pan
From: Kito Cheng
Sent: Monday, August 14, 2023 11:02 PM
To: Li, Pan2
Cc: Wang, Yanzhang ; gcc-patches
; 钟居哲
Subject: Re: [PATCH v1] RISC-V: Support RVV VFREC7 rounding mode intrinsic API
Checked with doc and llvm implementation, LGTM
This is an update of:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626194.html
This version of patch set only introduces some small simplications of
implementation. Because I missed the size limitation of mail size, the
huge testsuite patches of v2 and v3 are not shown in the mail list. S
From: Lulu Cheng
gcc/ChangeLog:
* config/loongarch/genopts/loongarch-strings: Add compilation framework.
* config/loongarch/genopts/loongarch.opt.in: Ditto.
* config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins): Ditto.
* config/loongarch/loongarch-def.c:
From: Lulu Cheng
gcc/ChangeLog:
* config/loongarch/genopts/loongarch-strings: Add compilation framework.
* config/loongarch/genopts/loongarch.opt.in: Ditto.
* config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins): Ditto.
* config/loongarch/loongarch-def.c:
On Mon, Aug 14, 2023 at 01:22:32PM +0800, Xi Ruoyao wrote:
> On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote:
> > The configure script and the GCC driver are updated so that
> > it is easier to customize and control GCC builds for targeting
> > different LoongArch implementations.
> >
> > * Su
On Mon, Aug 14, 2023 at 03:48:53PM +0800, Xi Ruoyao wrote:
> On Mon, 2023-08-14 at 15:37 +0800, Yujie Yang wrote:
> > On Mon, Aug 14, 2023 at 01:38:40PM +0800, Xi Ruoyao wrote:
> > > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote:
> > >
> > > > However, for LoongArch, we do not want such a "t
I guess there is a merge conflict with Yujie's "-msimd=" patch and you
may need to collaborate to resolve it. Maybe just add -msimd in this
series.
On Tue, 2023-08-15 at 09:05 +0800, Chenghui Pan wrote:
> From: Lulu Cheng
>
> gcc/ChangeLog:
>
> * config/loongarch/genopts/loongarch-stri
On Tue, 1 Aug 2023 at 14:44, Robin Dapp wrote:
>
> Hi Joern,
>
> thanks, I believe this will help with testing.
>
> > +proc check_effective_target_riscv_v { } {
> > +return [check_no_compiler_messages riscv_ext_v assembly {
> > + #ifndef __riscv_v
> > + #error "Not __riscv_v"
> > +
On Mon, 2023-08-14 at 19:16 +0800, Xi Ruoyao wrote:
> On Mon, 2023-08-14 at 18:18 +0800, Yujie Yang wrote:
> > On Mon, Aug 14, 2023 at 03:48:53PM +0800, Xi Ruoyao wrote:
> > > On Mon, 2023-08-14 at 15:37 +0800, Yujie Yang wrote:
> > > > On Mon, Aug 14, 2023 at 01:38:40PM +0800, Xi Ruoyao wrote:
> >
Yes, there's some confliction inside -mlsx/-mlasx option impl because
this patch set is based on the older option framework, we will try to
resolve this problem later.
On Tue, 2023-08-15 at 09:18 +0800, Xi Ruoyao wrote:
> I guess there is a merge conflict with Yujie's "-msimd=" patch and
> you
> m
On Fri, 4 Aug 2023 at 21:52, Jeff Law wrote:
> > diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> > index b4884a30872..e61110fa3ad 100644
> > --- a/gcc/config/riscv/riscv-v.cc
> > +++ b/gcc/config/riscv/riscv-v.cc
> > @@ -49,6 +49,7 @@
> > #include "tm-constrs.h"
> > #
Ping. Seems no objection ?
Will commit it soon.
Thanks.
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-08-12 22:15
To: gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc; jeffreyalaw; Juzhe-Zhong
Subject: [PATCH] RISC-V: Fix autovec_length_operand predicate[PR110989]
Currently, autovec_lengt
Sorry, I should have built the patch while backporting.
I'll backport another patch to fix the problems after finishing bootstraps,
probably in couple hours.
Thank you!
Lili.
> -Original Message-
> From: Tobias Burnus
> Sent: Monday, August 14, 2023 5:34 PM
> To: gcc-patches@gcc.gnu.org
Sorry, I should have built the patch while backporting, and thanks for your
report and suggestions.
I'll backport another patch to fix the problems after finishing bootstraps,
probably in couple hours.
Thank you!
Lili.
> -Original Message-
> From: Jonathan Wakely
> Sent: Monday, August
Committed as passed both the bootstrap and regression test in x86, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Tuesday, August 15, 2023 1:21 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang, Yanzhang
Subject: Re: [PATCH v4] M
> I came up with another idea. What if we:
>
> 1. Keep the "default" ABI libs in the toplevel directory. There is
> *always* a default ABI so treating it specially is not really nonsense.
> 2. Create a symlink for consistency. For example, if --with-abi=lp64d, -
> -with-multilib-list=lp64d,lp64s:
on 2023/8/14 22:16, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2023/8/14 20:20, Richard Sandiford wrote:
>>> Thanks for the clean-ups. But...
>>>
>>> "Kewen.Lin" writes:
Hi,
Following Richi's suggestion [1], this patch is to move the
handlings on V
From: Pan Li
This patch would like to support the rounding mode API for the
VFCVT.X.F.V as the below samples.
* __riscv_vfcvt_x_f_v_i32m1_rm
* __riscv_vfcvt_x_f_v_i32m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(class vfcvt_x_frm)
For conversion API, I would prefer kito review since I am not sure about this
stuff.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-15 10:55
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFCVT.X.F.V rounding mode intrinsic API
Fr
Hi,
Commit r14-3093 introduced a random build failure on
build/gencondmd.cc building. Since r14-3093 makes recog.h
include tree.h, which further includes (depends on) some
files that are generated during the building, such as:
all-tree.def, tree-check.h etc, when building file
build/gencondmd.cc,
> Date: Mon, 14 Aug 2023 16:47:40 +0800
> From: "Kewen.Lin via Gcc-patches"
> on 2023/8/14 15:53, Jan-Benedict Glaw wrote:
> > echo timestamp > s-constrs-h
> > /var/lib/laminar/run/gcc-local/82/local-toolchain-install/bin/g++
> > -std=c++11 -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti
>
On 2023/08/14 21:51, Jin Ma wrote:
> Hi Tsukasa,
> What a coincidence, I also implemented zfa extension, which also includes
> fli related instructions :)
Hi, I'm glad to know that someone is working on this extension more
comprehensively (especially when "someone" is an experienced GCC
contrib
On 8/12/23 10:44, Jivan Hakobyan wrote:
Yes, as mentioned Jeff I have some work in that scope.
The first is related to address computation when it has a large constant
part.
Suppose we have this code:
int consume (void *);
int foo (void) {
int x[1000];
return con
On 8/14/23 18:35, Vineet Gupta wrote:
On 8/11/23 17:04, Jeff Law wrote:
I'm wondering (naively) if there is some way to tune this - for a
given backend. In general it would make sense to do the replacement,
but not if the cost changes (e.g. consts could be embedded in x86
insn freely, bu
I'll commit this in a few hours pending testing. It seems
trivial enough to be posted before testing is finished
though, now that it has passed the previous
point-of-breakage. JFTR, I'm testing against the version
with the "first" breaking commit: r14-3092, not r14-3093 the
one with recog.h.
--
From: Pan Li
This patch would like to support the rounding mode API for the
VFCVT.XU.F.V as the below samples.
* __riscv_vfcvt_xu_f_v_u32m1_rm
* __riscv_vfcvt_xu_f_v_u32m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(vfcvt_xu_frm_ob
Anyone?
On Sun, Aug 13, 2023 at 4:48 PM Julian Waters
wrote:
> Please review a patch to add clang's invalid-noreturn flag to toggle
> noreturn warnings. This patch keeps the old behaviour of always warning on
> every noreturn violation, but unlike clang also adds an extra layer of fine
> tuning
> From: Hans-Peter Nilsson
> Date: Tue, 15 Aug 2023 06:57:04 +0200
Whoops, of course there was a typo due to
insufficient-last-minute-renaming syndrome. :)
> -#define TARGET_LEGITIMATE_ADDRESS_P cris_legitimate_address_p
> +#define TARGET_LEGITIMATE_ADDRESS_P cris_target_legitimate_address_p
*c
Re-testing as previously mentioned, reposted freshly for reference.
-- >8 --
While there's another patch that fixes the immediate error
in the PR by other means, the include of tree.h here is
something I prefer to avoid.
PR bootstrap/111021
* config/cris/cris-protos.h: Revert recen
On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
> There's no practical (programmatic) way to do such validation; it has to be a
> manual audit, which is why source code passed to the compiler has to be
> *trusted*.
No, I do not think that is a logical conclusion. What is the problem with
passing
Hi Stefan,
on 2023/8/15 02:51, Stefan Schulze Frielinghaus wrote:
> Hi everyone,
>
> I have bootstrapped and regtested the patch below on s390. For the
> 64-bit target I do not see any changes regarding the testsuite. For the
> 31-bit target I see the following failures:
>
> FAIL: gcc.dg/vect/
On Mon, Aug 14, 2023 at 4:46 AM liuhongt via Gcc-patches
wrote:
>
> vmovapd can enable register renaming and have same code size as
> vmovsd. Similar for vmovsh vs vmovaps, vmovaps is 1 byte less than
> vmovsh.
>
> When TARGET_AVX512VL is not available, still generate
> vmovsd/vmovss/vmovsh to avo
From: Pan Li
This patch would like to support the rounding mode API for the
VFCVT.F.X.V and VFCVT.F.XU.V as the below samples.
* __riscv_vfcvt_f_x_v_f32m1_rm
* __riscv_vfcvt_f_x_v_f32m1_rm_m
* __riscv_vfcvt_f_xu_v_f32m1_rm
* __riscv_vfcvt_f_xu_v_f32m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
On Tue, 15 Aug 2023, Kewen.Lin wrote:
> Hi Stefan,
>
> on 2023/8/15 02:51, Stefan Schulze Frielinghaus wrote:
> > Hi everyone,
> >
> > I have bootstrapped and regtested the patch below on s390. For the
> > 64-bit target I do not see any changes regarding the testsuite. For the
> > 31-bit targe
101 - 138 of 138 matches
Mail list logo
