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
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
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)
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
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
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:
> 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/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 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 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/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 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
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
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
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
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-
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
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
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
> 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 --
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
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
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
101 - 125 of 125 matches
Mail list logo
