On Mon, 20 Jan 2025, Soumya AR wrote:
> This patch fixes the ICE caused when comparing log or exp of a constant with
> another constant.
>
> The transform is now restricted to cases where the resultant
> log/exp (CST) can be constant folded.
OK.
Richard.
> Signed-off-by: Soumya AR
>
> gcc/Ch
On Mon, 20 Jan 2025, Hongyu Wang wrote:
> Thanks Richard for willing to review this part, it is true that the
> try_cmove_arith logic adds quite a lot of special handling for
> optimization, so I reduce the logic in emit_mask_load_store to just
> generate most simple load/store that does not allow
On Fri, 17 Jan 2025, Philipp Tomsich wrote:
> Folks,
>
> we'd appreciate it if someone could take the time to review this fix
> for PR116845.
>
> Thanks,
> Philipp.
>
>
>
> On Tue, 31 Dec 2024 at 10:03, Konstantinos Eleftheriou
> wrote:
> >
> > From: kelefth
> >
> > `(A * B) + (-C) to (B -
> sparc added a -mvis3b option, but the sparc.opt.url file wasn't
> regenerated.
>
> Fixes: d309844d6fe0 ("Fix bootstrap failure on SPARC with -O3
> -mcpu=niagara4")
Thanks, but how is one supposed to detect this? Everything worked fine.
--
Eric Botcazou
sifive_vector.h is a vendor specfic header, it should include before
using sifive vector intrinsic, it's just include riscv_vector.h for now,
we will separate the implementation by adding new pragma in future.
gcc/ChangeLog:
* config.gcc (riscv*): Install sifive_vector.h.
* config
For XTheadCondMov, the bit width of rs2 should always be XLEN-sized, otherwise
the program logic will be wrong.
Reference form
https://github.com/XUANTIE-RV/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf
Synopsis
Move if equal zero.
Mnemonic
th.mveqz rd, rs1, rs2
Descr
While fixing PR target/117665, I had noticed that fold_marked_statements
would not purge the abnormal edges which could not be taken any more due
to folding a call (devirtualization or simplification of a [target] builtin).
Devirutalization could also cause a call that used to be able to have an
ab
> > diff --git a/gcc/testsuite/gcc.target/riscv/xtheadcondmov-bug.c
> > b/gcc/testsuite/gcc.target/riscv/xtheadcondmov-bug.c
> > new file mode 100644
> > index ..33658b863514
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/riscv/xtheadcondmov-bug.c
> > @@ -0,0 +1,12 @@
> > +/* { d
This patch fixes the ICE caused when comparing log or exp of a constant with
another constant.
The transform is now restricted to cases where the resultant
log/exp (CST) can be constant folded.
Signed-off-by: Soumya AR
gcc/ChangeLog:
PR target/118490
* match.pd: Added ! to verify that log/exp
LGTM!
Thanks!
在 2025/1/18 下午7:33, Xi Ruoyao 写道:
For bstrins, we can merge it into and3 instead of having a
separate define_insn.
For bstrpick, we can use the constraints to ensure the first source
register and the destination register are the same hardware register,
instead of emitting a move
For mask{eq,ne}z, rk is always compared with 0 in the full width, thus
the mode for rk should be X.
I found the issue reviewing a patch fixing a similar issue for RISC-V
XTheadCondMov [1], but interestingly I cannot find a test case really
blowing up on LoongArch. But as the issue is obvious enou
Thanks Richard for willing to review this part, it is true that the
try_cmove_arith logic adds quite a lot of special handling for
optimization, so I reduce the logic in emit_mask_load_store to just
generate most simple load/store that does not allow sources to be
swapped.
Hi Jeff, would you help
> -Original Message-
> From: Michael Matz
> Sent: Wednesday, January 15, 2025 09:50
> To: Robert Dubner
> Cc: Richard Biener ; jklow...@symas.com; Joseph Myers
> ; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] COBOL 3/8 gen: GENERIC interface
>
> Hello,
>
> On Mon, 23 Dec 2024, Robe
All:
Thank you all for looking at this - there are a large number of moving parts
and I could
easily be making incorrect assumptions. FWIW the highest weighting in the
inputs I have
are given to DDI0487L_a_a-profile and the query output from the actual desktops.
-
Please note that the Dar
On 2025-01-19 21:20, Andrew Pinski wrote:
On Sun, Jan 19, 2025 at 12:17 PM Torbjörn SVENSSON
wrote:
Ok for trunk?
--
Most baremetal toolchains will not have an implementation for alarm and
sigaction as they are target specific.
For arm-none-eabi with newlib, function signatures are expose
Dear all,
this patch addresses a long-standing difference between gfortran and
other brands: when an array actual argument was passed to a procedure,
and the dummy argument had no intent specified, we would often create
packing and unpacking code. Only the case of the dummy argument
having inten
On Sun, Jan 19, 2025 at 12:17 PM Torbjörn SVENSSON
wrote:
>
> Ok for trunk?
>
> --
>
> Most baremetal toolchains will not have an implementation for alarm and
> sigaction as they are target specific.
> For arm-none-eabi with newlib, function signatures are exposed, but
> there is no implmentation
Ok for trunk?
--
Most baremetal toolchains will not have an implementation for alarm and
sigaction as they are target specific.
For arm-none-eabi with newlib, function signatures are exposed, but
there is no implmentation and thus the test cases causes a undefined
symbol link error.
gcc/testsuit
On Fri, Jan 17, 2025 at 10:01 PM Vladimir Makarov wrote:
>
> This is one more patch to solve
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
>
> with different -mcpu used.
>
> The patch was successfully bootstrapped and tested on x86-64, aarch64, and
> ppc64le.
I have committed a small t
sparc added a -mvis3b option, but the sparc.opt.url file wasn't
regenerated.
Fixes: d309844d6fe0 ("Fix bootstrap failure on SPARC with -O3 -mcpu=niagara4")
gcc/ChangeLog:
* config/sparc/sparc.opt.urls: Regenerated.
---
gcc/config/sparc/sparc.opt.urls | 3 +++
1 file changed, 3 insertion
Ok for trunk?
--
Using -std=c17 avoids excess errors like:
.../thumb-bitfld1.c:15:1: warning: old-style function definition
[-Wold-style-definition]
gcc/testsuite/ChangeLog:
* gcc.target/arm/thumb-bitfld1.c: Use -std=c17.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.target
Hi,
the attached patch fixes PR118185 (mentioned in the earlier thread about
118160). Tested on x86-64 Linux.
Thanks,
--
Giuseppe D'Angelo
From 9c61058809ac091335a5e73ad8080d8310e9942e Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo
Date: Sun, 19 Jan 2025 16:30:20 +0100
Subject: [PATCH] libs
On Sun, 29 Dec 2024, Jonathan Wakely wrote:
> On Sun, 29 Dec 2024, 13:55 Gerald Pfeifer wrote:
>> something tells me this is not the full extent of this issue. Something
>> to dig into when I find more time.
> I think the explanation for this is simple, and not likely to be part of a
> bigger issu
Hi Gerald,
On Tue, Dec 17, 2024 at 04:40:10PM +0900, Gerald Pfeifer wrote:
> On Mon, 2 Dec 2024, Mark Wielaard wrote:
> > Adjust the DCO text to match the broader community usage and
> > clarifications around the use of real names, known identities and
> > (anonymous) pseudonyms.
> >
> > These ch
zce must imply zcf but this rule was corrupted after
refactoring in this commit:
9e12010b5e724277ea44c300630802f464407d8d
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: fix zce to zcf
implication.
Signed-off-by: Yuriy Kolerov
---
gcc/common/config/riscv/riscv-common.cc
gcc/ChangeLog:
* config/riscv/riscv.md: Change 'r' to 'p'.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/prefetch-zicbop-ice.c: New test.
---
gcc/config/riscv/riscv.md| 2 +-
gcc/testsuite/gcc.target/riscv/prefetch-zicbop-ice.c | 9 +
2 files ch
On Sun, 2025-01-19 at 20:42 +0800, Jin Ma wrote:
/* snip */
> diff --git a/gcc/testsuite/gcc.target/riscv/xtheadcondmov-bug.c
> b/gcc/testsuite/gcc.target/riscv/xtheadcondmov-bug.c
> new file mode 100644
> index ..33658b863514
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/xt
On Sun, Jan 19, 2025 at 02:27:32PM +0200, Dimitar Dimitrov wrote:
> Shouldn't the two "calloc" arguments be multiplied here, instead of
> added?
Yes, will fix tomorrow.
Jakub
For XTheadCondMov, the bit width of rs2 should always be XLEN-sized, otherwise
the program logic will be wrong.
Reference form
https://github.com/XUANTIE-RV/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf
Synopsis
Move if equal zero.
Mnemonic
th.mveqz rd, rs1, rs2
Descr
On Fri, Jan 03, 2025 at 10:46:18PM +0100, Jakub Jelinek wrote:
> Hi!
>
> As suggested by Richi in the PR, the following patch will fail to DCE
> allocation calls if they have constant size which is too large (over
> PTRDIFF_MAX), or for the case of calloc, if either of the arguments
> is too large
> On 1/17/25 7:37 AM, Jin Ma wrote:
> >>> Since the parameter vl of XTheadVector does not support immediate
> >>> numbers, we need
> >>> to put it in the register in advance. That generates the initial code
> >>> correctly.
> >>>
> >>> PR 116593
> >>>
> >>> gcc/ChangeLog:
> >>>
> >>> * config
Although we have handled the vl of XTheadVector correctly in the
expand phase and predicates, the results show that the work is
still insufficient.
In the curr_insn_transform function, the insn is transformed from:
(insn 69 67 225 12 (set (mem:RVVM8SF (reg/f:DI 218 [ _77 ]) [0 S[128, 128]
A32])
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
When looking at PR c++/118513 I noticed that we don't currently check
the linkage of structured binding declarations in modules. This patch
adds those checks, and corrects decl_linkage to properly recognise
structured bind
On Sat, Jan 18, 2025 at 07:06:16PM +, Sam James wrote:
> Dimitar Dimitrov writes:
>
> > This test fails on AVR.
> >
> > Debugging the test on x86 host, I noticed that u in function s sometimes
> > has value 16128. The "t <= 3 * u" expression in the same function
> > results in signed integer
34 matches
Mail list logo
