https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110484
chenglulu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #16 from chenglulu ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to chenglulu from comment #13)
> > (In reply to Xi Ruoyao from comment #12)
> > > (In reply to chenglulu from comment #11)
> > > > (In reply to Xi Ruoyao
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #1 from chenglulu ---
$ gcc test.c -o - -S -O1
test.c: 在函数‘add_startpgm’中:
test.c:33:1: 编译器内部错误：在 simplify_subreg 中，于 simplify-rtx.cc:7538
33 | }
| ^
0x13506f4 simplify_context::simplify_subreg(machine_mode, rtx_def*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #2 from chenglulu ---
This problem occurred after adding the r14-3511 optimization.
However, during the debugging process, it was discovered that it was due to the
attempt to generate rtx during the combine pass optimization.
(set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #3 from chenglulu ---
This involves the template di3_fake:
(define_insn "di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,,")
(sign_extend:DI
(any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #7 from chenglulu ---
(In reply to Xi Ruoyao from comment #6)
> (In reply to Xi Ruoyao from comment #5)
> > (In reply to chenglulu from comment #3)
> > > This involves the template di3_fake:
> > > (define_insn "di3_fake"
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #8 from chenglulu ---
(In reply to Andrew Pinski from comment #4)
> (In reply to chenglulu from comment #3)
> > This involves the template di3_fake:
> > (define_insn "di3_fake"
> > [(set (match_operand:DI 0 "register_operand"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
Bug ID: 111334
Summary: ICE is reported during the combine pass optimization
Product: gcc
Version: rust/master
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #18 from chenglulu ---
(In reply to Xi Ruoyao from comment #17)
> I think the proper description should be:
>
> diff --git a/gcc/config/loongarch/loongarch.md
> b/gcc/config/loongarch/loongarch.md
> index 75f641b38ee..000d17b0ba6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
chenglulu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #11 from chenglulu ---
(In reply to Xi Ruoyao from comment #10)
> (In reply to Xi Ruoyao from comment #9)
>
> > (define_insn "di3_fake"
> >[(set (match_operand:DI 0 "register_operand" "=r,,")
> > - (sign_extend:DI
> > -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #13 from chenglulu ---
(In reply to Xi Ruoyao from comment #12)
> (In reply to chenglulu from comment #11)
> > (In reply to Xi Ruoyao from comment #10)
> > > (In reply to Xi Ruoyao from comment #9)
> > >
> > > > (define_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
--- Comment #7 from chenglulu ---
(In reply to Xi Ruoyao from comment #6)
> (In reply to chenglulu from comment #5)
> > (In reply to Xi Ruoyao from comment #4)
> > > (In reply to chenglulu from comment #3)
> > > > (In reply to Xi Ruoyao from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
--- Comment #3 from chenglulu ---
(In reply to Xi Ruoyao from comment #1)
> (In reply to Xi Ruoyao from comment #0)
>
> > I guess the easiest solution is raising the minimal GAS requirement of
> > bootstrapping GCC 14 on LoongArch to 2.42.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
--- Comment #5 from chenglulu ---
(In reply to Xi Ruoyao from comment #4)
> (In reply to chenglulu from comment #3)
> > (In reply to Xi Ruoyao from comment #1)
> > > (In reply to Xi Ruoyao from comment #0)
> > >
> > > > I guess the easiest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
--- Comment #14 from chenglulu ---
(In reply to Xi Ruoyao from comment #13)
> (In reply to chenglulu from comment #12)
> > (In reply to Xi Ruoyao from comment #11)
> > > I cherry-picked f87cf663af71e5d78c8d647fa48562102f3b0615 for Binutils 2.41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
--- Comment #10 from chenglulu ---
(In reply to Xi Ruoyao from comment #9)
> Xuerui informed me that non-LTO bootstrapping is broken too.
Well, this has nothing to do with whether to open lto or not, it is caused by
binutils inserting "nop"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
--- Comment #12 from chenglulu ---
(In reply to Xi Ruoyao from comment #11)
> I cherry-picked f87cf663af71e5d78c8d647fa48562102f3b0615 for Binutils 2.41
> and get some better error message:
>
> t.s:98064: Error: Reloc overflow
> t.s:101127:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112286
chenglulu changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112286
--- Comment #4 from chenglulu ---
(In reply to Xi Ruoyao from comment #2)
> (In reply to chenglulu from comment #1)
> > (In reply to Robin Lee from comment #0)
> > > Follow-up from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682#c2
> > >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112286
--- Comment #6 from chenglulu ---
(In reply to Xi Ruoyao from comment #5)
> (In reply to chenglulu from comment #4)
> > (In reply to Xi Ruoyao from comment #2)
> > > (In reply to chenglulu from comment #1)
> > > > (In reply to Robin Lee from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105514
chenglulu changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from chenglulu ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097
--- Comment #6 from chenglulu ---
Created attachment 53205
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53205=edit
0001-Fix-bug-for-PR16097.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097
--- Comment #8 from chenglulu ---
> You can reuse LU32I_B and LU52I_B instead of hard coding those long
> constants :).
I have fixed it, thanks！:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097
--- Comment #9 from chenglulu ---
Created attachment 53206
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53206=edit
use LU52I_B and LU32I_B instead of hard coding those long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096
--- Comment #5 from chenglulu ---
Created attachment 53213
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53213=edit
Modify the allocation order of caller saved registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097
--- Comment #11 from chenglulu ---
> Otherwise LGTM. As the port maintainer you can push it directly into
> master. Normally we should bootstrap and regtest before applying a patch,
> but currently the bootstrap is blocked by PR106096 :(.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096
--- Comment #8 from chenglulu ---
(In reply to Xi Ruoyao from comment #6)
> (In reply to chenglulu from comment #5)
> > Created attachment 53213 [details]
> > Modify the allocation order of caller saved registers.
>
> I think we need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096
--- Comment #10 from chenglulu ---
(In reply to Xi Ruoyao from comment #9)
> Created attachment 53214 [details]
> patch removing r13 from SIBCALL_REGS
>
> I'm testing this patch now.
>
> I suggest to apply this for trunk and gcc-12 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097
--- Comment #1 from chenglulu ---
How can I reproduce the problem?
Thanks!
Lulu Cheng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105514
Bug ID: 105514
Summary: rv64 qsort gets wrong result when '-O2 -DDEBUG'.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105514
--- Comment #2 from chenglulu ---
(In reply to Andrew Pinski from comment #1)
> Just looking at the code, there seems to be some aliasing violations going
> on which is causing the problem.
>
> Sometimes accessing via unsigned long and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107713
--- Comment #7 from chenglulu ---
(In reply to Xi Ruoyao from comment #6)
> Fixed for trunk. Should we backport it to gcc-12 branch too?
I don't know what the problem is, I always fail when I backport.
If it is convenient for you, could you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107713
--- Comment #10 from chenglulu ---
(In reply to Xi Ruoyao from comment #9)
> Fixed for gcc-12 too.
Thanks! ^v^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731
--- Comment #7 from chenglulu ---
(In reply to Andrew Pinski from comment #3)
> MIPS nor RISCV does not define a %c either.
These two architectures can also fail under the following conditions:
void
test(void)
{
asm (".long %c0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731
--- Comment #6 from chenglulu ---
(In reply to Andrew Pinski from comment #1)
> %c does not mean anything in loongarch.
>
> The codes are not documented in the documentation for loonarch though but
> they currently only documented in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731
Bug ID: 107731
Summary: error: invalid 'asm': invalid use of '%c'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731
chenglulu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107453
chenglulu changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109035
chenglulu changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109035
--- Comment #4 from chenglulu ---
(In reply to Xi Ruoyao from comment #3)
> I don't really understand why we should prefer the memory if there is a
> REG_EQUIV note, nor why this does not happen with -fPIE.
I didn't understand the optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109035
--- Comment #5 from chenglulu ---
On AARCH64:
$cat t.c
int test(int x)
{
char buf[128 << 10];
return buf[x];
}
$cat t-1.c
int test(int x)
{
char buf[0xfff];
return buf[x];
}
The generated assemblies are as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109035
--- Comment #6 from chenglulu ---
I tried changing the code,
diff --git a/gcc/lra-eliminations.cc b/gcc/lra-eliminations.cc
index 4220639..efaea6922b5 100644
--- a/gcc/lra-eliminations.cc
+++ b/gcc/lra-eliminations.cc
@@ -914,6 +914,11 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #16 from chenglulu ---
(In reply to rguent...@suse.de from comment #15)
> On Thu, 13 Apr 2023, xry111 at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
> >
> > --- Comment #14 from Xi Ruoyao ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #19 from chenglulu ---
(In reply to Xi Ruoyao from comment #18)
> (In reply to Richard Biener from comment #17)
> > Isn't this the same issue as seen in another bug, most targets defining
> > TARGET_PROMOTE_PROTOTYPES to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192
--- Comment #15 from chenglulu ---
(In reply to Andrew Macleod from comment #14)
> The upcoming patch for 109274 should resolve this.
The problem has been solved. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192
--- Comment #13 from chenglulu ---
(In reply to CVS Commits from comment #9)
> The master branch has been updated by Andrew Macleod :
>
> https://gcc.gnu.org/g:0963cb5fde158cce986523a90fa9edc51c881f31
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192
chenglulu changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #12 from chenglulu ---
(In reply to Xi Ruoyao from comment #11)
> (In reply to chenglulu from comment #10)
> > (In reply to Xi Ruoyao from comment #5)
> > > The test fails on loongarch64-linux-gnu. foo is kept in 114t.threadfull1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #10 from chenglulu ---
(In reply to Xi Ruoyao from comment #5)
> The test fails on loongarch64-linux-gnu. foo is kept in 114t.threadfull1,
> but removed in 135t.forwprop3.
>
> Does this mean something is wrong for LoongArch, or we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110136
chenglulu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110136
Bug ID: 110136
Summary: After optimization, the $r1 register will be broken
when jumping to the jump table, resulting in a
significant increase in the false prediction rate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110136
--- Comment #3 from chenglulu ---
(In reply to Andrew Pinski from comment #1)
> >In the regrename passover optimization
>
> I am trying to understand the issue.
>
> 5912 ldx.d $r20,$r16,$r19
> 5913 add.d $r1,$r16,$r20
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110136
--- Comment #4 from chenglulu ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > >In the regrename passover optimization
> >
> > I am trying to understand the issue.
> >
> > 5912 ldx.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110484
--- Comment #1 from chenglulu ---
The following code modification problem can be solved：
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1112,7 +1112,9 @@ loongarch_first_stack_step (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110484
Bug ID: 110484
Summary: Spec2017 541 after adding the
'-flto-fomit-frame-pointer' optimization, after
optimizing the rnreg, directly replaced other
registers with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112985
--- Comment #1 from chenglulu ---
(In reply to Xi Ruoyao from comment #0)
> /* { dg-do compile } */
> /* { dg-options "-O2 -ffast-math -fdump-tree-gimple" } */
>
> int
> short_circuit (float *a)
> {
> float t1x = a[0];
> float t2x = a[1];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #5 from chenglulu ---
(In reply to Xi Ruoyao from comment #4)
> Lulu: can you help to run some other benchmarks like SPEC (I don't have an
> access to it) and update these values for LA464 and LA664?
No problem, this is what I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #6 from chenglulu ---
Hi，Ruoyao:
I am testing the spec2006 scores when the parameters 'align-loops',
'align-jumps', 'align-functions', and 'align-labels' are '1', '8', '16', and
'32' respectively.
However, the test was suspended due
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113626
Bug ID: 113626
Summary: The r14-8450 commit causes the loongarch
[x]vfcmp-{d/f}.c test case to fail
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #8 from chenglulu ---
(In reply to Xi Ruoyao from comment #7)
> Any update? :)
Well, I haven't run it yet. Since this does not have a big impact on the spec
score, I am currently testing it on a single-channel machine, so the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112578
--- Comment #2 from chenglulu ---
(In reply to Xi Ruoyao from comment #1)
> I've made a patch and it's under testing.
>
> I've seen some "random" gcc.dg/torture/builtin-fp-int-inexact.c failures
> recently but maybe it's not related, we don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #10 from chenglulu ---
(In reply to Xi Ruoyao from comment #9)
> (In reply to chenglulu from comment #8)
> > (In reply to Xi Ruoyao from comment #7)
> > > Any update? :)
> >
> > Well, I haven't run it yet. Since this does not have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #12 from chenglulu ---
(In reply to Xi Ruoyao from comment #11)
> (In reply to chenglulu from comment #10)
> > (In reply to Xi Ruoyao from comment #9)
> > > (In reply to chenglulu from comment #8)
> > > > (In reply to Xi Ruoyao from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #16 from chenglulu ---
(In reply to Xi Ruoyao from comment #15)
> > Hi，Ruoyao:
> >
> > The results of spec2006 on 3A6000 were obtained, I removed the more
> > volatile
> > test items, '-falign-loops=8 -falign-functions=8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #13 from chenglulu ---
(In reply to Xi Ruoyao from comment #9)
> (In reply to chenglulu from comment #8)
> > (In reply to Xi Ruoyao from comment #7)
> > > Any update? :)
> >
> > Well, I haven't run it yet. Since this does not have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #14 from chenglulu ---
(In reply to chenglulu from comment #13)
> (In reply to Xi Ruoyao from comment #9)
> > (In reply to chenglulu from comment #8)
> > > (In reply to Xi Ruoyao from comment #7)
> > > > Any update? :)
> > >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #17 from chenglulu ---
(In reply to Xi Ruoyao from comment #15)
> > Hi，Ruoyao:
> >
> > The results of spec2006 on 3A6000 were obtained, I removed the more
> > volatile
> > test items, '-falign-loops=8 -falign-functions=8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
chenglulu changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #21 from chenglulu ---
(In reply to Xi Ruoyao from comment #20)
> (In reply to chenglulu from comment #19)
> > (In reply to Xi Ruoyao from comment #18)
> > > (In reply to chenglulu from comment #17)
> > >
> > > > The results of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #19 from chenglulu ---
(In reply to Xi Ruoyao from comment #18)
> (In reply to chenglulu from comment #17)
>
> > The results of spec2006 on LA464 are:
> > -falign-labels=4 -falign-functions=32 -falign-loops=16 -falign-jumps=16
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
chenglulu changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848
--- Comment #5 from chenglulu ---
(In reply to Xi Ruoyao from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > (In reply to Xi Ruoyao from comment #1)
> > > Hmm, AFAIK this should be already fixed with r14-6440?
> > >
> > > I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #10 from chenglulu ---
(In reply to Xi Ruoyao from comment #9)
> (In reply to chenglulu from comment #8)
>
> > diff --git a/gcc/config/loongarch/loongarch-def.cc
> > b/gcc/config/loongarch/loongarch-def.cc
> > index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #8 from chenglulu ---
(In reply to Chen Chen from comment #0)
> We tested Loongarch64 CPU Loongson 3A6000 with "LA664" architecture in Linux
> operating system AOSC OS 11.4.0 (default gcc version is 13.2.0). And we
> found the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #11 from chenglulu ---
(In reply to Chen Chen from comment #0)
> We tested Loongarch64 CPU Loongson 3A6000 with "LA664" architecture in Linux
> operating system AOSC OS 11.4.0 (default gcc version is 13.2.0). And we
> found the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #15 from chenglulu ---
(In reply to Chen Chen from comment #14)
> (In reply to Xi Ruoyao from comment #13)
> > (In reply to Chen Chen from comment #12)
> >
> > > No. I used system default gcc.
> >
> > AOSC backports *many* changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #5 from chenglulu ---
I will verify it on multiple machines to see if the problem can be reproduced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #16 from chenglulu ---
The performance degradation on LoongArch is caused by one commit：
commit e0e9499aeffdaca88f0f29334384aa5f710a81a4 (HEAD -> trunk)
Author: Richard Biener
Date: Tue Mar 19 12:24:08 2024 +0100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #18 from chenglulu ---
(In reply to Xi Ruoyao from comment #17)
> Strangely PR114074 is a wrong-code (instead of missed-optimization) and
> reverting its fix seems improving performance for other targets...
This is very strange. I
80 matches
Mail list logo
