[Gah. In my head I'd sent this a few weeks ago, but it turns out
that I hadn't even got to the stage of writing the changlog...]
LRA keeps track of the biggest mode for both hard registers and
pseudos. The updates assume that the modes are ordered, i.e. that
we can tell whether one is no bigger
On 03/12/2023 04:03, Xi Ruoyao wrote:
> On Sun, 2023-12-03 at 00:17 +, Jonny Grant wrote:
>> @@ -733,7 +733,7 @@ To configure GCC:
>> @smallexample
>> % mkdir @var{objdir}
>> % cd @var{objdir}
>> -% @var{srcdir}/configure [@var{options}] [@var{target}]
>> +% ../@var{srcdir}/configure [@va
Hi!
On 2023-12-03T08:41:59+0100, Florian Weimer wrote:
> * Jeff Law:
>
>> Anyway, this test was the one I was most concerned about. Basically
>> we're testing that on a !dfp target that the builtins are not available.
>> It expects a warning, but gets an error by default now. I just
>> change
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The TYPE_DECL_SUPPRESS_DEBUG and DECL_EXTERNAL flags use the same
underlying bit. This is causing confusion when attempting to determine
the interface for a streamed-in class type, since the modules code
currently assumes t
Saurabh Jha writes:
> On 12/1/2023 2:10 PM, Richard Earnshaw (lists) wrote:
>> On 01/12/2023 13:45, Christophe Lyon wrote:
>>> On Fri, 1 Dec 2023 at 13:44, Richard Earnshaw (lists)
>>> wrote:
On 01/12/2023 11:28, Saurabh Jha wrote:
> Hey,
>
> I introduced this test "gcc/testsuite
On Sun, 2023-12-03 at 11:59 +, Jonny Grant wrote:
>
>
> On 03/12/2023 04:03, Xi Ruoyao wrote:
> > On Sun, 2023-12-03 at 00:17 +, Jonny Grant wrote:
> > > @@ -733,7 +733,7 @@ To configure GCC:
> > > @smallexample
> > > % mkdir @var{objdir}
> > > % cd @var{objdir}
> > > -% @var{srcdir}/c
On Fri, Nov 17, 2023 at 02:04:01PM +0100, Robin Dapp wrote:
> > Yes, your version is also OK.
>
> The attached was bootstrapped and regtested on aarch64, x86 and
> regtested on riscv. Going to commit it later unless somebody objects.
Unfortunately the aarch64/pr112406.c was reduced too much and
Hi!
I've noticed this test regressed on s390x-linux with the addition of the
switch to modern C patchset. Haven't tried to reproduce the ICE, but as it
was a backend ICE and FE after warning used to add such casts before (now
errors), I think this ought to keep the testcase testing what was inten
> Am 03.12.2023 um 19:32 schrieb Jakub Jelinek :
>
> On Fri, Nov 17, 2023 at 02:04:01PM +0100, Robin Dapp wrote:
>>> Yes, your version is also OK.
>>
>> The attached was bootstrapped and regtested on aarch64, x86 and
>> regtested on riscv. Going to commit it later unless somebody objects.
>
On 12/3/23 05:23, Thomas Schwinge wrote:
Hi!
On 2023-12-03T08:41:59+0100, Florian Weimer wrote:
* Jeff Law:
Anyway, this test was the one I was most concerned about. Basically
we're testing that on a !dfp target that the builtins are not available.
It expects a warning, but gets an er
Committed as it is obvious fix.
gcc/ChangeLog:
* config/riscv/riscv.md: Rostify the constraints.
---
gcc/config/riscv/riscv.md | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 4c6f63677df
The recent change to represent language and target attribute tables using
vec.h's array_slice template class triggers an issue/bug in older g++
compilers, specifically the g++ 4.8.5 system compiler of older RedHat
distributions. This exhibits as the following compilation errors during
bootstrap:
Hi Ajit,
on 2023/12/1 17:10, Ajit Agarwal wrote:
> Hello Kewen:
>
> On 24/11/23 3:01 pm, Kewen.Lin wrote:
>> Hi Ajit,
>>
>> Don't forget to CC David (CC-ed) :), some comments are inlined below.
>>
>> on 2023/10/8 03:04, Ajit Agarwal wrote:
>>> Hello All:
>>>
>>> This patch add new pass to replace
LGTM
On Sun, Dec 3, 2023 at 5:16 AM Christoph Müllner <
christoph.muell...@vrull.eu> wrote:
> This patch documents the optimization parameter
> riscv-strcmp-inline-limit, which can be used to tweak the behaviour
> of -minline-strcmp and -minline-strncmp.
>
> gcc/ChangeLog:
>
> PR target/1
On Sat, Dec 2, 2023 at 3:04 AM Richard Sandiford
wrote:
>
> Jakub Jelinek writes:
> > Hi!
> >
> > The following testcase ICEs on x86_64-linux since df_note_add_problem ()
> > call has been added to mode switching.
> > The problem is that the pro_and_epilogue pass in
> > prepare_shrink_wrap -> cop
This patch add the intrinsic functions(according to https://github.com/
riscv-non-isa/rvv-intrinsic-doc/blob/eopc/vector-crypto/auto-generated/
vector-crypto/intrinsic_funcs.md) for crypto vector Zvbc extension. And all
the test cases are added for api-testing.
Co-Authored by: Songhe Zhu
gcc/Cha
This patch add the intrinsic functions(according to https://github.com/
riscv-non-isa/rvv-intrinsic-doc/blob/eopc/vector-crypto/auto-generated/
vector-crypto/intrinsic_funcs.md) for crypto vector Zvkg extension. And all
the test cases are added for api-testing.
Co-Authored by: Songhe Zhu
Co-Autho
This patch add the intrinsic functions(according to https://github.com/
riscv-non-isa/rvv-intrinsic-doc/blob/eopc/vector-crypto/auto-generated/
vector-crypto/intrinsic_funcs.md) for crypto vector Zvkned extension. And all
the test cases are added for api-testing.
gcc/ChangeLog:
* common/c
This patch add the intrinsic functions(according to https://github.com/
riscv-non-isa/rvv-intrinsic-doc/blob/eopc/vector-crypto/auto-generated/
vector-crypto/intrinsic_funcs.md) for crypto vector Zvksed extension. And all
the test cases are added for api-testing.
gcc/ChangeLog:
* common/c
This patch add the intrinsic functions(according to https://github.com/
riscv-non-isa/rvv-intrinsic-doc/blob/eopc/vector-crypto/auto-generated/
vector-crypto/intrinsic_funcs.md) for crypto vector Zvknh[ab] extension. And all
the test cases are added for api-testing.
Co-Authored by: Songhe Zhu
gc
This patch add the intrinsic functions(according to https://github.com/
riscv-non-isa/rvv-intrinsic-doc/blob/eopc/vector-crypto/auto-generated/
vector-crypto/intrinsic_funcs.md) for crypto vector Zvksh extension. And all
the test cases are added for api-testing.
Co-Authored by: Songhe Zhu
gcc/Ch
Hi, eswin.
Thanks for contributing vector crypto support.
It seems patches mess up. Could you rebase your patch to the trunk GCC cleanly
and send it again.
The patches look odd to me, for example:
// ZVBB
-DEF_VECTOR_CRYPTO_FUNCTION (vandn, zvbb, full_preds, u_vvv_ops, zvkb_or_zvbb)
-DEF_VECT
Wait, I got this on my machine?
../../../../riscv-gnu-toolchain-trunk/gcc/gcc/doc/invoke.texi:29774: misplaced }
../../../../riscv-gnu-toolchain-trunk/gcc/gcc/doc/invoke.texi:29786: misplaced }
On Mon, Dec 4, 2023 at 10:43 AM Kito Cheng wrote:
>
> LGTM
>
> On Sun, Dec 3, 2023 at 5:16 AM Christo
On 12/1/23 17:42, Patrick Palka wrote:
On Fri, 1 Dec 2023, Jason Merrill wrote:
On 12/1/23 12:32, Patrick Palka wrote:
On Tue, 14 Nov 2023, Jason Merrill wrote:
On 11/14/23 11:10, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
On 12/2/23 05:51, Jakub Jelinek wrote:
Hi!
foo in the unroll-5.C testcase ICEs because cp_parser_pragma_unroll
during parsing calls maybe_constant_value unconditionally, which is
fine if !processing_template_decl, but can ICE otherwise.
While just calling fold_non_dependent_expr there instead c
In serious high register pressure case (appended in this patch):
We see vluxei8.v v0,(s1),v1,v0.t which is not allowed.
Since according to RVV ISA:
+;; The destination vector register group for a masked vector instruction
cannot overlap the source mask register (v0),
+;; unless the destina
.i.e. for below cases.
a[0] = b1;
a[1] = b2;
..
a[n] = bn;
There're extra dependences when contructing the vector, but not for
scalar store. According to experiments, it's generally worse.
The patch adds an cut-off heuristic when vec_stmt is just
vec_construct and vector store. It imp
2023-12-04 11:37 juzhe.zhong wrote:
Will split again as you mentioned. Thanks.
Feng Wang
>Hi, eswin.
>
>Thanks for contributing vector crypto support.
>
>It seems patches mess up. Could you rebase your patch to the trunk GCC cleanly
>and send it again.
>
>The patches look odd
Extract the logic of checking conflict extensions to a standard alone
function, prepare to add more checking logic.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::check_conflict_ext): New.
(riscv_subset_list::parse): Move checking conflict ext. to
RISC-V ISA implication rules become little bit complicated than before,
it may come with condition, so this commit extend the capability of
riscv_implied_info_t, also make it more...C++ize.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_implied_predicator_t): New.
(ri
x280 is one of SiFive core, and it release for a while, also
upstream LLVM already support that.
[1] https://www.sifive.com/cores/intelligence-x280
gcc/ChangeLog:
* config/riscv/riscv-cores.def: Add sifive-x280.
* doc/invoke.texi (RISC-V Options): Add sifive-x280
gcc/testsuite/C
Rebase and resend this patch due to it was not added into patchwork
before. Kito had already reviewed it. Please refer to
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg327499.html
This patch add the Zvkb subset of crypto vector extension. The
corresponding test cases have aslo been modif
Committed. Thanks Kito and Jeff.
BR
Fei
On 2023-11-28 13:03 Jeff Law wrote:
>
>
>
>On 11/27/23 20:09, Kito Cheng wrote:
>> Personally I don't like to play with the pattern order to tweak the
>> code gen since it kinda introduces implicit relation/rule here, but I
>> guess the only way to preve
LGTM again :)
On Mon, Dec 4, 2023 at 2:44 PM Feng Wang wrote:
>
> Rebase and resend this patch due to it was not added into patchwork
> before. Kito had already reviewed it. Please refer to
> https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg327499.html
>
> This patch add the Zvkb subset of
Like r14-5990-gb4a7c1c8c59d19, but the patch optimized for udot_prod.
Since (zero_extend) (unsigned char)-> int is equal
to (zero_extend)(unsigned char) -> short
+ (sign_extend) (short) -> int
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
It should be safe to emu
On Fri, Dec 1, 2023 at 10:26 PM Richard Biener
wrote:
>
> On Fri, Dec 1, 2023 at 3:39 AM liuhongt wrote:
> >
> > > Hmm, I would suggest you put reg_needed into the class and accumulate
> > > over all vec_construct, with your patch you pessimize a single v32qi
> > > over two separate v16qi for exa
Committed! Thanks Kito.
BR,
Fei
On 2023-12-04 15:01 Kito Cheng wrote:
>
>LGTM again :)
>
>On Mon, Dec 4, 2023 at 2:44 PM Feng Wang wrote:
>>
>> Rebase and resend this patch due to it was not added into patchwork
>> before. Kito had already reviewed it. Please refer to
>> https://www.mail-arch
Hi!
The following testcase ICEs, because the signbit2 expander uses an
explicit SUBREG in the pattern around match_operand with register_operand
predicate. If we are unlucky enough that expansion tries to expand it
with some SUBREG as operands[1], we have two nested SUBREGs in the IL,
which is no
On Fri, Dec 01, 2023 at 10:43:57AM -0700, Sandra Loosemore wrote:
> On 12/1/23 10:33, Jakub Jelinek wrote:
> > Shall we tweak that somehow? If the argument names are unimportant, perhaps
> > it is fine to leave that out, but shouldn't we always use @var{...} around
> > the parameter names when spe
Hi!
The following testcase ICEs with RTL checking, because it sets if
XINT (SET_SRC (set), 1) is UNSPEC_SET_GOT without checking if SET_SRC (set)
is actually an UNSPEC, so any time we see any other insn with PARALLEL
and a SET in it which is not an UNSPEC we ICE during RTL checking or
access there
RISC-V newlib patch send, one for libgloss and another one for libm,
the libm issue is because we don't have right long double support,
however newlib has supported that few months ago, and porting effort
is minor, so I just port that to fix the issue :)
https://sourceware.org/pipermail/newlib/202
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::check_conflict_ext): Check zcd conflicts
with zcmt and zcmp.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-29.c: New test.
* gcc.target/riscv/arch-30.c: New test.
---
gcc/common/c
On Mon, Dec 4, 2023 at 8:35 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs, because the signbit2 expander uses an
> explicit SUBREG in the pattern around match_operand with register_operand
> predicate. If we are unlucky enough that expansion tries to expand it
> with some SUBREG
On Mon, Dec 4, 2023 at 8:41 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs with RTL checking, because it sets if
> XINT (SET_SRC (set), 1) is UNSPEC_SET_GOT without checking if SET_SRC (set)
> is actually an UNSPEC, so any time we see any other insn with PARALLEL
> and a SET in it
On Mon, Dec 4, 2023 at 8:11 AM Hongtao Liu wrote:
>
> On Fri, Dec 1, 2023 at 10:26 PM Richard Biener
> wrote:
> >
> > On Fri, Dec 1, 2023 at 3:39 AM liuhongt wrote:
> > >
> > > > Hmm, I would suggest you put reg_needed into the class and accumulate
> > > > over all vec_construct, with your patch
45 matches
Mail list logo
