Thanks Jeff for comments.
> I'd put it in that code. Probably something like
> && GET_CODE (return_copy_pat) = SET
> && OBJECT_P (SET_SRC (return_copy_pat)))
> That way we make it clear that we should only be looking at SET_SRC of
> an actual SET.
> Is there some reason you put the guard earl
From: Pan Li
This patch would like to support the rounding mode API for the
VFNMSUB as the below samples.
* __riscv_vfnmsub_vv_f32m1_rm
* __riscv_vfnmsub_vv_f32m1_rm_m
* __riscv_vfnmsub_vf_f32m1_rm
* __riscv_vfnmsub_vf_f32m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/ri
Committed, thanks Jeff.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Saturday, August 12, 2023 11:57 AM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@sifive.com; kito.ch...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH] RISC-V: Add
> If we encounter a uarch where the other sequence is better, then I think
> we can do something like query costs or the like and select between the
> approaches -- but no need to do that now.
> So OK for the trunk.
Thanks, patch will be committed soon.
-- Original --
On 8/11/23 20:30, Juzhe-Zhong wrote:
This patch fixes bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110994
This is caused VLS modes incorrect codes int register allocation.
The original case trigger the ICE is fortran code but I can reproduce
with a C code.
PR target/110994
gc
From: Tsukasa OI
After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
extensions") changed how do we handle unknown extensions, we have no
guarantee that we can share the same architectural string with Binutils
(specifically, the assembler).
To avoid compilation errors on shar
From: Tsukasa OI
After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
extensions") changed how do we handle unknown extensions, we have no
guarantee that we can share the same architectural string with Binutils
(specifically, the assembler).
To avoid compilation errors on shar
From: Tsukasa OI
After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
extensions") changed how do we handle unknown extensions, we have no
guarantee that we can share the same architectural string with Binutils
(specifically, the assembler).
To avoid compilation errors on shar
Hello,
After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
extensions") changed how do we handle unknown extensions, we have no
guarantee that we can share the same architectural string with Binutils
(specifically, the assembler).
To avoid compilation errors on shared Assemble
This patch fixes bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110994
This is caused VLS modes incorrect codes int register allocation.
The original case trigger the ICE is fortran code but I can reproduce
with a C code.
PR target/110994
gcc/ChangeLog:
* config/riscv/riscv-
On Thu, 2023-08-10 at 15:04 +0200, Stefan Schulze Frielinghaus via Gcc-
patches wrote:
> In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I
> completely missed the fact that the normal form of a generated constant for a
> mode with fewer bits than in HOST_WIDE_INT is a sign exte
Committed, thanks Jeff.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Friday, August 11, 2023 10:47 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@gmail.com; kito.ch...@sifive.com; rdapp@gmail.com
Subject: Re: [PATCH] RISC-V: Fix v
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Friday, August 11, 2023 6:00 PM
To: Juzhe-Zhong
Cc: GCC Patches ; Kito Cheng ;
Jeff Law ; Robin Dapp
Subject: Re: [PATCH V2] RISC-V: Allow CONST_VECTOR for VLS modes
LGTM
On 2023/08/12 8:30, Jeff Law wrote:
>
>
> On 8/9/23 16:39, Tsukasa OI wrote:
>> On 2023/08/10 5:05, Jeff Law wrote:
>
>>> I'd tend to think we do not want to expose the intrinsic unless the
>>> right extensions are enabled -- even though the encoding is a no-op and
>>> we could emit it as a .ins
On 8/11/23 17:32, Vineet Gupta wrote:
On 8/1/23 12:17, Vineet Gupta wrote:
Hi Jeff,
As discussed this morning, I'm sending over dumps for the optim of DF
const -0.0 (PR/110748) [1]
For rv64gc_zbs build, IRA is undoing the split which eventually leads
to ICE in final pass.
[1] https://g
On Fri, 11 Aug 2023 16:30:29 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 8/9/23 16:39, Tsukasa OI wrote:
On 2023/08/10 5:05, Jeff Law wrote:
I'd tend to think we do not want to expose the intrinsic unless the
right extensions are enabled -- even though the encoding is a no-op and
we coul
On 8/1/23 12:17, Vineet Gupta wrote:
Hi Jeff,
As discussed this morning, I'm sending over dumps for the optim of DF
const -0.0 (PR/110748) [1]
For rv64gc_zbs build, IRA is undoing the split which eventually leads
to ICE in final pass.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11074
On 8/9/23 16:39, Tsukasa OI wrote:
On 2023/08/10 5:05, Jeff Law wrote:
I'd tend to think we do not want to expose the intrinsic unless the
right extensions are enabled -- even though the encoding is a no-op and
we could emit it as a .insn.
I think that makes sense. The only reason I impl
On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> The previous patch in this series introduced the concept of LC_GEN line
> maps. This patch continues on the path to using them to improve _Pragma
> diagnostics, by adding a new source_id SRC member to struct
> expanded_location, which is popul
On 8/11/23 03:01, Lehua Ding wrote:
Hi,
This patch revert the convert from vmv.s.x to vmv.v.i and add new pattern
optimize the special case when the scalar operand is zero.
Currently, the broadcast pattern where the scalar operand is a imm
will be converted to vmv.v.i from vmv.s.x and the ma
On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
Hi Lewis, thanks for the patch...
> Add a new linemap reason LC_GEN which enables encoding the location of data
> that was generated during compilation and does not appear in any source file.
> There could be many use cases, such as, for insta
Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 also needed.
-- >8 --
When writing to a contiguous iterator, std::format_to_n(out, n, ...)
always returns out + n, even if it wrote fewer than n characters to the
iterator.
The problem is in the _M_finish() member function of the _Iter_sin
This patch adds new functions to the analyzer for checking that
an argument at a callsite is a pointer to a valid null-terminated
string, and uses this for the following known functions:
- error (param 3, the format string)
- error_at_line (param 5, the format string)
- putenv
- strchr (1st param)
Some of Andrew's recent match.pd changes triggered a regression in my
tester for the rx processor for c-torture/execute/pr66940.c which would
be exposed only during an LTO compilation.
Specifically the subdi3_internal pattern had the wrong idiom to detect a
carry from the high word into the lo
Committed, thanks Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Biener via Gcc-patches
Sent: Friday, August 11, 2023 9:57 PM
To: Juzhe-Zhong
Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com
Subject: Re: [PATCH V2] VECT: Fix ICE on MASK_LEN_{LOAD,STORE} wh
On Fri, 11 Aug 2023, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Aug 11, 2023 at 01:25:38PM +, Joseph Myers wrote:
> > On Fri, 11 Aug 2023, Jakub Jelinek wrote:
> >
> > > All that is diagnosed is when result is bool or enum (any kind). Even for
> >
> > I'd suggest tests that other nonsen
On 8/8/23 21:05, pan2...@intel.com wrote:
From: Pan Li
In same cases, like gcc/testsuite/gcc.dg/pr78148.c in RISC-V, there will
be only 1 operand when SET_SRC in create_pre_exit. For example as below.
(insn 13 9 14 2 (clobber (reg/i:TI 10 a0))
"gcc/testsuite/gcc.dg/pr78148.c":24:1 -1
(e
On 8/11/23 13:44, Jeff Law wrote:
On 8/11/23 13:15, Patrick O'Neill wrote:
On rv32 targets, this patch fixes ztso testcases errors like this:
cc1: error: ABI requires '-march=rv32'
2023-08-11 Patrick O'Neill
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo-table-ztso-amo-add-1.c: Add
On 8/11/23 13:15, Patrick O'Neill wrote:
On rv32 targets, this patch fixes ztso testcases errors like this:
cc1: error: ABI requires '-march=rv32'
2023-08-11 Patrick O'Neill
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo-table-ztso-amo-add-1.c: Add -mabi=lp64d
to dg-option
I've noticed there were still some strange indentations in the last
patch ... however, I think I've finally figured out a sane formatting
solution for me (fingers crossed). I will address them in the
follow-up patch at the same time as adding more test coverage.
---
In case, anyone else using VSC
On rv32 targets, this patch fixes ztso testcases errors like this:
cc1: error: ABI requires '-march=rv32'
2023-08-11 Patrick O'Neill
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo-table-ztso-amo-add-1.c: Add -mabi=lp64d
to dg-options.
* gcc.target/riscv/amo-table-ztso-a
Tested x86_64-linux, pushed to trunk.
This is a pure addition that only affects C++20 mode, so I'm considering
backporting it to gcc-13 at some point (once any dust has settled from
landing it on trunk).
-- >8 --
This adds the missing C++20 features to .
I've implemented my proposed resolutions
We were reserving one of the hard registers in BPF in order to
implement dynamic stack allocation: alloca and VLAs. However, there is
kernel code that has inline assembly that requires all the non-fixed
registers to be available for register allocation.
This patch:
1. Liberates r9 that is now ava
BPF currently limits the number of registers used to pass arguments to
functions to five registers. There is a check for this at function
expansion time. However, if a function is guaranteed to be always
inlined (and its body never generated) by virtue of the always_inline
attribute, it can "rece
On 8/11/23 13:35, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK.
-- >8 --
This makes the generic pretty printer print braces around a TREE_VEC
like we do for CONSTRUCTOR. This should improve readability of nested
TREE_VECs in particular.
gcc/ChangeLog:
Thanks for the feedback! I've incorporated the changes (aside from
expanding test coverage, which I plan on releasing in a follow-up),
rebased, and performed a bootstrap and regtest on
aarch64-unknown-linux-gnu. Since you mentioned that it is good for trunk
with nits fixed and no problems after reb
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
This makes the generic pretty printer print braces around a TREE_VEC
like we do for CONSTRUCTOR. This should improve readability of nested
TREE_VECs in particular.
gcc/ChangeLog:
* tree-pretty-print.cc (dump_generic_n
On Fri, Aug 11, 2023 at 01:25:38PM +, Joseph Myers wrote:
> On Fri, 11 Aug 2023, Jakub Jelinek wrote:
>
> > All that is diagnosed is when result is bool or enum (any kind). Even for
>
> I'd suggest tests that other nonsense cases are diagnosed, such as
> floating-point or pointer arguments
ChangeLog:
* MAINTAINERS: Add myself.
Signed-off-by: Eric Feng
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1e54844c905..7a3ad68bc42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -411,6 +411,7 @@ Chris Fairles
Second attempt to fix this PR. Tested x86_64-linux, pushed to trunk.
-- >8 --
Calling log10(0.0) returns -inf which has undefined behaviour when
converted to an integer. We only need to use log10 for large values
anyway. If the value is zero then the larger buffer is only needed due
to a large pr
Hi,
Thanks for the finding.
I will fix it in next upcoming patches.
Thanks,
Cupertino
Shung-Hsi Yu writes:
> Hi,
>
> Thanks for working on the BPF backend!
>
> I noticed a tiny typo while test compiling libbpf-tools[1]. (Have yet look
> into the cause of failure in detail though)
>
> On Thu,
>> But combine doesn't run at -O0. So something is
inconsistent. I >> certainly believe we need to avoid the
mem->mem case, but that's >> independent of combine and affects all
optimization levels. > This is an new bug when running all tests after
fixing the combine bug. > I understand that
> But combine doesn't run at -O0. So something is inconsistent. I
> certainly believe we need to avoid the mem->mem case, but that's
> independent of combine and affects all optimization levels.
This is an new bug when running all tests after fixing the combine bug.
I understand that maybe I sh
On 8/11/23 04:48, Jakub Jelinek wrote:
On Fri, Aug 11, 2023 at 01:13:32AM +0200, Jakub Jelinek wrote:
Looking at the first uses of the builtin back in 90s in va*.h, it certainly
relied on array/function decay there (the macros would abort e.g. on
array_type_class, function_type_class and various
On 8/8/23 21:54, Lehua Ding wrote:
Hi Jeff,
> The pattern's operand 0 explicitly allows MEMs as do the constraints.
> So forcing the operand into a register just seems like it's papering
> over the real problem.
The added of force_reg code is address the problem preduced after
address th
> Hi Jin Ma,
>
> On 5/16/23 00:06, jinma via Gcc-patches wrote:
> > On 5/15/23 07:16, Jin Ma wrote:
> >>
> >> Do we also need to check Z[FDH]INX too?
> >>
> >> Otherwise it looks pretty good. We just need to wait for everything to
> >> freeze and finalization on the assembler interface.
> >>
> >>
On 8/11/23 09:43, Lehua Ding wrote:
> I can't speak for other uarches, but as a guiding principle for Ventana
> we're assuming vsetvl instructions are common and as a result need to be
> very cheap in hardware. It's likely a good tradeoff for us.
> I could see other uarches making diffe
> I can't speak for other uarches, but as a guiding principle for Ventana
> we're assuming vsetvl instructions are common and as a result need to be
> very cheap in hardware. It's likely a good tradeoff for us.
> I could see other uarches making different design choices though. So
at
> a high
On Fri, 2023-08-11 at 13:51 +0200, priour...@gmail.com wrote:
> From: benjamin priour
Hi Benjamin, thanks for the patch.
Overall, the patch is close to being ready, but see the various
comments inline below...
>
> This patch introduces -fanalyzer-show-events-in-system-headers,
> disabled by de
Sorry, I had some problems with email. Therefore there are email
duplication and they were sent to g...@gcc.gnu.org instead of
gcc-patches@gcc.gnu.org
On 8/9/23 16:54, Vladimir Makarov wrote:
On 8/9/23 07:15, senthilkumar.selva...@microchip.com wrote:
Hi,
After turning on FP -> SP el
On 2023-08-11 11:12, David Edelsohn wrote:
The text above states "bugs in these libraries may be evaluated for
security impact", but there is no comment about the criteria for a
security impact, unlike the GLIBC SECURITY.md document. The text seems
to imply the "What is a security bug?" defini
On 8/10/23 05:33, Thomas Neumann via Gcc-patches wrote:
Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
Rainer Orth successfully tested the patch on Solaris with a full bootstrap.
Some uncommon unwinding table encodings need to access the base pointer
for address co
On 2023-08-11 11:09, Paul Koning wrote:
On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar wrote:
On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output for
On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar
wrote:
> On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
> >> Do you have a suggestion for the language to address libgcc,
> >> libstdc++, etc. and libiberty, libbacktrace, etc.?
> >
> > I'll work on this a bit and share a draft.
>
> Hi David,
>
>
On 8/10/23 13:27, John David Anglin wrote:
Ping.
On 2023-07-19 2:59 p.m., John David Anglin wrote:
Tested on trunk with hppa64-hp-hpux11.11.
Okay?
Dave
---
Use strtol instead of std::stoi [PR110646]
Implementation of std::stoi was overlooked on hppa-hpux, so use
strtol instead.
2023-07-
> On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output for
valid input source code
On 8/11/23 05:51, Richard Biener wrote:
On Fri, Aug 11, 2023 at 11:17 AM Andrew Pinski via Gcc-patches
wrote:
So it turns out there was a simplier way of starting to
improve VRP to start to fix PR 110131, PR 108360, and PR 108397.
That was rewrite test_for_singularity to use range_op_handler
On 8/11/23 03:01, Lehua Ding wrote:
Hi,
This patch revert the convert from vmv.s.x to vmv.v.i and add new pattern
optimize the special case when the scalar operand is zero.
Currently, the broadcast pattern where the scalar operand is a imm
will be converted to vmv.v.i from vmv.s.x and the ma
On 8/11/23 02:45, Juzhe-Zhong wrote:
This patch fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110985
PR target/110985
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_vec_series): Refactor the expander.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autove
On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output for
valid input source code.
I think this leaves open the interpretation "every wrong code bug
is potenti
On 2023/08/11 23:15, Jeff Law wrote:
>
>
> On 8/11/23 03:11, Tsukasa OI via Gcc-patches wrote:
>> From: Tsukasa OI
>>
>> Commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
>> extensions") changed how do we handle unknown extensions and
>> commit 6f709f79c915a ("[committed] [RISC-V
From: Ju-Zhe Zhong
Hi, Richard and Richi.
This patch add support live vectorization by VEC_EXTRACT for LEN loop control.
Consider this following case:
#include
#define EXTRACT_LAST(TYPE) \
TYPE __attribute__ ((noinline, noclone)) \
test_##TYPE (TYPE *x, int n, T
On Fri, 11 Aug 2023 at 15:50, Martin Jambor wrote:
> Hello,
>
> On Fri, Aug 11 2023, Christophe Lyon wrote:
> > Hi Martin,
> >
> >
> > On Fri, 4 Aug 2023 at 18:26, Martin Jambor wrote:
> >
> >> Hello,
> >>
> >> On Wed, Aug 02 2023, Richard Biener wrote:
> >> > On Mon, Jul 31, 2023 at 7:05 PM Mar
Hi,
Thanks for working on the BPF backend!
I noticed a tiny typo while test compiling libbpf-tools[1]. (Have yet look
into the cause of failure in detail though)
On Thu, Aug 03, 2023 at 10:54:31AM +0100, Cupertino Miranda wrote:
> [snip]
> +
> +pack_type_fail:
> + bpf_error_at (EXPR_LOC_OR_
On 8/11/23 03:11, Tsukasa OI via Gcc-patches wrote:
From: Tsukasa OI
Commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
extensions") changed how do we handle unknown extensions and
commit 6f709f79c915a ("[committed] [RISC-V] Fix expected diagnostic messages
in testsuite") "fix
Tested x86_64-linux, Pushed to trunk. I'll backport this to gcc-13 too.
-- >8 --
This avoids an IndexError exception when printing invalid chrono::month
or chrono::weekday values.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdChronoCalendarPrinter):
Check for out
As promised yesterday, this reverts the part of the change I didn't mean
to commit. Tested x86_64-linux. Pushed to trunk.
-- >8 --
In commit r14-3134-g9cb2a7c8d54b1f I only meant to change some uses of
__clamp_iter_cat to use __iter_category_t, I didn't mean to commit the
additional change introd
On 8/11/23 09:54, Patrick Palka wrote:
On Thu, 10 Aug 2023, Jason Merrill wrote:
On 8/10/23 16:40, Patrick Palka wrote:
On Thu, 10 Aug 2023, Jason Merrill wrote:
On 8/10/23 12:09, Patrick Palka wrote:
Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for
trunk and perhap
On 8/11/23 03:51, Richard Biener via Gcc-patches wrote:
On Fri, Aug 11, 2023 at 11:17 AM Andrew Pinski via Gcc-patches
wrote:
So it turns out there was a simplier way of starting to
improve VRP to start to fix PR 110131, PR 108360, and PR 108397.
That was rewrite test_for_singularity to use
On Fri, 11 Aug 2023, Juzhe-Zhong wrote:
> This ICE is caused because of this situation:
>
> mask__49.21_99 = vect__17.19_96 == { 0.0, ... };
> ...
> vect__6.24_107 = .MASK_LEN_LOAD (vectp.22_105, 32B, mask__49.21_99,
> POLY_INT_CST [2, 2], 0);
>
> The MASK_LEN_LOAD is using real MASK which is p
This ICE is caused because of this situation:
mask__49.21_99 = vect__17.19_96 == { 0.0, ... };
...
vect__6.24_107 = .MASK_LEN_LOAD (vectp.22_105, 32B, mask__49.21_99,
POLY_INT_CST [2, 2], 0);
The MASK_LEN_LOAD is using real MASK which is produced by the EQ comparison
wheras the LEN
is the dummy
On Thu, 10 Aug 2023, Jason Merrill wrote:
> On 8/10/23 16:40, Patrick Palka wrote:
> > On Thu, 10 Aug 2023, Jason Merrill wrote:
> >
> > > On 8/10/23 12:09, Patrick Palka wrote:
> > > > Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > > for
> > > > trunk and perhaps 13?
Hello,
On Fri, Aug 11 2023, Christophe Lyon wrote:
> Hi Martin,
>
>
> On Fri, 4 Aug 2023 at 18:26, Martin Jambor wrote:
>
>> Hello,
>>
>> On Wed, Aug 02 2023, Richard Biener wrote:
>> > On Mon, Jul 31, 2023 at 7:05 PM Martin Jambor wrote:
>> >>
>> >> Hi,
>> >>
>> >> when IPA-SRA detects whether
On Fri, 11 Aug 2023, Richard Biener wrote:
> > I think it converts SNan to QNan (when the partial vector has just one
> > element which is SNan), so is a test for -fsignaling-nans missing?
>
> Hm, I guess that's a corner case that could happen when there's no
> runtime profitability check on mo
On 8/10/23 21:45, Palmer Dabbelt wrote:
OK, that seems like the way to go. I still think it's likely we'll need
to split up these types more, but that's something we can only deal with
when there's HW that behaves oddly.
Yea, but I think we can fault this in as problematic hardware arrive
On Fri, 11 Aug 2023, Jakub Jelinek wrote:
> All that is diagnosed is when result is bool or enum (any kind). Even for
I'd suggest tests that other nonsense cases are diagnosed, such as
floating-point or pointer arguments or results (hopefully such cases are
already diagnosed and just need test
Richard Biener writes:
> On Fri, 11 Aug 2023, juzhe.zh...@rivai.ai wrote:
>
>> Hi, Richi.
>>
>> > 1. Target is using loop MASK as the partial vector loop control.
>> >> I don't think it checks for this?
>>
>> I am not sure whether I understand EXTRACT_LAST correctly.
>> But if target doesn't use
On 8/10/23 20:12, Jin Ma wrote:
My fault, I'm very sorry for not replying to the patch follow-up, I just
forgot this :)
No worries. We're tracking it in patchwork and it also overlaps with
some work we had internally at Ventana. So it was trivial to pick it up
once it was clear it'd fall
Hi Jason,
Regarding the initialization example - no, the set of classes that we
consider cold is more loosely defined.
On Thu, Aug 10, 2023 at 11:01 PM Jason Merrill wrote:
> Yes, but that's because the implicit op== isn't declared lazily like
> some other special member functions (CLASSTYPE_LAZ
Hi Martin,
On Fri, 4 Aug 2023 at 18:26, Martin Jambor wrote:
> Hello,
>
> On Wed, Aug 02 2023, Richard Biener wrote:
> > On Mon, Jul 31, 2023 at 7:05 PM Martin Jambor wrote:
> >>
> >> Hi,
> >>
> >> when IPA-SRA detects whether a parameter passed by reference is
> >> written to, it does not spe
When we vectorize fold-left reductions with partial vectors but
no target operation available we use a vector conditional to force
excess elements to zero. But that doesn't correctly preserve
the sign of zero. The following patch disables partial vector
support when we have to do that and also ne
On Fri, 11 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> >> check here the target supports VEC_EXTRACT
> >> else set LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P to false with a
> >> diagnostic.
>
> I am wondering target has VEC_EXTRACT but no EXTRACT_LAST, and such
> target is using MASK as t
On Fri, 11 Aug 2023, Juzhe-Zhong wrote:
> This patch fixes bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110989
>
> This ICE is caused because of this situation:
>
> mask__49.21_99 = vect__17.19_96 == { 0.0, ... };
> ...
> vect__6.24_107 = .MASK_LEN_LOAD (vectp.22_105, 32B, mask__49.21_99,
On Fri, 11 Aug 2023, Alexander Monakov wrote:
>
> On Fri, 11 Aug 2023, Richard Biener wrote:
>
> > When we vectorize fold-left reductions with partial vectors but
> > no target operation available we use a vector conditional to force
> > excess elements to zero. But that doesn't correctly prese
I forgot to mention that this has been successfully regstrapped off trunk
54be338589ea93ad4ff53d22adde476a0582537b on x86_64-linux-gnu.
Is it OK for trunk ?
Thanks,
Benjamin.
This patch fixes bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110989
This ICE is caused because of this situation:
mask__49.21_99 = vect__17.19_96 == { 0.0, ... };
...
vect__6.24_107 = .MASK_LEN_LOAD (vectp.22_105, 32B, mask__49.21_99,
POLY_INT_CST [2, 2], 0);
The MASK_LEN_LOAD is using re
From: benjamin priour
This patch introduces -fanalyzer-show-events-in-system-headers,
disabled by default.
This option reduce the noise of the analyzer emitted diagnostics
when dealing with system headers.
The new option only affects the display of the diagnostics,
but doesn't hinder the actual
Richard Biener writes:
> When we vectorize fold-left reductions with partial vectors but
> no target operation available we use a vector conditional to force
> excess elements to zero. But that doesn't correctly preserve
> the sign of zero. The following patch disables partial vector
> support i
Hi, Richi.
>> check here the target supports VEC_EXTRACT
>> else set LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P to false with a
>> diagnostic.
I am wondering target has VEC_EXTRACT but no EXTRACT_LAST, and such target is
using MASK as the loop control.
It seems that it will cause ICE for such target ?
On Fri, 11 Aug 2023, Richard Biener wrote:
> When we vectorize fold-left reductions with partial vectors but
> no target operation available we use a vector conditional to force
> excess elements to zero. But that doesn't correctly preserve
> the sign of zero. The following patch disables part
On Fri, 11 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> > 1. Target is using loop MASK as the partial vector loop control.
> >> I don't think it checks for this?
>
> I am not sure whether I understand EXTRACT_LAST correctly.
> But if target doesn't use loop MASK for partial vector loop
The following makes us more correctly print the used vector size
when doing BB vectorization and also print all involved SLP graph
roots, not just the random one we ended up picking as leader.
In particular the last bit improves diffing opt-info between
different GCC revs but it also requires some
When we vectorize fold-left reductions with partial vectors but
no target operation available we use a vector conditional to force
excess elements to zero. But that doesn't correctly preserve
the sign of zero. The following patch disables partial vector
support in that case.
Bootstrap and regtes
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, August 11, 2023 6:24 PM
To: Li, Pan2 ; gcc-patches
Cc: jeffreyalaw ; Li, Pan2 ; Wang,
Yanzhang ; kito.cheng
Subject: Re: [PATCH v1] RISC-V: Support RVV VFMSUB rounding mode intrinsic API
LGTM
_
Hi, Richi.
> 1. Target is using loop MASK as the partial vector loop control.
>> I don't think it checks for this?
I am not sure whether I understand EXTRACT_LAST correctly.
But if target doesn't use loop MASK for partial vector loop control, how does
target use EXTRACT_LAST?
Since EXTRACT_LAST
Committed, thanks Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Biener via Gcc-patches
Sent: Friday, August 11, 2023 6:23 PM
To: Juzhe-Zhong
Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com
Subject: Re: [PATCH] VECT: Add vec_mask_len_{load_lanes,store_lan
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-11 18:11
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFMSUB rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API for
On Fri, 11 Aug 2023, Juzhe-Zhong wrote:
> This patch is add vec_mask_len_{load_lanes,store_stores} autovectorization
> patterns.
>
> Here we want to support this following autovectorization:
>
> #include
> void
> foo (int8_t *__restrict a,
> int8_t *__restrict b,
> int8_t *__restrict cond,
>
On Fri, 11 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> >> So how can we resolve the issue when a non-VL operation like
> >> .VEC_EXTRACT is used for _len support?
>
> Do you mean non-VL extract last operation (I am sorry that not sure whether I
> understand your question correctly)?
From: Pan Li
This patch would like to support the rounding mode API for the
VFMSUB as the below samples.
* __riscv_vfmsub_vv_f32m1_rm
* __riscv_vfmsub_vv_f32m1_rm_m
* __riscv_vfmsub_vf_f32m1_rm
* __riscv_vfmsub_vf_f32m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-v
1 - 100 of 125 matches
Mail list logo
