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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #45 from Xi Ruoyao ---
(In reply to Luke Dalessandro from comment #44)
> Now that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 was resolved is
> it possible to actually get the atomic/atomic_ref to generate cmpxchg16b? Or
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
--- Comment #9 from Xi Ruoyao ---
(In reply to Jerry DeLisle from comment #7)
> More importantly I dont believe it is legitimate to run fortran IO in a
> libgomp environment at all. It was and is not designed to run omp_parallel.
> The fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
See Als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118918
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=118925
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=118935
--- Comment #5 from Xi Ruoyao ---
I guess we have a race condition here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118326
Xi Ruoyao changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96570
--- Comment #13 from Xi Ruoyao ---
(In reply to Bernhard M. Wiedemann from comment #12)
> @Xi: that is a cast from time_t to int, but I want a warning for conversion
> from int to time_t
>
> And IMHO we don't have to force warnings for explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118908
--- Comment #4 from Xi Ruoyao ---
The standard library has no obligation to make it "predictable" except it must
be available with #include .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118908
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118877
Bug ID: 118877
Summary: -Wstringop-overread in gcc/attribs.cc with -O3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118843
--- Comment #4 from Xi Ruoyao ---
(In reply to chenglulu from comment #3)
> I tried to make some changes, and the test went smoothly without any issues.
> for (int i = 0; i < N_EVO_FEATURES; i++)
> {
> builtin_undef (la_evo_macro_na
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118843
--- Comment #2 from Xi Ruoyao ---
We have
if (TARGET_HARD_FLOAT && ISA_HAS_FRECIPE)
builtin_define ("__loongarch_frecipe");
where the logic seems correct. But __loongarch_frecipe is also in
la_evo_macro_name and it can get defined by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84918
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #10 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118834
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=118828
Bug ID: 118828
Summary: LoongArch: #pragma GCC target should update
__loongarch_asx and similar macros
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478
--- Comment #9 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #8)
> For LoongArch we also have a fallout:
>
> __int128 test(__int128 a)
> {
> return a << 16;
> }
>
> is now
>
> srli.d $r12,$r4,48
> slli.d $r5,$r5,16
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478
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=118817
Xi Ruoyao changed:
What|Removed |Added
Blocks||56456
--- Comment #3 from Xi Ruoyao ---
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118817
Xi Ruoyao changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118817
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767
--- Comment #22 from Xi Ruoyao ---
Maybe it's worthy to try the new LLVM TBAA sanitizer for this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806
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=118777
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #2 fr
1 - 100 of 1026 matches
Mail list logo
