https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107374
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107048
Xi Ruoyao changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356
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=109357
Xi Ruoyao changed:
What|Removed |Added
Target Milestone|--- |12.3
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109368
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109190
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=109356
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed||2023-04-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109405
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |WONTFIX
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109418
--- Comment #1 from Xi Ruoyao ---
(In reply to Gareth Anthony Hulse from comment #0)
> Created attachment 54812 [details]
> Output of `make -B 2> /tmp/errors.txt`
>
> `/usr/include/c++/12.2.1/bits/random.tcc` has variables that are possibly
> u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109418
Xi Ruoyao changed:
What|Removed |Added
Keywords|easyhack|
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426
--- Comment #5 from Xi Ruoyao ---
(In reply to Jonathan Wakely from comment #4)
> N.B. this code is just copied from PR 54402. It might have been helpful to
> say where you found the code.
>
> zhonghao, it's really not helpful to just copy&past
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
Xi Ruoyao changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356
--- Comment #7 from Xi Ruoyao ---
(In reply to Jonny Grant from comment #6)
> Tried a few other compilers on godbolt.
>
> ICC gets the warning on line 6
> https://godbolt.org/z/fYb9c8f61
>
> nvc++ gives the warning on line 6
> https://godbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456
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=109465
Bug ID: 109465
Summary: LoongArch: The expansion of memcpy is slow and bloated
for some sizes
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109465
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed||2023-04-10
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109470
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109470
--- Comment #2 from Xi Ruoyao ---
With "-Wall -O1" this is diagnosed properly, but with a spurious
maybe-uninitialized warning:
In file included from /usr/include/c++/12.2.0/cassert:44,
from t.c:2:
t.c: In function 'int main()'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109446
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Ever confirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109471
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=109446
--- Comment #4 from Xi Ruoyao ---
(In reply to Martin Liška from comment #3)
> The problem here is that we normally preserve memcpy calls and then
> __interceptor_memcpy is used from the run-time library. However, in this
> case the second argum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109481
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=109446
--- Comment #13 from Xi Ruoyao ---
(In reply to rguent...@suse.de from comment #12)
> On Wed, 12 Apr 2023, marxin at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109446
> >
> > --- Comment #9 from Martin Li?ka ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018
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=109369
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109493
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=109484
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=108357
--- Comment #11 from Xi Ruoyao ---
(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,
> > but removed in 135t.forwprop3.
> >
> > Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #14 from Xi Ruoyao ---
(In reply to rguent...@suse.de from comment #13)
> On Thu, 13 Apr 2023, chenglulu at loongson dot cn wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
> >
> > --- Comment #10 from chenglulu --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #18 from Xi Ruoyao ---
(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 hook_bool_const_tree_true but loongarch not?
> That will ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109522
Bug ID: 109522
Summary: Spurious "cc1: error: no include path in which to
search for stdc-predef.h" building a cross compiler
Product: gcc
Version: 13.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109522
--- Comment #2 from Xi Ruoyao ---
(In reply to Jakub Jelinek from comment #1)
> I bet we really don't need the macros from stdc-predef.h, so perhaps we
> could use -nostdinc.
> stdc-predef.h currently (sometimes) predefines
> __STDC_IEC_559__
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109522
Xi Ruoyao changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21038
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #6 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109526
Bug ID: 109526
Summary: Broken type name for anonymous struct containing a VLA
member in diagnostic message
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542
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=109542
--- Comment #4 from Xi Ruoyao ---
(In reply to Amos Maimon from comment #3)
> 1. the same will occur if you will do :
> p[0xe] = 0xfc;
Yes, it's undefined behavior too as C defines a[b] as *(a+b).
> 2. how do you explin the fact that if th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109465
Xi Ruoyao changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109554
--- Comment #2 from Xi Ruoyao ---
And it's clearly documented in https://gcc.gnu.org/gcc-8/changes.html:
Flowing off the end of a non-void function is considered unreachable and may be
subject to optimization on that basis. As a result of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
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=109553
--- Comment #4 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #3)
> Note I disagree with load_uint32_t having a warning. the pointer might be
> have a const qualifier on it does not mean the location is const overall.
And the doc di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109590
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=109590
--- Comment #4 from Xi Ruoyao ---
(In reply to Jonny Grant from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > There is -Wnull-dereference for this ...
>
> I agree. I set that -Wnull-dereference in usual projects (it doesn't seem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #16 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
Xi Ruoyao changed:
What|Removed |Added
Summary|Carla/sord miscompiled with |[10/11/12/13/14 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109633
Xi Ruoyao changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Xi Ruoyao changed:
What|Removed |Added
CC||bremende55 at gmail dot com
--- Comment #26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109522
Xi Ruoyao changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109792
Bug ID: 109792
Summary: RFE: Warn about misuse of "pure" attribute
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109792
Xi Ruoyao changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
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=109814
--- Comment #1 from Xi Ruoyao ---
It seems a deliberate change. See PR103626.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #9 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #11 from Xi Ruoyao ---
Is it supported to use different -flifetime-dse settings for TUs when LTO is
enabled? If yes we can submit a LLVM change to add -flifetime-dse=1 for
User.cpp.o and mark this MOVED.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #16 from Xi Ruoyao ---
(In reply to Alexander Monakov from comment #14)
> (In reply to Jan Hubicka from comment #13)
> > Indeed it is quite long time problem with clang not building with lifetime
> > DSE and strict aliasing. I wonde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #18 from Xi Ruoyao ---
(In reply to Alexander Monakov from comment #12)
> Is there any need to over-engineer this like that? I would hope enabling
> -fno-lifetime-dse globally would not be controversial for LLVM
Maybe. Should we s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #20 from Xi Ruoyao ---
(In reply to Jan Hubicka from comment #19)
> > > Is there any need to over-engineer this like that? I would hope enabling
> > > -fno-lifetime-dse globally would not be controversial for LLVM
>
> It would be re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #28 from Xi Ruoyao ---
(In reply to Alexander Monakov from comment #21)
> (In reply to Xi Ruoyao from comment #18)
> > Maybe. Should we send a patch?
>
> Yes, if we have a volunteer.
I'm creating it, but from the description of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #29 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #28)
> (In reply to Alexander Monakov from comment #21)
> > (In reply to Xi Ruoyao from comment #18)
> > > Maybe. Should we send a patch?
> >
> > Yes, if we have a voluntee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #30 from Xi Ruoyao ---
https://reviews.llvm.org/D150505.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107855
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109842
Xi Ruoyao changed:
What|Removed |Added
Known to fail||12.1.0, 12.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109842
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |MOVED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852
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=109863
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=109863
--- Comment #2 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #1)
> Note that the entire "initializing a flexible array member" thing is a GNU
> extension and not supported by the standard. So GCC is free to support the
> constexpr case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
Xi Ruoyao changed:
What|Removed |Added
URL|https://sourceware.org/pipe |https://sourceware.org/git/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590
Xi Ruoyao changed:
What|Removed |Added
Status|RESOLVED|WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114597
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=114574
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
Xi Ruoyao changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
Xi Ruoyao changed:
What|Removed |Added
Target Milestone|12.4|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114638
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=114637
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Xi Ruoyao changed:
What|Removed |Added
CC||teodor_spaeren at riseup dot
net
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #12 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #10 from Xi Ruoyao ---
> rust's `chrono`
Note that this is really a bad example because of CVE-2020-26235.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
--- Comment #13 from Xi Ruoyao ---
Will we back port the fix to 13 and 12?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
Xi Ruoyao changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
Xi Ruoyao changed:
What|Removed |Added
Summary|Front-end optimization |Front-end optimization
|g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #13 from Xi Ruoyao ---
And IIRC there are various suggestion saying "if you want -fwrapv, you are
likely actually wanting -fsanitize=signed-integer-overflow" and some plan
deprecating -fwrapv. So it's more important to fix the sanit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499
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=114773
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114773
Xi Ruoyao changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #6 from Xi Ruoyao ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114800
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=114808
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114830
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=113235
--- Comment #13 from Xi Ruoyao ---
(In reply to David Malcolm from comment #10)
> (In reply to Jan Hubicka from comment #4)
> > I keep mentioning to Larabel that he should use -fno-semantic-interposition,
> > but he doesn't.
>
> Possibly a sill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848
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=114848
Xi Ruoyao changed:
What|Removed |Added
Summary|longarch: epilogue in |loongarch: epilogue in
|_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861
Bug ID: 114861
Summary: LoongArch: Fail to build the kernel with -Os
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861
--- Comment #1 from Xi Ruoyao ---
Created attachment 58044
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58044&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861
Xi Ruoyao changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #2 from Xi Ruoyao ---
It se
301 - 400 of 1050 matches
Mail list logo
