On Tue, 11 Apr 2023, Richard Sandiford wrote:
> "juzhe.zh...@rivai.ai" writes:
> > Hi, Richards.
> > Kindly Ping this patch.
> > This is the most important patch for RVV auto-vectorization support.
> > Bootstraped on X86 has passed.
>
> Can it wait for GCC 14? It doesn't seem like stage 4 mat
On 4/11/23 11:23, Richard Biener wrote:
> On Thu, Apr 6, 2023 at 3:58 PM Martin Liška wrote:
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed after stage1 opens?
>
> Did we release a compiler with version 1? If not we might want to sneak
Y
On Tue, 11 Apr 2023, Kito Cheng wrote:
> Let me give more explanation why RISC-V vector need so many modes than
> AArch64.
>
> The following will use "RVV" as an abbreviation for "RISC-V Vector"
> instructions.
>
> There are two key points here:
>
> - RVV has a concept called LMUL - you can un
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
https://translationproject.org/POT-files/gcc
Thank you very much for reply.
WHILE_LEN is the pattern that calculates the number of the elements of the
vector will be updated in each iteration.
For RVV, we use vsetvl instruction to calculate the number of the elements of
the vector.
WHILE_ULT can not work for RVV since WHILE_ULT is generat
On Tue, Apr 11, 2023 at 07:52:29PM -0400, Andrew MacLeod wrote:
> This bootstraps on x86_64-pc-linux-gnu with that single regression, which I
> have XFAILed for now. OK for trunk?
Yes.
> Once Jakub verifies it actually fixes
> the execution problem. we have no executable test . yet.
I have
On Wed, 12 Apr 2023, juzhe.zh...@rivai.ai wrote:
> Thank you very much for reply.
>
> WHILE_LEN is the pattern that calculates the number of the elements of the
> vector will be updated in each iteration.
> For RVV, we use vsetvl instruction to calculate the number of the elements of
> the vect
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 French team of translators. The file is available at:
https://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-13.1-b20230409.fr.po',
Prathamesh Kulkarni writes:
> On Thu, 6 Apr 2023 at 16:05, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> > On Tue, 4 Apr 2023 at 23:35, Richard Sandiford
>> > wrote:
>> >> > diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
>> >> > b/gcc/config/aarch64/aarch64-sve-
Hi Richard:
> > In order to model LMUL in backend, we have to the combination of
> > scalar type and LMUL; possible LMUL is 1, 2, 4, 8, 1/2, 1/4, 1/8 - 8
> > different types of LMUL, and we'll have QI, HI, SI, DI, HF, SF and DF,
> > so basically we'll have 7 (LMUL type) * 7 (scalar type) here.
>
>
On Wed, Apr 12, 2023 at 1:52 AM Andrew MacLeod wrote:
>
> This is a carry over from PR 108139.
>
> When we have a PHI node which has 2 arguments and one is undefined, we
> create an equivalence between the LHS and the non-undefined PHI
> argument. THis allows us to perform certain optimizations.
>> Thanks for the detailed explanation. Just to clarify - with RVV
>> there's only a single mask register, v0.t, or did you want to
>> say an instruction can only specify a single mask register?
RVV has 32 (v0~v31) vector register in total.
We can store vector data value or mask value in any of
Sorry for incorrect typo.We can predicate vadd.vv with v1 - v31.
>
We can't predicate vadd.vv with v1 - v31.
juzhe.zh...@rivai.ai
From: juzhe.zh...@rivai.ai
Date: 2023-04-12 17:15
To: rguenther
CC: richard.sandiford; gcc-patches; jeffreyalaw
Subject: Re: Re: [PATCH] VECT: Add WHILE_LEN patt
On Wed, 12 Apr 2023, Kito Cheng wrote:
> Hi Richard:
>
> > > In order to model LMUL in backend, we have to the combination of
> > > scalar type and LMUL; possible LMUL is 1, 2, 4, 8, 1/2, 1/4, 1/8 - 8
> > > different types of LMUL, and we'll have QI, HI, SI, DI, HF, SF and DF,
> > > so basically
On Wed, 12 Apr 2023, juzhe.zh...@rivai.ai wrote:
>
> >> Thanks for the detailed explanation. Just to clarify - with RVV
> >> there's only a single mask register, v0.t, or did you want to
> >> say an instruction can only specify a single mask register?
>
> RVV has 32 (v0~v31) vector register in
> > The concept of fractional LMUL is the same as the concept of AArch64's
> > partial SVE vectors,
> > so they can only access the lowest part, like SVE's partial vector.
> >
> > We want to spill/restore the exact size of those modes (1/2, 1/4,
> > 1/8), so adding dedicated modes for those partial
>> I think we can CC IBM folks to see whether we can make WHILE_LEN works
>> for both IBM and RVV ?
>
> I've CCed them. Adding WHILE_LEN support to rs6000/s390x would be
> mainly the "easy" way to get len-masked (epilog) loop support. I've
> figured actually implementing WHILE_ULT for AVX512 in
Hi!
On Wed, Apr 12, 2023 at 08:21:26AM +0200, Jakub Jelinek via Gcc-patches wrote:
> I would have expected something like
> WORD_REGISTER_OPERATIONS && known_le (GET_MODE_PRECISION (mode),
> BITS_PER_WORD)
> as the condition to use word_mode, rather than just
> WORD_REGISTER_OPERATIONS. In both
The following makes sure to carry out the reduction epilog adjustment
in the original computation type which for pointers is an unsigned
integer type. There's a similar issue with signed vs. unsigned ops
and overflow which is fixed by this as well.
Bootstrapped and tested on x86_64-unknown-linux-
On Tue, Apr 11, 2023 at 04:58:19PM -0400, Andrew MacLeod wrote:
> This bootstraps and has no regressions, and is fine by me if you want to use
> it.
Thanks, looks nice.
My incremental patch on top of that would then be below.
Though,
FAIL: gcc.dg/tree-ssa/vrp-float-6.c scan-tree-dump-times evrp "
On Wed, Apr 12, 2023 at 11:12:17AM +0200, Richard Biener wrote:
> > 108139 fixed this by not evaluating any equivalences if the equivalence
> > was the LHS.
> >
> > What it missed, was it possible we are calculating the range of a_3.
> > b_2 is not defined in a phi node, so it happily used the equi
On Wed, Apr 12, 2023 at 12:59 PM Jakub Jelinek wrote:
>
> On Wed, Apr 12, 2023 at 11:12:17AM +0200, Richard Biener wrote:
> > > 108139 fixed this by not evaluating any equivalences if the equivalence
> > > was the LHS.
> > >
> > > What it missed, was it possible we are calculating the range of a_3
From: Ju-Zhe Zhong
Fix supporting data type according to RVV ISA.
For vint64m*_t, we should only allow them in zve64* instead of zve32*_zvl64b
(>=64b).
Ideally, we should make error message more friendly like Clang.
https://godbolt.org/z/f9GMv4dMo to report the RVV type require extenstion name.
Richard Biener writes:
> On Wed, 12 Apr 2023, juzhe.zh...@rivai.ai wrote:
>
>>
>> >> Thanks for the detailed explanation. Just to clarify - with RVV
>> >> there's only a single mask register, v0.t, or did you want to
>> >> say an instruction can only specify a single mask register?
>>
>> RVV ha
Thank you. Richard.
>> I think that already works for them (could be misremembering).
>> However, IIUC, they have no special instruction to calculate the
>> length (unlike for RVV), and so it's open-coded using vect_get_len.
Yeah, the current flow using min, sub, and then min in vect_get_len
is
On Wed, Apr 12, 2023 at 1:18 PM Richard Sandiford via Gcc-patches
wrote:
>
> Richard Biener writes:
> > On Wed, 12 Apr 2023, juzhe.zh...@rivai.ai wrote:
> >
> >>
> >> >> Thanks for the detailed explanation. Just to clarify - with RVV
> >> >> there's only a single mask register, v0.t, or did you
We'd been generating really bad block move sequences which is recently
complained by kernel developers who tried __builtin_memcpy. To improve
it:
1. Take the advantage of -mno-strict-align. When it is set, set mode
size to UNITS_PER_WORD regardless of the alignment.
2. Half the mode size when
"juzhe.zh...@rivai.ai" writes:
>>> I think that already works for them (could be misremembering).
>>> However, IIUC, they have no special instruction to calculate the
>>> length (unlike for RVV), and so it's open-coded using vect_get_len.
>
> Yeah, the current flow using min, sub, and then min in
Tested x86_64-linux and sparc-solaris2.11. Pushed to trunk.
-- >8 --
Import the new 2023c tzdata.zi file.
libstdc++-v3/ChangeLog:
* src/c++20/tzdata.zi: Import new file from 2023c release.
---
libstdc++-v3/src/c++20/tzdata.zi | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
Tested x86_64-linux and sparc-solaris2.11. Pushed to trunk.
-- >8 --
On Solaris the in_addr struct contains a union and value-initializing it
does not make the s_addr member active. This means we can't access that
member later during constant evaluation.
Make the constructors explicitly set ever
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 error message for
>>> requirements
OK for trunk, but plz improve the coverage of the testcase, e.g.
vint16mf4_t has fixed too but not tested in testcase.
On Wed, Apr 12, 2023 at 7:09 PM wrote:
>
> From: Ju-Zhe Zhong
>
> Fix supporting data type according to RVV ISA.
> For vint64m*_t, we should only allow them in zve64* instead of
Hi!
on 2023/4/12 19:37, juzhe.zh...@rivai.ai wrote:
> Thank you. Richard. >> I think that already works for them (could be
> misremembering). >> However, IIUC, they have no special instruction to
> calculate the >> length (unlike for RVV), and so it's open-coded using
> vect_get_len.
>
> Than
On 4/12/23 04:20, Jakub Jelinek wrote:
On Tue, Apr 11, 2023 at 07:52:29PM -0400, Andrew MacLeod wrote:
This bootstraps on x86_64-pc-linux-gnu with that single regression, which I
have XFAILed for now. OK for trunk?
Yes.
Once Jakub verifies it actually fixes
the execution problem. we
From: yulong
This patch fix a redefinition bug.
There are have a definition about mode_t in the fd-4.c, but it duplicates the
definition in types.h that be included by stdio.h.
Thanks to Jeff Law for reviewing the previous version.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/fd-4.c: del
Thanks Kewen.
It seems that this proposal WHILE_LEN can help s390 when using --param
vect-partial-vector-usage=2 compile option.
Would you mind apply this patch && support WHILE_LEN in s390 backend and test
it to see the overal benefits for s390
as well as the correctness of this sequence ?
I
On 4/12/23 00:21, Jakub Jelinek wrote:
On Tue, Apr 11, 2023 at 07:26:07PM -0600, Jeff Law wrote:
I did bootstrap on riscv, but not a regression test, that's spinning right
now.
Jeff
diff --git a/gcc/combine.cc b/gcc/combine.cc
index 22bf8e1ec89..c41d8a09b3b 100644
--- a/gcc/combine.cc
+++
This is proposed to fix PR109460 where an older version of
gcc (7.3) was used to build for windows (mingw) host.
From e5b608072f80a83cca65e88bb75ecc62ab0bbb87 Mon Sep 17 00:00:00 2001
From: Costas Argyris
Date: Wed, 12 Apr 2023 08:48:18 +0100
Subject: [PATCH] mingw: Support building with older gcc
This makes floating_from_chars.cc explicitly include all headers
that are used by the original fast_float amalgamation according to
r12-6647-gf5c8b82512f9d3, except:
1. since fast_float doesn't seem to use anything from it
2. since fast_float doesn't seem to use anything directly
from i
From: Ju-Zhe Zhong
Fix supporting data type according to RVV ISA.
For vint64m*_t, we should only allow them in zve64* instead of zve32*_zvl64b
(>=64b).
Ideally, we should make error message more friendly like Clang.
https://godbolt.org/z/f9GMv4dMo to report the RVV type require extenstion name.
On 4/12/23 04:02, Jakub Jelinek wrote:
Hi!
On Wed, Apr 12, 2023 at 08:21:26AM +0200, Jakub Jelinek via Gcc-patches wrote:
I would have expected something like
WORD_REGISTER_OPERATIONS && known_le (GET_MODE_PRECISION (mode), BITS_PER_WORD)
as the condition to use word_mode, rather than just
W
>> It's not so much that we need to do that. But normally it's only worth
>> adding internal functions if they do something that is too complicated
>> to express in simple gimple arithmetic. The UQDEC case I mentioned:
>>z = MAX (x, y) - y
>> fell into the "simple arithmetic" category for m
On Wed, Apr 12, 2023 at 12:33:39PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Apr 11, 2023 at 04:58:19PM -0400, Andrew MacLeod wrote:
> > This bootstraps and has no regressions, and is fine by me if you want to use
> > it.
>
> Thanks, looks nice.
> My incremental patch on top of that wo
Hi!
On the following testcase, we emit weird diagnostics.
User used the z modifier, but diagnostics talks about Z instead.
This is because z is implemented by doing some stuff and then falling
through into the Z case.
The following patch adjusts the Z diagnostics, such that it prints whatever
mod
On Wed, Apr 12, 2023 at 08:17:46AM -0600, Jeff Law wrote:
> Looks pretty sensible. It'll take most of the day, but I'll do a bootstrap
> and regression test with this variant.
Thanks. Note, it bootstraps/regtests on x86_64-linux and i686-linux fine,
though that is not WORD_REGISTER_OPERATIONS ta
On Wed, Apr 12, 2023 at 4:28 PM Jakub Jelinek wrote:
>
> Hi!
>
> On the following testcase, we emit weird diagnostics.
> User used the z modifier, but diagnostics talks about Z instead.
> This is because z is implemented by doing some stuff and then falling
> through into the Z case.
>
> The follo
Hi!
The following testcase ICEs in reassoc, unlike the last case I've fixed
there here SSA_NAME_USED_IN_ABNORMAL_PHI is not the case anywhere.
build_and_add_sum places new statements after the later appearing definition
of an operand but if both operands are default defs or constants, we place
sta
On 4/12/23 13:39, Costas Argyris wrote:
This is proposed to fix PR109460 where an older version of
gcc (7.3) was used to build for windows (mingw) host.
Thanks, accepted and pushed to master branch.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR libstdc++/108291
libstdc++-v3/ChangeLog:
* include/std/ranges (chunk_by_view::_M_find_next): Generalize
parameter types of the predicate passed to adjacent_find.
(chunk_by_view::_M_find_prev): Likewise
On Wed, Apr 12, 2023 at 01:31:46PM +0800, Jiufu Guo wrote:
> I understand that QP insns (e.g. xscmpexpqp) is valid if the system
> meets ISA3.0, no matter BE/LE, 32-bit/64-bit.
> I think option -mfloat128-hardware is designed for QP insns.
>
> While there is one issue, on BE machine, when compilin
> Am 12.04.2023 um 16:37 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> The following testcase ICEs in reassoc, unlike the last case I've fixed
> there here SSA_NAME_USED_IN_ABNORMAL_PHI is not the case anywhere.
> build_and_add_sum places new statements after the later appearing defi
Ping for patch 105325. I believe patch V3 answers the objections raised
earlier. Can I check this patch into master? Then can I apply this patch to
GCC 12 and 11 after appropriate delays?
| Date: Mon, 27 Mar 2023 23:19:55 -0400
| Subject: [PATCH, V3] PR target/105325, Make load/cmp fusion know
On Wed, 12 Apr 2023 at 14:45, Patrick Palka via Libstdc++
wrote:
>
> This makes floating_from_chars.cc explicitly include all headers
> that are used by the original fast_float amalgamation according to
> r12-6647-gf5c8b82512f9d3, except:
>
> 1. since fast_float doesn't seem to use anything fro
On Wed, 12 Apr 2023 at 15:41, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
>
> PR libstdc++/108291
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (chunk_by_view::_M_find_next): Generalize
> parameter
Thanks for the quick response! verified and pushed to trunk.
On Wed, Apr 12, 2023 at 9:56 PM wrote:
>
> From: Ju-Zhe Zhong
>
> Fix supporting data type according to RVV ISA.
> For vint64m*_t, we should only allow them in zve64* instead of zve32*_zvl64b
> (>=64b).
> Ideally, we should make error
Thank you for the feedback Richard and Richard.
> Note the calls are guarded with
>
> && ! known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U)
Yes, I believe nelt.is_constant() wouldn't be necessary. I didn't realize
the call was guarded by this condition.
> But I think the better check for loca
Hi All,
I think that the changelog says it all. OK for mainline?
Paul
Fortran: Fix some deferred character problems in associate [PR109451]
2023-04-07 Paul Thomas
gcc/fortran
PR fortran/109451
* trans-array.cc (gfc_conv_expr_descriptor): Guard expression
character length backend decl before
On Wed, Apr 12, 2023 at 12:02:12PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 12, 2023 at 08:21:26AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > I would have expected something like
> > WORD_REGISTER_OPERATIONS && known_le (GET_MODE_PRECISION (mode),
> > BITS_PER_WORD)
> > as the condition to u
On 12 April 2023 16:21:24 CEST, Jakub Jelinek via Gcc-patches
wrote:
>--- gcc/range-op-float.cc.jj 2023-04-12 12:17:44.784962757 +0200
>+++ gcc/range-op-float.cc 2023-04-12 16:07:54.948759355 +0200
>@@ -835,10 +835,17 @@ public:
> bool fold_range (irange &r, tree type,
>
On Wed, Apr 12, 2023 at 06:35:29PM +0200, Bernhard Reutner-Fischer wrote:
> >+relation_kind ret = le_op1_op2_relation (lhs);
> >+if (ret == VREL_GT
> >+&& (op1.known_isnan ()
> >+|| op1.maybe_isnan ()
> >+|| op2.known_isnan ()
> >+|| op2.maybe_isnan ()))
> >+
On Wed, Apr 12, 2023 at 12:02:12PM +0200, Jakub Jelinek via Gcc-patches wrote:
> I've tried the pr108947.c testcase, but I see no differences in the assembly
> before/after the patch (but dunno if I'm using the right options).
> The pr109040.c testcase from the patch I don't see the expected zero
>
On Wed, Apr 12, 2023 at 11:04 AM Jonathan Wakely wrote:
>
> On Wed, 12 Apr 2023 at 14:45, Patrick Palka via Libstdc++
> wrote:
> >
> > This makes floating_from_chars.cc explicitly include all headers
> > that are used by the original fast_float amalgamation according to
> > r12-6647-gf5c8b82512f9
On Tue, Apr 11, 2023 at 11:12 AM Jonathan Wakely wrote:
>
> On Tue, 11 Apr 2023 at 15:59, Patrick Palka via Libstdc++
> wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk perhaps?
>
> Yes, this is only for C++23 so OK for trunk now.
Yay thanks, pushed as r13-7161-g0f3b4d38
On 6 April 2023 12:49:53 CEST, Ajit Agarwal via Gcc-patches
wrote:
>Hello All:
>
>Eliminate unnecessary redundant extension within basic and across basic blocks.
To borrow HP's "arm-chair development mode", unfortunately most of the comments
i had for the previous version apply to this version
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 German team of translators. The file is available at:
https://translationproject.org/latest/gcc/de.po
(This file, 'gcc-13.1-b20230409.de.po',
On Tue, Mar 28, 2023 at 03:49:43PM +, Qing Zhao wrote:
> the C front-end has been approved by Joseph.
>
> Jacub, could you please eview the middle end part of the changes of this
> patch?
>
> The major change is in tree-object-size.cc (addr_object_size).
> (To use the new TYPE_INCLUDE_FLEXA
Hi Paul,
On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
I think that the changelog says it all. OK for mainline?
this looks almost fine, but still fails if one directly uses the
dummy argument as the ASSOCIATE target, as in:
program p
implicit none
character(4) :: c
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 happens in this PR, undefined phi arg from the
pre-header and uses of the previous iteratio
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/using.xml: Document libstdc++exp.a library.
* doc/html/*: Regenerate.
diff --git a/libstdc++-v3/doc/xml/manual/using.xml
b/libstdc++-v3/doc/xml/manual/using.xml
index 7f011a6d931..3a507fc1671 100644
--- a/libstd
Tested x86_64-linux and powerpc-aix. Pushed to trunk.
-- >8 --
AIX defines struct tstate with non-reserved names, so
adjust the 17_intro/names.cc test. It also defines struct user, which
conflicts with namespace user in some tests.
Replacing the global operator new doesn't work on AIX the same
On 4/6/23 19:11, juzhe.zh...@rivai.ai wrote:
From: Juzhe-Zhong
This patch should be merged before this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614935.html
According to RVV ISA, the EEW = 64 is enable only when -march=*zve64*
Current condition is incorrect, since -march=*
Yeah. But this patch is not appropriate now since it is conflict with the
upstream GCC.
I am gonna re-check the current upstream GCC and the queue patch for GCC 14.
If there are some conflicts, I will resend them.
Thanks
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-04-13 07:00
To: juzhe.zho
On 4/5/23 07:53, juzhe.zh...@rivai.ai wrote:
>> So fusion in this context is really about identifying cases where two
configuration settings are equivalent and you "fuse" them together.
Presumably this is only going to be possible when the vector insns are
just doing data movement rather tha
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 problem in tree_type_common an
On 3/27/23 00:59, juzhe.zh...@rivai.ai wrote:
From: Juzhe-Zhong
PR 108270
Fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108270.
Consider the following testcase:
void f (void * restrict in, void * restrict out, int l, int n, int m)
{
for (int i = 0; i < l; i++){
for
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
On Linux/x86_64,
58c8c1b383bc3c286d6527fc6e8fb62463f9a877 is the first bad commit
commit 58c8c1b383bc3c286d6527fc6e8fb62463f9a877
Author: Andre Vieira
Date: Tue Apr 11 10:07:43 2023 +0100
if-conv: Restore MASK_CALL conversion [PR10]
caused
FAIL: gcc.dg/vect/vect-simd-clone-16e.c scan
On Mon, Apr 10, 2023 at 10:08 AM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> This patch mentions Intel AMX-COMPLEX ISA support in GCC 13.
>
> Also it revises the march support according to newly released
> Intel Architecture Instruction Set Extensions and Future Features.
>
> Ok for trunk
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
On 4/12/23 10:58, Jakub Jelinek wrote:
On Wed, Apr 12, 2023 at 12:02:12PM +0200, Jakub Jelinek via Gcc-patches wrote:
I've tried the pr108947.c testcase, but I see no differences in the assembly
before/after the patch (but dunno if I'm using the right options).
The pr109040.c testcase from th
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
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 `malloc` may be attached on
> fopen:
> ```
> # 258 "/usr/
Hi Mike,
On 2023-04-12 22:46, Michael Meissner wrote:
On Wed, Apr 12, 2023 at 01:31:46PM +0800, Jiufu Guo wrote:
I understand that QP insns (e.g. xscmpexpqp) is valid if the system
meets ISA3.0, no matter BE/LE, 32-bit/64-bit.
I think option -mfloat128-hardware is designed for QP insns.
While
Hi Harald,
That's interesting - the string length '.q' is not set for either of the
associate blocks. I'm onto it.
Thanks
Paul
On Wed, 12 Apr 2023 at 20:26, Harald Anlauf wrote:
> Hi Paul,
>
> On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > I think that the c
On Wed, 12 Apr 2023, ??? wrote:
> >> It's not so much that we need to do that. But normally it's only worth
> >> adding internal functions if they do something that is too complicated
> >> to express in simple gimple arithmetic. The UQDEC case I mentioned:
>
> >>z = MAX (x, y) - y
>
> >> f
85 matches
Mail list logo
