Hi!
finish_struct already made sure not to call build_bitint_type for
signed _BitInt(2) : 1;
or
signed _BitInt(2) : 0;
bitfields (but instead build a zero precision integral type,
we remove it later), this patch makes sure we do it also for
unsigned _BitInt(1) : 0;
because of the build_bitint_type
Hi!
The following testcase ICEs, because group_case_labels_stmt optimizes
switch (a.0_7) [50.00%], case 0: [50.00%], case 2:
[50.00%]>
where L7 block starts with __builtin_unreachable (); to
switch (a.0_7) [50.00%]>
and single label GIMPLE_SWITCH is something the switch expansion refuses
For SPEC INT 2017, when using upstream GCC (whitout these patches), I get a
coredump when training the peak case, so no data yet. The cause of the core
dump still needs to be investigated.
Typo, SPEC INT 2017 -> SPEC FP 2017
Also There is a bad news, the score of specint 2017 (with these patches
I think it just trigger a latent bug that we didn't encounter.
Hi, Robin. Would you mind give me preprocessed file to reproduce the issue ?
I suspect it triggers latent bug in VSETVL PASS.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2024-02-05 12:36
To: Juzhe-Zhong; gcc-patches
CC: kito.cheng;
Yes, this test needs "--enable-checking=rtl" build.
On Mon, Feb 5, 2024 at 11:28 AM Jeff Law wrote:
>
>
> On 2/4/24 20:20, Monk Chiang wrote:
> > gcc/ChangeLog:
> >
> > PR target/113742
> > * config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix
> > recognizes UNSPEC_AUIPC fo
On 2/2/24 15:48, Greg McGary wrote:
On 2/1/24 10:24 PM, Jeff Law wrote:
On 2/1/24 18:24, Greg McGary wrote:
However, for a machine where (WORD_REGISTER_OPERATIONS &&
load_extend_op (inner_mode) == SIGN_EXTEND), the high part of a PSoM
is only known at runtime as 0s or 1s. That's the down
On 2/4/24 20:26, Jeff Law wrote:
On 2/1/24 18:56, Juzhe-Zhong wrote:
This patch fixes the following:
vsetvli a5,a1,e32,m1,tu,ma
slli a4,a5,2
sub a1,a1,a5
vle32.v v2,0(a0)
add a0,a0,a4
vadd.vv v1,v2,v1
bne a1,zero
Hi Mike,
on 2024/1/6 07:42, Michael Meissner wrote:
> This patch is a prelimianry patch to add the full 1,024 bit dense math
> register> (DMRs) for -mcpu=future. The MMA 512-bit accumulators map onto the
> top of the
> DMR register.
>
> This patch only adds the new 1,024 bit register support.
On 2/4/24 20:20, Monk Chiang wrote:
gcc/ChangeLog:
PR target/113742
* config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix
recognizes UNSPEC_AUIPC for RISCV_FUSE_LUI_ADDI.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr113742.c: New test.
OK. Presumably thi
On 2/1/24 18:56, Juzhe-Zhong wrote:
This patch fixes the following:
vsetvli a5,a1,e32,m1,tu,ma
sllia4,a5,2
sub a1,a1,a5
vle32.v v2,0(a0)
add a0,a0,a4
vadd.vv v1,v2,v1
bne a1,zero,.L3
vsetivlizero,1
gcc/ChangeLog:
PR target/113742
* config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix
recognizes UNSPEC_AUIPC for RISCV_FUSE_LUI_ADDI.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr113742.c: New test.
---
gcc/config/riscv/riscv.cc | 2 +-
gcc/t
pushed, thanks :)
On Fri, Feb 2, 2024 at 11:59 AM Monk Chiang wrote:
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-cores.def: Add sifive-p450, sifive-p670.
> * doc/invoke.texi (RISC-V Options): Add sifive-p450,
> sifive-p670.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.ta
pushed, thanks :)
On Fri, Feb 2, 2024 at 11:59 AM Monk Chiang wrote:
>
> Add sifive p400 series scheduler module. For more information
> see https://www.sifive.com/cores/performance-p450-470.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md: Include sifive-p400.md.
> * config/riscv/
Xi Ruoyao 于2024年2月5日周一 02:01写道:
>
> We expanded (neg x) to (minus const0 x) for MSA FP vectors, this is
> wrong because -0.0 is not 0 - 0.0. This causes some Python tests to
> fail when Python is built with MSA enabled.
>
> Use the bnegi.df instructions to simply reverse the sign bit instead.
>
>
This patch fixes PR target/113690, an ICE-on-valid regression on x86_64
that exhibits with a specific combination of command line options. The
cause is that x86's scalar-to-vector pass converts a chain of instructions
from TImode to V1TImode, but fails to appropriately update the attached
REG_EQU
On Sat, Feb 3, 2024 at 6:19 AM Takayuki 'January June' Suwa
wrote:
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.md (*eqne_zero_masked_bits):
> Add missing ":SI" to the match_operator.
> ---
> gcc/config/xtensa/xtensa.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reg
On Sun, Feb 4, 2024 at 2:20 AM Takayuki 'January June' Suwa
wrote:
>
> After LRA transition, HImode constants that don't fit into signed 12 bits
> are no longer subject to constant synthesis:
>
> /* example */
> void test(void) {
> short foo = 32767;
> __asm__ ("" :: "r"(foo));
This patch adjusts the costs so that we treat REG and SUBREG expressions
the same for costing.
This was motivated by bt_skip_func and bt_find_func in xz and results in
nearly a 5% improvement in the dynamic instruction count for input #2
and smaller, but definitely visible improvements pretty
We expanded (neg x) to (minus const0 x) for MSA FP vectors, this is
wrong because -0.0 is not 0 - 0.0. This causes some Python tests to
fail when Python is built with MSA enabled.
Use the bnegi.df instructions to simply reverse the sign bit instead.
gcc/ChangeLog:
* config/mips/mips-msa
On Sun, 2024-02-04 at 11:19 +0800, chenglulu wrote:
>
> 在 2024/2/2 下午5:55, Xi Ruoyao 写道:
> > We call loongarch_symbol_insns with mode = MAX_MACHINE_MODE sometimes.
> > But in loongarch_symbol_insns:
> >
> > if (LSX_SUPPORTED_MODE_P (mode) || LASX_SUPPORTED_MODE_P (mode))
> > return 0;
On Sun, 2024-02-04 at 11:20 +0800, chenglulu wrote:
>
> 在 2024/2/3 下午4:58, Xi Ruoyao 写道:
> > We expanded (neg x) to (minus const0 x) for LSX FP vectors, this is
> > wrong because -0.0 is not 0 - 0.0. This causes some Python tests to
> > fail when Python is built with LSX enabled.
> >
> > Use the
After LRA transition, HImode constants that don't fit into signed 12 bits
are no longer subject to constant synthesis:
/* example */
void test(void) {
short foo = 32767;
__asm__ ("" :: "r"(foo));
}
;; before
.literal_position
.literal .LC0, 32767
te
Pushed to r14-8784.
在 2024/2/2 上午9:42, Li Wei 写道:
This FAIL was introduced from r14-6908. The reason is that when merging
constant vector permutation implementations, the 128-bit matching situation
was not fully considered. In fact, the expansion of 128-bit vectors after
merging only supports va
23 matches
Mail list logo