https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
Xi Ruoyao changed:
What|Removed |Added
Status|REOPENED|NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114505
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114505
Xi Ruoyao changed:
What|Removed |Added
Keywords||needs-reduction
--- Comment #5 from Xi Ruoy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114511
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
Xi Ruoyao changed:
What|Removed |Added
Target Milestone|--- |12.4
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #20 from Xi Ruoyao ---
(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 spec2006 on LA464 are:
> > > -falign-labels=4 -falign-f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110754
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110754
--- Comment #4 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Xi Ruoyao from comment #1)
> > Is this a bug? The standard defines accessing volatile objects as
> > side-effects so it's not allowed to merge volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110791
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110791
Xi Ruoyao changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818
Xi Ruoyao changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110789
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110789
--- Comment #9 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #7)
> If you compile GMP (MPFR and MPC) as part of GCC build rather than
> seperately, the build will do the correct thing and not use the "native"
> options by default.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110789
--- Comment #10 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #9)
> (In reply to Andrew Pinski from comment #7)
> > If you compile GMP (MPFR and MPC) as part of GCC build rather than
> > seperately, the build will do the correct thing a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110819
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818
--- Comment #9 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #8)
> (In reply to CTC from comment #7)
> > No errors or warnings raised and 0 alarms generated by the analysis when
> > analyzed by frama-c.
>
> Still undefined reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818
Xi Ruoyao changed:
What|Removed |Added
Summary|Segmentation fault with |[11 Regression]
|'-O3 -fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110845
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818
--- Comment #13 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Xi Ruoyao from comment #9)
> > https://godbolt.org/z/5vr1oPExb
> >
> > Looks like .LC0 is not aligned but GCC 11 attempts to use movdqa to load it.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818
--- Comment #14 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #12)
> Created attachment 55656 [details]
> Assembly code
>
> The only difference between GCC 9 and GCC 10 is:
> #cmpl%edx, 0
>
> GCC 10 has this line uncommented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #53 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109250
--- Comment #8 from Xi Ruoyao ---
Should be fixed with GMP 6.3.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109465
Xi Ruoyao changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110867
Xi Ruoyao changed:
What|Removed |Added
CC||panchenghui at loongson dot cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110867
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
Xi Ruoyao changed:
What|Removed |Added
Resolution|DUPLICATE |---
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111058
Bug ID: 111058
Summary: __builtin_nans (and its friends) compiles to an
external call to __builtin_nans for unsupported tag
Product: gcc
Version: 14.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111058
--- Comment #6 from Xi Ruoyao ---
(In reply to jos...@codesourcery.com from comment #5)
> We should absolutely *not* generate calls to a non-existent function
> "nans" based on a long-obsolescent standard proposal. The modern way to
> generat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111084
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111084
--- Comment #6 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #5)
> Also buildroot uses sysroots and chroot/containers instead.
>
> Containers/chroot is the better approach anyways.
We use sysroot and chroot since Linux From Scratc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
Xi Ruoyao changed:
What|Removed |Added
CC||xen0n at gentoo dot org
--- Comment #12 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
Xi Ruoyao changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed|2023-08-08 00:00:00 |2023-08-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111210
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111221
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111224
Bug ID: 111224
Summary: modules: xtreme-header-1_a.H etc. ICE (in core_vals,
at cp/module.cc:6108) on AArch64
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111224
--- Comment #1 from Xi Ruoyao ---
The stack trace in g++.log:
/home/xry111/git-repos/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-1_a.H:
internal compiler error: in core_vals, at cp/module.cc:6108
0x9563a3 trees_out::core_vals(tree_node*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111224
--- Comment #2 from Xi Ruoyao ---
It seems related to Glibc version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111224
Xi Ruoyao changed:
What|Removed |Added
Keywords|needs-reduction |ice-on-valid-code
--- Comment #3 from Xi Ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111224
Xi Ruoyao changed:
What|Removed |Added
Known to fail||11.1.0, 11.4.0, 12.3.0
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111233
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252
Bug ID: 111252
Summary: LoongArch: Suboptimal code for (a & ~mask) | (b &
mask) where mask is a constant with value ((1 << n) -
1) << m
Product: gcc
Version: 14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252
Xi Ruoyao changed:
What|Removed |Added
CC||chenglulu at loongson dot cn,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252
Xi Ruoyao changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252
--- Comment #4 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #2)
> Interesting:
> int test(int a, int b)
> {
> return (a & ~0x8000) | (b & 0x8000);
> }
>
> Produces better code:
> lu12i.w $r12,-2147483648>>12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252
--- Comment #5 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #4)
> Hmm, this seems a separate issue. The compiler knows to optimize (a & mask)
> if mask is ((1 << a) - 1) << b iff a + b = 32 or b = 0, but not for any
I mean "32 or 64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111256
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111256
--- Comment #2 from Xi Ruoyao ---
If you don't have Clang, you can also reproduce the timeout with
-ftrivial-auto-var-init=zero or -ftrivial-auto-var-init=pattern (in GCC 12 or
later).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243
--- Comment #9 from Xi Ruoyao ---
(In reply to Alex Mohr from comment #8)
> (In reply to Jonathan Wakely from comment #5)
> > A 4x slowdown isn't really acceptable IMHO. At that point, why not just use
> > -O0 instead?
>
> I've been using -O0 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243
--- Comment #11 from Xi Ruoyao ---
(In reply to Alex Mohr from comment #10)
> (In reply to Xi Ruoyao from comment #9)
> > I believe the only real issue is imprecise documentation: "It is a better
> > choice than -O0" has some caveats and it's no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111319
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252
Xi Ruoyao changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111323
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #6 from Xi Ruoyao ---
(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"
> > [(set (match_operand:DI 0 "register_operand" "=r,&r,&r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
Xi Ruoyao changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|ICE is reported dur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #9 from Xi Ruoyao ---
(In reply to chenglulu from comment #7)
> (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_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #10 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #9)
> (define_insn "di3_fake"
>[(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> - (sign_extend:DI
> - (any_div:SI (match_operand:DI 1 "register_oper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #12 from Xi Ruoyao ---
(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 "di3_fake"
> > >[(set (match_operand:DI 0 "register_o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #14 from Xi Ruoyao ---
I'm trying
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 75f641b38ee..44d9b99b2f5 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #15 from Xi Ruoyao ---
(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 from comment #10)
> > > > (In reply to Xi Ruoyao fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111336
Xi Ruoyao changed:
What|Removed |Added
Summary|Wrong code at -O2/3 since |[14 Regression] Wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111336
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #17 from Xi Ruoyao ---
I think the proper description should be:
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 75f641b38ee..000d17b0ba6 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #19 from Xi Ruoyao ---
(In reply to chenglulu from comment #18)
> This problem has been fixed on LA664．
> I don't quite understand why this operation is still needed in !TARGET_64BIT?
It's not needed with !TARGET_64BIT. I just mea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111356
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Known to wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111356
--- Comment #4 from Xi Ruoyao ---
BTW it works with 13.2.0 with "ulimit -s 131072" too, so it's a stack usage
issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111365
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111365
--- Comment #2 from Xi Ruoyao ---
int a, c, d, e = -1233286202, f = -1233286202;
...
if (l <= 0 || &c + l > &d)
I suppose this is invoking undefined behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111365
--- Comment #3 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #2)
> int a, c, d, e = -1233286202, f = -1233286202;
>
> ...
>
> if (l <= 0 || &c + l > &d)
>
> I suppose this is invoking undefined behavior.
Nope, the problematic &c + l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111365
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111383
Xi Ruoyao changed:
What|Removed |Added
Component|c |tree-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111379
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111379
--- Comment #3 from Xi Ruoyao ---
If CWG 2749 is accepted we should just close this as WONTFIX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
Bug ID: 111403
Summary: LoongArch: Wrong code with -O -mlasx -fopenmp-simd
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
Xi Ruoyao changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111405
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #11 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111424
Bug ID: 111424
Summary: LoongArch: Enable vect test suite
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111472
Xi Ruoyao changed:
What|Removed |Added
Component|c |tree-optimization
--- Comment #1 from Xi Ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111472
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|Wrong code at -Os on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716
Xi Ruoyao changed:
What|Removed |Added
Resolution|INVALID |MOVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
--- Comment #15 from Xi Ruoyao ---
(In reply to Mathieu Malaterre from comment #14)
> (In reply to Andrew Pinski from comment #13)
> > (In reply to Mathieu Malaterre from comment #12)
> > > I am seeing a difference in result (log1p computation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111569
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Xi Ruoyao changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #12 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646
--- Comment #5 from Xi Ruoyao ---
(In reply to vishwambhar.rathi from comment #4)
> I am not using any optimization flag in compiling. Where should I post about
> this bug? Thanks.
I don't know because maybe this is a Glibc issue or a QEMU issu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
--- Comment #13 from Xi Ruoyao ---
The patch is pushed. I'm running a bootstrap and I'll close this PR after it
successes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #15 f
101 - 200 of 1050 matches
Mail list logo
