https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120476
Bug ID: 120476
Summary: LoongArch: -mtune=la664 is pessimizing even on LA664
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471
Xi Ruoyao changed:
What|Removed |Added
Keywords||diagnostic, wrong-code
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471
--- Comment #6 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #5)
> (In reply to xiaohuba2021 from comment #4)
> > (In reply to Xi Ruoyao from comment #2)
> > > I cannot reproduce it locally, nor on godbolt:
> > > https://godbolt.org/z/r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471
Xi Ruoyao changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Xi Ruoyao ---
(In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Last reconfirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806
Xi Ruoyao changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120317
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120050
--- Comment #9 from Xi Ruoyao ---
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683277.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120050
--- Comment #6 from Xi Ruoyao ---
Before ext-dce:
(insn 421 420 422 43 (set (reg:DI 523 [ i ])
(sign_extend:DI (reg:SI 423 [ _144 ]))) 238 {extendsidi2}
(expr_list:REG_DEAD (reg:SI 423 [ _144 ])
(nil)))
(insn 440 439 441 45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120050
--- Comment #5 from Xi Ruoyao ---
Before ext-dce:
(insn 420 419 421 43 (set (reg:SI 423 [ _144 ])
(truncate:SI (reg:DI 304 [ ivtmp.55 ]))) 203 {truncdisi2}
(nil))
(insn 421 420 422 43 (set (reg:DI 523 [ i ])
(sign_extend:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120050
--- Comment #4 from Xi Ruoyao ---
As a hack I disabled ext-dce for MIPS by default:
diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index 24a28dcf817..cf4784c48bb 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120050
Xi Ruoyao changed:
What|Removed |Added
Keywords|needs-bisection |needs-reduction
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120064
Bug ID: 120064
Summary: doc: -f[no-]ext-dce not documented
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120050
Xi Ruoyao changed:
What|Removed |Added
Keywords||ice-checking
--- Comment #2 from Xi Ruoyao
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120050
--- Comment #1 from Xi Ruoyao ---
Hmm, the ICE with trunk is from gcc_checking_assert. Thus maybe the difference
between 15 and 16 comes from the different --enable-checking setting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120050
Xi Ruoyao changed:
What|Removed |Added
Target Milestone|--- |15.2
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120050
Bug ID: 120050
Summary: [15/16 Regression] Fail to bootstrap on mips64el with
--with-arch=gs464 --with-build-config=bootstrap-O3
Product: gcc
Version: 16.0
Status: UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119973
--- Comment #9 from Xi Ruoyao ---
(In reply to Sam James from comment #8)
> Why'd you close? Doesn't it affect 15 too?
Oops, I misread the 15 backport for another issue in my mail box as the fix for
this :(.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331
Bug 68331 depends on bug 119973, which changed state.
Bug 119973 Summary: [15 Regression] Wrong code at -O1 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119973
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119973
Xi Ruoyao changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119973
Xi Ruoyao changed:
What|Removed |Added
Summary|[15/16 Regression] Wrong|[15/16 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119973
Bug ID: 119973
Summary: [15/16 Regression] Wrong code at -O1 -fipa-pta -flto
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119929
Xi Ruoyao changed:
What|Removed |Added
CC||syq at gcc dot gnu.org,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118885
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118885
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=119408
--- Comment #26 from Xi Ruoyao ---
(In reply to Jakub Jelinek from comment #24)
> Maybe, but probably we need a whitelist or blacklist.
> Because e.g. powerpc64le-linux I guess wants libquadmath because it
> historically has been using it and lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #23 from Xi Ruoyao ---
(In reply to Jakub Jelinek from comment #22)
> I think for libgfortran the cleanest would be in the configure check whether
> long double is IEEE quad and if so, have libgfor_cv_have_float128 no.
> That can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #19 from Xi Ruoyao ---
(In reply to Jakub Jelinek from comment #18)
> _Float128 is definitely not for backward compatibility
Sorry, I mean __float128.
The problem here is we added __float128 as an alias of _Float128 for
compatibili
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #16 from Xi Ruoyao ---
(In reply to chenglulu from comment #15)
> (In reply to Xi Ruoyao from comment #14)
> > (In reply to chenglulu from comment #13)
> > > There is a problem now. When gcc supports both _Float128 and Q suffixes,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #17 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #16)
/* snip */
> diff --git a/libgfortran/acinclude.m4 b/libgfortran/acinclude.m4
> index a73207e5465..8913dacb2b1 100644
> --- a/libgfortran/acinclude.m4
> +++ b/libgfort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #14 from Xi Ruoyao ---
(In reply to chenglulu from comment #13)
> There is a problem now. When gcc supports both _Float128 and Q suffixes, the
> libquadmath library will be automatically linked when the fortran program is
> compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119340
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119340
--- Comment #8 from Xi Ruoyao ---
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679454.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119340
--- Comment #7 from Xi Ruoyao ---
Well, I think this is just PR116550. Before LRA:
(jump_insn 930 383 1043 73 (parallel [
(set (pc)
(if_then_else (ne (reg:DI 592 [424])
(const_int 1 [0x1]))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119340
--- Comment #6 from Xi Ruoyao ---
Created attachment 60899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60899&action=edit
my reduction
My reduction is different:
https://godbolt.org/z/GGc987xMY
It obviously invokes undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #9 from Xi Ruoyao ---
Ok for a backport into the 14 branch (where __float128 has been added)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119429
Xi Ruoyao changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #24 from Xi Ruoyao ---
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119340
Xi Ruoyao changed:
What|Removed |Added
Known to fail||14.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119340
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119340
--- Comment #4 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #3)
> (In reply to Sam James from comment #2)
> > Created attachment 60797 [details]
> > reduced.i
>
> Hmm strangely I cannot reproduce the ICE with the reduced test case.
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119340
--- Comment #3 from Xi Ruoyao ---
(In reply to Sam James from comment #2)
> Created attachment 60797 [details]
> reduced.i
Hmm strangely I cannot reproduce the ICE with the reduced test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119429
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #21 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
Xi Ruoyao changed:
What|Removed |Added
Target Milestone|--- |14.3
--- Comment #5 from Xi Ruoyao ---
(In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119353
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117452
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=114978
--- Comment #39 from Xi Ruoyao ---
(In reply to Chen Chen from comment #38)
> (In reply to Xi Ruoyao from comment #37)
> > So if we revert r15-7525 now, would things work normally with just r15-6657?
> > If so I'd suggest to revert r15-7525 (now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
Xi Ruoyao changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119213
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=114978
--- Comment #32 from Xi Ruoyao ---
Or perhaps you can run a bisect. Unfortunately I don't have SPEC access.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #29 from Xi Ruoyao ---
For 15 r15-7525 is intended for this issue. But I don't know if it's a good
idea to backport it, as it's only a workaround, not a proper fix.
Could someone try the diff in PR 115842 comment 6 (one time just o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119253
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=119238
Xi Ruoyao changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119238
--- Comment #3 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #2)
> Oops I mistakenly believed the C++ standard for GCC code base was same as
> the default of GCC.
>
> I agree with the fix in comment 1.
Just thought it again and submit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119238
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Summar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
--- Comment #4 from Xi Ruoyao ---
(In reply to Richard Biener from comment #3)
> Nah, cobol isn't a primary or default language.
Oh I wrongly thought it was enabled by default.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119171
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=7826
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #9 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
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=119186
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
--- Comment #6 from Xi Ruoyao ---
(In reply to Uroš Platiše from comment #5)
> My assumption was that the object is anyway in the regs and the mere issue
> would be accessing its value.
You assumption is incorrect as I've already said. It's j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
--- Comment #4 from Xi Ruoyao ---
(In reply to Jonathan Wakely from comment #2)
> What if the function is not called indirectly, wouldn't the implicit object
> ref just be garbage?
>
> My response to this is "just use C++". Then you have functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119184
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |WONTFIX
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119127
Xi Ruoyao changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119182
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=119180
--- Comment #2 from Xi Ruoyao ---
> Actual Result:
> GCC compiles the code silently (or with -pedantic warns but still succeeds).
"Warns but still succeeds" is a correct behavior.
The standard NEVER says "the code should be rejected." It only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119180
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
Xi Ruoyao changed:
What|Removed |Added
CC||qurong at ios dot ac.cn
--- Comment #26 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119084
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119127
--- Comment #6 from Xi Ruoyao ---
More simplified test case:
int x;
struct Type {
unsigned SubclassData : 24;
} y;
void test(void) {
x = y.SubclassData * 37;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119127
--- Comment #5 from Xi Ruoyao ---
(In reply to chenglulu from comment #4)
> (In reply to Xi Ruoyao from comment #3)
> > It happens at:
> >
> > trying to combine definition of r94 in:
> >15: r94:DI=r92:DI<<0x2&0xfffc
> > REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119127
--- Comment #3 from Xi Ruoyao ---
It happens at:
trying to combine definition of r94 in:
15: r94:DI=r92:DI<<0x2&0xfffc
REG_DEAD r92:DI
into:
17: r96:DI=sign_extend(r87:SI+r94:DI#0)
REG_DEAD r94:DI
REG_DEAD r87:SI
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119127
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119089
--- Comment #14 from Xi Ruoyao ---
(In reply to John David Anglin from comment #13)
> Debian doesn't ship fixed pthread.h but they are in my personal
> builds. I will probably remove fixed pthread.h from my personal
> builds.
Or use --disable-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119095
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=119089
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=119084
--- Comment #6 from Xi Ruoyao ---
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/676725.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119084
Xi Ruoyao changed:
What|Removed |Added
See Also||https://github.com/cisco/op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
Xi Ruoyao changed:
What|Removed |Added
Summary|RISC-V: Mis-optimized code |RISC-V: Miss optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119084
Xi Ruoyao changed:
What|Removed |Added
Attachment #60632|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119084
--- Comment #2 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #1)
> Created attachment 60632 [details]
> untested patch
It causes an ICE with
V16QI y = __builtin_lsx_vldx ((char *)0, t);
I'll fix it before sending the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119084
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119084
Xi Ruoyao changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119084
Bug ID: 119084
Summary: LoongArch: __builtin_lsx_vldx can be incorrectly
reordered
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119077
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=119013
--- Comment #2 from Xi Ruoyao ---
(In reply to Jeffrey A. Law from comment #1)
> The way we typically deal with these issues with rv64 is to create a DImode
> temporary and store the result in there. We then use a narrowing subreg to
> copy fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119028
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119013
Bug ID: 119013
Summary: LoongArch and RISC-V: Redundant sign-extension after
moving 32-bit values from FPR into 64-bit GPR
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118997
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=118981
--- Comment #41 from Xi Ruoyao ---
So fixed? Or should we reject the code if it uses init_priority(99) and
-fvtable-verify at the same time?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Xi Ruoyao changed:
What|Removed |Added
Keywords||needs-reduction
--- Comment #29 from Xi Ruo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Xi Ruoyao changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #23 from Xi Ruoyao ---
I just tried bootstrapping GCC and I couldn't reproduce the failure. The
output assembly seems normal regarding _GLOBAL__sub_I.00099_tzdb.cc:
.section.text.startup._GLOBAL__sub_I.00099_tzdb.cc,"ax",@p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #21 from Xi Ruoyao ---
(In reply to Erich Löw from comment #16)
> In parallel: how did I come to "CCFLAGS=-pipe -march=native -O2 -fPIC
> -fomit-frame-pointer"?
> --> They are from linux kernel compiling
This is not correct. The cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Xi Ruoyao changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
1 - 100 of 1050 matches
Mail list logo
