LGTM!
Thanks for the revision.:-)
在 2023/12/13 下午11:26, Jiajie Chen 写道:
Several typos have been found and fixed: missing semicolons, using
variable name instead of type, duplicate functions and wrong types.
gcc/ChangeLog:
* doc/extend.texi(__lsx_vabsd_di): remove extra `i' in name.
We will read and test these patches as soon as possible.
Thanks!
在 2023/12/19 下午2:59, Xi Ruoyao 写道:
Superseds
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640871.html.
Per Jakub's response, vec_init patterns do not have a predicate on the
input operand so the operand can be
Am Montag, dem 18.12.2023 um 20:14 +0100 schrieb Jakub Jelinek:
> Hi!
>
> The following patch changes -Walloc-size warning to no longer warn
> about int *p = calloc (1, sizeof (int));, because as discussed earlier,
> the size is IMNSHO sufficient in that case, for alloc_size with 2
> arguments
Non functional change, clean up the code.
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_expand_vector_init_same): Remove "temp2" and reuse
"temp" instead.
(loongarch_expand_vector_init): Use gcc_unreachable () instead
of gcc_assert (0), and fix
Jakub says:
Then that seems like a bug in the loongarch vec_init pattern(s).
Those really don't have a predicate in any of the backends on the
input operand, so they need to force_reg it if it is something it
can't handle. I've looked e.g. at i386 vec_init and that is exactly
Superseds
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640871.html.
Per Jakub's response, vec_init patterns do not have a predicate on the
input operand so the operand can be *anything*. It's not safe to simply
move it into an reg, and we have to use force_reg instead.
The code clean
Hi Haochen,
on 2023/12/18 10:44, HAO CHEN GUI wrote:
> Hi,
> This patch cleans up pre-checkings of expand_block_compare. It does
> 1. Assert only P7 above can enter this function as it's already guard
> by the expand.
> 2. Return false when optimizing for size.
> 3. Remove P7 processor test as
Committed, thanks juzhe.
xu...@eswincomputing.com
From: juzhe.zhong
Date: 2023-12-19 14:01
To: Li Xu
CC: gcc-patches@gcc.gnu.org; kito.ch...@gmail.com; pal...@dabbelt.com; xuli
Subject: Re: [PATCH] testsuite: Fix dump checks under different riscv-sim for
RVV.
ok
Replied Message
ok Replied Message FromLi XuDate12/19/2023 13:31 Togcc-patches@gcc.gnu.org Cckito.ch...@gmail.com,pal...@dabbelt.com,juzhe.zh...@rivai.ai,xuliSubject[PATCH] testsuite: Fix dump checks under different riscv-sim for RVV.
Similar for A < B ? B : A to MAX_EXPR.
There're codes in the frontend to optimize such pattern but failed to
handle testcase in the PR since it's exposed at gimple level when
folding backend builtins.
pr95906 now can be optimized to MAX_EXPR as it's commented in the
testcase.
// FIXME: this
From: xuli
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/cpymem-1.c: Fix checks under medany.
* gcc.target/riscv/rvv/base/cpymem-strategy-3.c: Fix checks.
* gcc.target/riscv/rvv/base/cpymem-strategy-4.c: Ditto.
---
.../gcc.target/riscv/rvv/base/cpymem-1.c |
Fix this FAIL:
FAIL: gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-7.c scan-tree-dump-times
vect "Maximum lmul = 2" 1
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-7.c: Adapt test.
---
gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-7.c | 2 +-
Since
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2e7abd09621a4401d44f4513adf126bce4b4828b
we only allow VLSmodes with size <= TARGET_MIN_VLEN * TARGET_MAX_LMUL.
So when -march=rv64gcv default LMUL = 1, we don't have VLS modes of
256/512/1024 vectors.
Disable them in vect test which fixes
On Dec 15, 2023, Richard Biener wrote:
> You have to be generally careful when working within IPA
> with function bodies without push/pop_cfun around that, several APIs
> have variants with struct function sepcified, using the wrong one
> will get you a NULL cfun which _some_ of them handle
On 12/18/23 17:05, Jeff Law wrote:
On 12/18/23 15:16, Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64.
The patch affects a sensitive part of LRA. So
Hi Haochen,
on 2023/12/18 10:43, HAO CHEN GUI wrote:
> Hi,
> The patch corrects the definition of
> TARGET_EFFICIENT_OVERLAPPING_UNALIGNED and replace it with the call of
> slow_unaligned_access.
>
> Compared with last version,
>
OK。
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-12-19 09:44
To: gcc-patches
CC: kito.cheng; palmer; juzhe.zhong; xuli
Subject: [PATCH] testsuite: Fix cpymem-2.c dump checks under different
riscv-sim for RVV.
From: xuli
gcc/testsuite/ChangeLog:
*
From: xuli
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/cpymem-2.c: Fix checks.
---
.../gcc.target/riscv/rvv/base/cpymem-2.c | 44 ++-
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/cpymem-2.c
This Go frontend patch moves the lowering pass after the type
determination and the type checking passes. This lets us simplify
some of the code that determines the type of an expression, which
previously had to work correctly both before and after type
determination.
I'm doing this to help with
The function `reconcat` cannot append string(s) to NULL,
as the concat process will stop at the first NULL.
Let's always put the `ret` to the end, as it may be NULL.
We keep use reconcat here, due to that reconcat can make it
easier if we add more hardware features detecting, for example
by
In order to add other vector related extensions in the future, this
patch add one more parameter in the function_group_info, it will be
used to determine whether intrinsic registration processing is required.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-functions.def
Thanks for refactor it. You can commit it today.
Thanks.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2023-12-18 11:28
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH] RISC-V: Add required_extensions in function_group
In order to add other vector related
On 12/18/23 15:16, Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64.
The patch affects a sensitive part of LRA. So I will monitor that the
commit does
This also happens to fix composition of these closure objects.
PR libstdc++/112802
PR libstdc++/113068
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::_To::operator()): Add constraints.
(__detail::_To2::operator()): Likewise.
*
Jakub Jelinek 于2023年12月18日周一 16:10写道：
>
> On Mon, Dec 18, 2023 at 11:44:21AM +0800, YunQiang Su wrote:
> > The function `reconcat` cannot append string(s) to NULL,
> > as the concat process will stop at the first NULL.
> >
> > Let's initialize `ret` with `concat (" ", NULL)`, then
> > it can be
Thanks Robin send initial patch to fix this ICE bug.
CC to Richard S, Richard B, and Andrew.
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-19 03:50
To: gcc-patches
CC: rdapp.gcc; Li, Pan2; juzhe.zh...@rivai.ai
Subject: [PATCH] fold-const: Handle AND, IOR, XOR with stepped
In r14-6603-gfcdd2757c76bf925115b8e1ba4318d6366dd6f09 I messed up the
parentheses in aarch64_stp_reg_operand, the indentation shows the
intended nesting of the conditions.
This patch fixes that.
This fixes PR113061 which shows IRA substituting (const_int 1) into a
writeback stp pattern as a
Ping David. :)
Le sam. 9 déc. 2023 à 12:12, Guillaume Gomez
a écrit :
>
> Added it.
>
> Le jeu. 7 déc. 2023 à 18:13, Antoni Boucher a écrit :
> >
> > It seems like you forgot to prefix the commit message with "libgccjit:
> > ".
> >
> > On Thu, 2023-11-30 at 10:55 +0100, Guillaume Gomez wrote:
>
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64.
The patch affects a sensitive part of LRA. So I will monitor that the
commit does not create serious failures on other targets. If
On 12/18/23 16:57, Nathan Sidwell wrote:
On 12/18/23 16:31, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Does this make sense? Did you have
another theory
about how to merge these?
Why isn't push_abi_namespace doing the right setup here? (and I think
get_global_binding might be
On 12/15/23 14:07, Patrick Palka wrote:
On Thu, 1 Jun 2023, Patrick Palka wrote:
During partial ordering, we want to look through dependent alias
template specializations within template arguments and otherwise
treat them as opaque in other contexts (see e.g. r7-7116-g0c942f3edab108
and
On 12/18/23 16:31, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Does this make sense? Did you have another theory
about how to merge these?
Why isn't push_abi_namespace doing the right setup here? (and I think
get_global_binding might be similarly problematic?)
nathan
-- 8< --
On 12/15/23 14:06, Patrick Palka wrote:
On Mon, 11 Sep 2023, Patrick Palka wrote:
On Thu, 1 Jun 2023, Patrick Palka wrote:
For a complex alias template-id, dependent_alias_template_spec_p returns
true if any template argument of the template-id is dependent. This
predicate indicates that
On 12/18/23 14:50, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
Here we first use and therefore synthesize the local class operator<=>
from an unevaluated context, which inadvertently affects synthesization
by causing
On 12/18/23 14:50, Patrick Palka wrote:
Bootstrappde and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
When computing a direct conversion to reference type fails and yields a
bad conversion, reference_binding incorrectly commits to that conversion
rather than
On 12/18/23 14:56, Marek Polacek wrote:
On Mon, Dec 18, 2023 at 02:50:04PM -0500, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
LGTM but...
-- >8 --
The deprecated and unavailable attributes weren't working when used on
a template
Tested x86_64-pc-linux-gnu. Does this make sense? Did you have another theory
about how to merge these?
-- 8< --
Doing a dynamic_cast in both TUs broke because we were declaring a new
__class_type_info in _b that conflicted with the one imported in the global
module from _a.
Eliminate redundant compare between set{z,nz} and j{z,nz}:
setz %al; test %al,%al; jz <...> -> setz %al; jnz <...> and
setnz %al, test %al,%al; jz <...> -> setnz %al; jz <...>.
We can use the original Zero-flag value instead of setting the
temporary register and testing it for zero.
On Mon, 2023-12-18 at 21:15 +0100, Jakub Jelinek wrote:
>
> Then that seems like a bug in the loongarch vec_init pattern(s).
> Those really don't have a predicate in any of the backends on the input
> operand, so they need to force_reg it if it is something it can't handle.
> I've looked e.g. at
On Tue, Dec 19, 2023 at 04:01:52AM +0800, Xi Ruoyao wrote:
> On Mon, 2023-12-18 at 18:45 +0100, Jakub Jelinek wrote:
> > On Tue, Dec 19, 2023 at 12:48:46AM +0800, Xi Ruoyao wrote:
> > > > > gcc/ChangeLog:
> > > > >
> > > > > PR middle-end/113033
> > > > > * expmed.cc (expand_shift_1):
On Mon, 2023-12-18 at 18:45 +0100, Jakub Jelinek wrote:
> On Tue, Dec 19, 2023 at 12:48:46AM +0800, Xi Ruoyao wrote:
> > > > gcc/ChangeLog:
> > > >
> > > > PR middle-end/113033
> > > > * expmed.cc (expand_shift_1): When expanding rotate shift, call
> > > > negate_rtx
On Mon, Dec 18, 2023 at 02:50:04PM -0500, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
LGTM but...
> -- >8 --
>
> The deprecated and unavailable attributes weren't working when used on
> a template redeclaration ultimately because the
Bootstrappde and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
When computing a direct conversion to reference type fails and yields a
bad conversion, reference_binding incorrectly commits to that conversion
rather than attempting a conversion via a temporary. This
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here we first use and therefore synthesize the local class operator<=>
from an unevaluated context, which inadvertently affects synthesization
by causing functions used within the definition (such as the
Hi,
found in PR112971, this patch adds folding support for bitwise operations
of const duplicate zero vectors and stepped vectors.
On riscv we have the situation that a folding would perpetually continue
without simplifying because e.g. {0, 0, 0, ...} & {7, 6, 5, ...} would
not fold to {0, 0, 0,
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
The deprecated and unavailable attributes weren't working when used on
a template redeclaration ultimately because the corresponding tree flags
on the underlying decls weren't being merged across
On Mon, Dec 18, 2023 at 07:11:59PM +0100, Harald Anlauf wrote:
> Dear all,
>
> starting with Fortran 2018, DATE_AND_TIME allowed a non-default
> integer VALUES argument.
>
> While gfortran accepts this silently, this failed at runtime
> because the library implementation beyond kind=4 and kind=8
Hi!
The following patch changes -Walloc-size warning to no longer warn
about int *p = calloc (1, sizeof (int));, because as discussed earlier,
the size is IMNSHO sufficient in that case, for alloc_size with 2
arguments warns if the product of the 2 arguments is insufficiently small.
Also, it
On Fri, 8 Sep 2023, Arthur Cohen wrote:
> + if (c < 0x80)
> + {
> +if (('A' <= c && c <= 'Z') || ('a' <= c && c <= 'z'))
> + return CPP_XID_START | CPP_XID_CONTINUE;
> +if (('0' <= c && c <= '9') || c == '_')
> + return CPP_XID_CONTINUE;
This may be an artifact of how the patch was
With the recently introduced -munaligned-symbols option byte-sized
variables which are resolved externally are considered to be
potentially misaligned.
However, this should rather also be applied to symbols which resolve
locally if they are weak. Done with this patch.
Committed to mainline.
On 12/18/23 11:32, Joseph Myers wrote:
On Sat, 16 Dec 2023, Jeff Law wrote:
I tracked this down to the port unconditionally adding -funsigned-bitfields to
CC1_SPEC. According to the comment it's how the ABI is defined for the mcore
targets.
We explicitly document (under Non-bugs in
On 12/17/23 16:51, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
An alternative approach for the lambda issue would be to modify
'maybe_add_lambda_conv_op' to not pass a null pointer, but I wasn't sure
what the best approach for that would be.
I don't
On Sat, 16 Dec 2023, Jeff Law wrote:
> I tracked this down to the port unconditionally adding -funsigned-bitfields to
> CC1_SPEC. According to the comment it's how the ABI is defined for the mcore
> targets.
We explicitly document (under Non-bugs in trouble.texi) that we don't do
this, and
On Sun, 17 Dec 2023, Florian Weimer wrote:
> This matches other compiler diagnostics. No test updates are needed
> because c-c++-common/pr95378.c does not match a specific -W option.
>
> Fixes commit d2384b7b24f8557b66f6958a05ea99ff4307e75c ("c-family:
> check qualifiers of arguments to
Dear all,
starting with Fortran 2018, DATE_AND_TIME allowed a non-default
integer VALUES argument.
While gfortran accepts this silently, this failed at runtime
because the library implementation beyond kind=4 and kind=8
was missing.
Futhermore, the standard effectively requires that the integer
On Tue, Dec 19, 2023 at 12:48:46AM +0800, Xi Ruoyao wrote:
> > > gcc/ChangeLog:
> > >
> > > PR middle-end/113033
> > > * expmed.cc (expand_shift_1): When expanding rotate shift, call
> > > negate_rtx instead of simplify_gen_unary (NEG, ...).
>
> > The key difference being that using
This patch fixes two issues with the handling of 128-bit TImode integer
constants in the x86_64 backend. The main issue is that GCC always
tries to load 128-bit integer constants via broadcasts to vector SSE
registers, even if the result is required in general registers. This
is seen in the two
Hi!
> --- a/libgrust/configure.ac
> +++ b/libgrust/configure.ac
> -# AM_ENABLE_MULTILIB(, ..)
> +AM_ENABLE_MULTILIB(, ..)
Such a change was applied eventually, and is necessary for target builds
-- but potentially harmful for host builds. OK to push the attached
"libgrust: 'AM_ENABLE_MULTILIB'
gcc/ChangeLog:
* gimple-fold.cc (optimize_atomic_compare_exchange_p): enable
for SCALAR_FLOAT_TYPE_P type of expected var, or if TYPE_PRECISION
is different from mode's bitsize
(fold_builtin_atomic_compare_exchange): if TYPE_PRECISION is
different from
Hi, I noticed PR71716 and I want to enable ATOMIC_COMPARE_EXCHANGE internal-fn
optimization
for floating type or types contains padding (e.g., long double). Please tell me
if I happen to
make any mistakes, Thanks!
Firstly, about the concerns of sNaNs float/double value, it seems work well and
On Mon, 2023-12-18 at 08:39 -0700, Jeff Law wrote:
>
>
> On 12/18/23 06:42, Xi Ruoyao wrote:
> > With simplify_gen_unary we end up with a not fully expanded RTX like
> >
> > (set (reg:SI 90) (and:SI (neg:SI (reg:SI 80)) (const_int 63)))
> >
> > Then it will cause an ICE with
It is always safe to set the computed bit for dynamic object sizes at
the end of collect_object_sizes_for because even in case of a dependency
loop encountered in nested calls, we have an SSA temporary to actually
finish the object size expression. The reexamine pass for dynamic
object sizes is
The problem here is that in C++ structs and classes have a
linkage too so the type vertex is not considered local to
the TU but will conflict with the globally defined one
in graphds.h. The simple way to fix this is to wrap the ones
defined locally in gimple-ssa-sccopy.cc inside an anonymous
On 12/18/23 06:42, Xi Ruoyao wrote:
With simplify_gen_unary we end up with a not fully expanded RTX like
(set (reg:SI 90) (and:SI (neg:SI (reg:SI 80)) (const_int 63)))
Then it will cause an ICE with unrecognizable insn.
gcc/ChangeLog:
PR middle-end/113033
* expmed.cc
Hi Sandra,
On 17.12.23 20:02, Sandra Loosemore wrote:
This patch introduces enumerators to represent trait-set names and
trait names, which makes it easier to use tables to control other
behavior and for switch statements to dispatch on the tags. The tags
are stored in the same place in the
Hi Andrew!
On 2023-12-13T15:46:45+, Andrew Stubbs wrote:
> Some AMD GCN devices support an "XNACK" mode in which the device can
> handle page-misses (and maybe other traps in memory instructions), but
> it's not completely invisible to software.
>
> We need this now to support OpenMP Unified
The "exploitable vulnerability" may lead to a misunderstanding that
missed hardening issues are considered vulnerabilities, just that
they're not exploitable. This is not true, since while hardening bugs
may be security-relevant, the absence of hardening does not make a
program any more
On Mon, 18 Dec 2023, Jakub Jelinek wrote:
> On Mon, Dec 18, 2023 at 03:08:49PM +0100, Richard Biener wrote:
> > The following improves the manual work needed to make a -gimple dump
> > valid input to the GIMPLE FE. First of all it recognizes the 'sizetype'
> > tree and dumps it as __SIZETYPE__,
On Mon, Dec 18, 2023 at 03:08:49PM +0100, Richard Biener wrote:
> The following improves the manual work needed to make a -gimple dump
> valid input to the GIMPLE FE. First of all it recognizes the 'sizetype'
> tree and dumps it as __SIZETYPE__, then it changes dumping vector types
> without name
The following improves the manual work needed to make a -gimple dump
valid input to the GIMPLE FE. First of all it recognizes the 'sizetype'
tree and dumps it as __SIZETYPE__, then it changes dumping vector types
without name from 'vector(n) T' to 'T [[gnu::vector_size(n')]]' which
we can parse
gcc/ChangeLog:
* config/loongarch/loongarch.md (rotl3):
New define_expand.
* config/loongarch/simd.md (vrotl3): Likewise.
(rotl3): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/rotl-with-rotr.c: New test.
*
With simplify_gen_unary we end up with a not fully expanded RTX like
(set (reg:SI 90) (and:SI (neg:SI (reg:SI 80)) (const_int 63)))
Then it will cause an ICE with unrecognizable insn.
gcc/ChangeLog:
PR middle-end/113033
* expmed.cc (expand_shift_1): When expanding rotate
On Sun, 17 Dec 2023, John David Anglin wrote:
> The sentence about 64-bit libffi for hpux also can be removed. I ported
> it a few years ago.
Thanks! I made this change on top and pushed the resulting changeset.
>> (I believe it would be great if you could have a look at that part of the
>>
OK.
Regards
Robin
Reworked Stam's patch after comments in:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640362.html
The original gcc ChangeLog remains unchanged, but I did split up some tests so
here is the testsuite ChangeLog.
gcc/testsuite/ChangeLog:
* gcc.target/arm/lob.h: Update
Re-sending Stam's first patch, same as:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635301.html
Hopefully patchworks can pick this up :)
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index a9c2752c0ea..0b0e8620717 100644
--- a/gcc/config/arm/arm.h
+++
Resending series to make use of the Linaro pre-commit CI in patchworks.
Andre Vieira (2):
arm: Add define_attr to to create a mapping between MVE predicated and
unpredicated insns
arm: Add support for MVE Tail-Predicated Low Overhead Loops
--
2.17.1
The following adds dumping of TARGET_MEM_REF in -gimple form and
adds parsing of it to the GIMPLE FE.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR c/111975
gcc/c/
* gimple-parser.cc (c_parser_gimple_postfix_expression):
Parse TARGET_MEM_REF extended
Update in V2 with more information in commit log:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640863.html
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-12-18 18:59
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [PATCH] RISC-V:
For 'wv' instructions, e.g. vwadd.wv vd,vs2,vs1.
vs2 has same EEW as vd.
vs1 has smaller than vd.
So, vs2 can overlap with vd, but vs1 can only overlap highest-number of vd
when LMUL of vs1 is greater than 1.
We already have supported overlap for vs1 LMUL >= 1.
But I forget vs1 LMUL < 1, vs2
Hi!
As written earlier, this test was written with the x86 specifics in mind
and adding dg-final directives for it for other arches makes it unreadable.
If a declare variant call can be resolved in gimple already as in the
aarch64 or gcn cases, it can be done in gcc.dg/gomp/ and I believe we have
For 'wv' instructions, e.g. vwadd.wv vd,vs2,vs1.
vs2 has same EEW as vd.
vs1 has smaller than vd.
So, vs2 can overlap with vd, but vs1 can only overlap highest-number of vd
when LMUL of vs1 is greater than 1.
We already have supported overlap for vs1 LMUL >= 1.
But I forget vs1 LMUL < 1, vs2
LGTM.
Regards
Robin
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Add RV32.
---
gcc/testsuite/lib/target-supports.exp | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index
LGTM.
Regards
Robin
Hi Juzhe,
> -} elseif [istarget riscv64-*-*] {
> +} elseif [istarget riscv*-*-*] {
> if [check_effective_target_riscv_v] {
> lappend DEFAULT_VECTCFLAGS "--param" "riscv-vector-abi"
> set dg-do-what-default run
Yes, that's reasonable. A bit further down we have
On Mon, Dec 18, 2023 at 9:35 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs because we aren't careful enough with
> alloc_size attribute. We do check that such an argument exists
> (although wouldn't handle correctly functions with more than INT_MAX
> arguments), but didn't
On Thu, Dec 14, 2023 at 07:59:26PM -0500, Patrick Palka wrote:
> * g++.dg/abi/abi-tag25.C: New test.
> * g++.dg/abi/abi-tag25a.C: New test.
Line 11 of abi-tag25.C is wrapped in #if __cpp_variable_templates
which isn't defined for -std=c++11, so we can't expect a warning
in that case
This is a small change to libstdc++ which does not change any behavior.
This change has two, ihmo positive, implications:
- The implicit conversion from double to int is avoided (Avoiding a
warning).
- No floating point number is used at all, which could be significant
in some
Hi!
The following testcase ICEs because we aren't careful enough with
alloc_size attribute. We do check that such an argument exists
(although wouldn't handle correctly functions with more than INT_MAX
arguments), but didn't check that it is scalar integer, the ICE is
trying to fold_convert a
On Mon, Dec 18, 2023 at 11:44:21AM +0800, YunQiang Su wrote:
> The function `reconcat` cannot append string(s) to NULL,
> as the concat process will stop at the first NULL.
>
> Let's initialize `ret` with `concat (" ", NULL)`, then
> it can be used by reconcat.
>
> gcc/
>
> PR
91 matches
Mail list logo
