[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #60 from cqwrteur --- i am here? Have you even checked my repository? i have been working on llvm backend for my projects for nearly a year. At this point i won't even be shocked even microsoft giving up msvc and moving to llvm. Get

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #59 from cqwrteur --- you think it is not a reality? android freebsd wasm and even windows had already moved to llvm. GCC does not even support android any more. glibc on linux is the only reason people still stay with gcc. But now l

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #54 from cqwrteur --- (In reply to Arsen Arsenović from comment #48) > Please stop resetting the bug status. You create unneeded churn. This bug > is invalid. > > (In reply to cqwrteur from comment #43) > > This is completely BS.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #53 from cqwrteur --- (In reply to Arsen Arsenović from comment #48) > Please stop resetting the bug status. You create unneeded churn. This bug > is invalid. > > (In reply to cqwrteur from comment #43) > > This is completely BS.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #52 from cqwrteur --- (In reply to Andrew Pinski from comment #47) > Apple provides different sysroots for each (major) version of their OS to > solve this issue. This is NOT a GCC issue nor this is a glibc issue. You can > buld gcc

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #51 from cqwrteur --- (In reply to Arsen Arsenović from comment #48) > Please stop resetting the bug status. You create unneeded churn. This bug > is invalid. > > (In reply to cqwrteur from comment #43) > > This is completely BS.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #50 from cqwrteur --- (In reply to Arsen Arsenović from comment #48) > Please stop resetting the bug status. You create unneeded churn. This bug > is invalid. > > (In reply to cqwrteur from comment #43) > > This is completely BS.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #44 from cqwrteur --- (In reply to Andrew Pinski from comment #42) > (In reply to frankhb1989 from comment #41) > > I ran into exact the same trouble of C23 missing symbols on old systems. In > > my case it is a custom build (with ta

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #36 from cqwrteur --- Also, it is a waste of energy and time to build the same compiler on different machines over and over again instead of just building one, packaging it and distributed it among many machines. Plus Cloud servers h

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #35 from cqwrteur --- (In reply to Arsen Arsenović from comment #34) > (In reply to cqwrteur from comment #29) > > I don't know how you do that. It is impossible to upgrade glibc on any of my > > linux distributions. I tried ubuntu,

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #33 from cqwrteur --- https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html "If build and target are the same, but host is different, you are using a cross compiler to build a cross compiler that produces code for the machine y

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #32 from cqwrteur --- (In reply to cqwrteur from comment #31) > > Why not? It has to pull libraries and headers from somewhere (note that I > > do not know what "crossback" means). > > > > Note that there is desire to not predefine

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #31 from cqwrteur --- > Why not? It has to pull libraries and headers from somewhere (note that I > do not know what "crossback" means). > > Note that there is desire to not predefine _GNU_SOURCE in C++ modes. See > the PRs Andrew

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #30 from cqwrteur --- (In reply to cqwrteur from comment #29) > (In reply to Arsen Arsenović from comment #28) > > (In reply to cqwrteur from comment #26) > > > > The c++ frontend has defined _GNU_Source since at least 2001. > > > >

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #22 from cqwrteur --- (In reply to Arsen Arsenović from comment #20) > (In reply to cqwrteur from comment #17) > > Then why? Why does it define _ISOC2X_SOURCE? C++ is not even C. > > "it"? presuming you mean glibc, because _GNU_SOU

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #18 from cqwrteur --- (In reply to Andrew Pinski from comment #16) > (In reply to cqwrteur from comment #10) > > (In reply to Andrew Pinski from comment #6) > > > There is NO fix inside gcc/libstdc++. > > > THe only fix is your build

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #13 from cqwrteur --- (In reply to cqwrteur from comment #12) > (In reply to Andrew Pinski from comment #6) > > There is NO fix inside gcc/libstdc++. > > THe only fix is your build of GCC (which includes the target libraries) > > nee

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #12 from cqwrteur --- (In reply to Andrew Pinski from comment #6) > There is NO fix inside gcc/libstdc++. > THe only fix is your build of GCC (which includes the target libraries) > needs to be build against the oldest version of gli

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #11 from cqwrteur --- (In reply to Andrew Pinski from comment #6) > There is NO fix inside gcc/libstdc++. > THe only fix is your build of GCC (which includes the target libraries) > needs to be build against the oldest version of gli

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #10 from cqwrteur --- (In reply to Andrew Pinski from comment #6) > There is NO fix inside gcc/libstdc++. > THe only fix is your build of GCC (which includes the target libraries) > needs to be build against the oldest version of gli

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #9 from cqwrteur --- (In reply to Andrew Pinski from comment #6) > There is NO fix inside gcc/libstdc++. > THe only fix is your build of GCC (which includes the target libraries) > needs to be build against the oldest version of glib

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #7 from cqwrteur --- Created attachment 58654 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58654&action=edit patch

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #5 from cqwrteur --- (In reply to Andrew Pinski from comment #3) > Note while glibc is backwards compatibility, it is not forward compatible. > So if you build against the newest version of glibc, it will always use the > newest symb

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #1 from cqwrteur --- Created attachment 58652 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58652&action=edit dependency

[Bug libstdc++/115907] New: Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Bug ID: 115907 Summary: Libstdc++ and GCC itself should avoid glibc above 2.34 dependency Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug c++/114990] Compiler errors in compiling a module-based app

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 --- Comment #17 from cqwrteur --- (In reply to Jason Merrill from comment #16) > (In reply to cqwrteur from comment #15) > > But it is not declaration, but definition. The actual implementation > > duplicates twice. > > Definitions are also mer

[Bug c++/114990] Compiler errors in compiling a module-based app

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 --- Comment #15 from cqwrteur --- (In reply to Jason Merrill from comment #13) > > The question is still how this library could work. The same simply > > absolutely conflicts. Unless the standard allows inline to be discarded > > across modules

[Bug c++/114990] Compiler errors in compiling a module-based app

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 --- Comment #14 from cqwrteur --- (In reply to Jason Merrill from comment #13) > > The question is still how this library could work. The same simply > > absolutely conflicts. Unless the standard allows inline to be discarded > > across modules

[Bug c++/114990] Compiler errors in compiling a module-based app

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 --- Comment #12 from cqwrteur --- (In reply to Jason Merrill from comment #10) > (In reply to cqwrteur from comment #9) > > (In reply to Jason Merrill from comment #8) > > > bar.cppm:4:20: error: conflicting declaration of ‘void foo()’ in module

[Bug c++/114990] Compiler errors in compiling a module-based app

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 --- Comment #11 from cqwrteur --- (In reply to Jason Merrill from comment #10) > (In reply to cqwrteur from comment #9) > > (In reply to Jason Merrill from comment #8) > > > bar.cppm:4:20: error: conflicting declaration of ‘void foo()’ in module

[Bug c++/114990] Compiler errors in compiling a module-based app

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 --- Comment #9 from cqwrteur --- (In reply to Jason Merrill from comment #8) > bar.cppm:4:20: error: conflicting declaration of ‘void foo()’ in module ‘bar’ > 4 | export inline void foo() noexcept; > |^~~ > In file

[Bug c++/114990] Compiler errors in compiling a module-based app

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 --- Comment #7 from cqwrteur --- (In reply to Jason Merrill from comment #6) > (In reply to cqwrteur from comment #5) > > > > Is this a C++ standard defect? There is no inline definition for classes and > > templates that allow multiple definit

[Bug c++/114990] Compiler errors in compiling a module-based app

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 --- Comment #5 from cqwrteur --- (In reply to Patrick Palka from comment #3) > I reckon it's not something we can fix/implement in a point release of GCC > 14, but hopefully for 15... Is this a C++ standard defect? There is no inline definition

[Bug c++/115720] module symbol collision

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115720 --- Comment #1 from cqwrteur --- https://www.reddit.com/r/cpp/comments/1dqhlh2/c_modules_discussion_ask_questions_and_share_your/ import std; #include // or any other standard library header Looks like defects in the C++ standard that does no

[Bug c++/115720] New: module symbol collision

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115720 Bug ID: 115720 Summary: module symbol collision Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assigne

[Bug libstdc++/107367] All standard library algorithms should optimize to pointers internally when they are contiguous iterators after C++20

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107367 --- Comment #7 from cqwrteur --- I see similar side effects like what if someone adds a print statement in the operator++ or operator * in a contiguous iterator and etc. If I am not allowed to use std::to_address, what’s the point?

[Bug libstdc++/107367] All standard library algorithms should optimize to pointers internally when they are contiguous iterators after C++20

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107367 --- Comment #6 from cqwrteur --- Your argument is not correct when you can just detect all the iterator methods are noexcept. Plus, the standard does not need you to handle exceptions if iterator throw it but to terminate. Btw what is the point

[Bug target/115643] [15 regression] aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64 since r15-1602-ged20feebd9ea31

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 --- Comment #21 from cqwrteur --- First, the bug is not caused by me and I am just reporting the issue here. Why should I waste my time to test for him? Second, I am tired of building compilers again and again just to fix a regression every day

[Bug target/115643] [15 regression] aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64 since r15-1602-ged20feebd9ea31

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 --- Comment #19 from cqwrteur --- Then just merge it into the main repo if it works. I have no time for testing because my machine is super slow and I have no idea what’s going on. BTW, it is still insane Microsoft employee would ask Microsoft

[Bug target/115643] [15 regression] aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64 since r15-1602-ged20feebd9ea31

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 --- Comment #17 from cqwrteur --- https://github.com/trcrsired/toolchainbuildscripts/blob/main/gccbuild/x86_64-w64-mingw32/x86_64-w64-mingw32.sh Here is the automatic script. Go and test yourself

[Bug target/115643] [15 regression] aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64 since r15-1602-ged20feebd9ea31

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 --- Comment #16 from cqwrteur --- This is insane. I am a Microsoft shareholder so technically I am your boss. Why would you ask your boss to waste time for doing your job? Sent from Mail for Windo

[Bug target/115643] [15 regression] aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64 since r15-1602-ged20feebd9ea31

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 --- Comment #15 from cqwrteur --- (In reply to Evgeny Karpov from comment #13) > Could you please confirm that the patch resolves the issue? People like you need to be fired

[Bug target/115643] [15 regression] aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64 since r15-1602-ged20feebd9ea31

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 --- Comment #14 from cqwrteur --- (In reply to Evgeny Karpov from comment #13) > Could you please confirm that the patch resolves the issue? why should I? As a microsoft sholder i would say fuck you for using gmail and google bs

[Bug c++/115692] C++ module ice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115692 cqwrteur changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #6 from

[Bug c++/115692] C++ module ice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115692 --- Comment #5 from cqwrteur --- g++ -c ../modules/fast_io_core_impl.cppm -Ofast -std=c++26 -fmodules-ts -I../include -freport-bug

[Bug c++/115692] C++ module ice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115692 --- Comment #4 from cqwrteur --- g++ -c ../modules/fast_io_core_impl.cppm -Ofast -std=c++26 -fmodules-ts -I../include -freport-bug

[Bug c++/115692] C++ module ice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115692 --- Comment #3 from cqwrteur --- Created attachment 58534 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58534&action=edit Preprocessed source stored into /tmp/cc3uiZPp.out file, please attach this to your bugreport.

[Bug c++/115692] New: C++ module ice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115692 Bug ID: 115692 Summary: C++ module ice Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassi

[Bug target/115643] aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 --- Comment #11 from cqwrteur --- (In reply to Evgeny Karpov from comment #9) > Sure, it will be included in the patch. BTW, any plans for riscv and loongarch support for Windows GCC?

[Bug target/115643] aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 --- Comment #10 from cqwrteur --- (In reply to Evgeny Karpov from comment #9) > Sure, it will be included in the patch. What's the progression of GCC for aarch64-windows-gnu? How long would it be done? I want to buy a surface pro 11 to use it.

[Bug target/115643] aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 --- Comment #1 from cqwrteur --- make[4]: Leaving directory '/home/nagisa/toolchains_build/build/x86_64-w64-mingw32/x86_64-w64-mingw32/artifacts/targetbuild/x86_64-w64-mingw32/gcc/x86_64-w64-mingw32/32/libgcc' make[3]: *** [Makefile:1221: multi-

[Bug target/115643] New: aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 Bug ID: 115643 Summary: aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64 Product: gcc Version: unk

[Bug libstdc++/115585] --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 --- Comment #11 from cqwrteur --- Hi? Could anyone help review my patch and merge it? Ty https://patchwork.sourceware.org/project/gcc/patch/sa1pr11mb71305d480b48400426c253d9b2...@sa1pr11mb7130.namprd11.prod.outlook.com/

[Bug libstdc++/115585] --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 --- Comment #10 from cqwrteur --- https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655462.html

[Bug libstdc++/115585] --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 --- Comment #9 from cqwrteur --- (In reply to Andrew Pinski from comment #8) > (In reply to cqwrteur from comment #7) > > The patch has passed the CI. It is time to review and merge my patch. Thank > > you. > > Before we can review it, can you

[Bug libstdc++/115585] --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 --- Comment #7 from cqwrteur --- The patch has passed the CI. It is time to review and merge my patch. Thank you. https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655430.html https://patchwork.sourceware.org/project/gcc/patch/sa1pr11mb713044

[Bug libstdc++/115585] --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 --- Comment #6 from cqwrteur --- (In reply to Andrew Pinski from comment #3) > https://gcc.gnu.org/onlinedocs/gcc-14.1.0/libstdc++/manual/manual/configure. > html > > > --disable-libstdcxx-verbose > By default, the library is configured to wri

[Bug libstdc++/115585] --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 --- Comment #5 from cqwrteur --- (In reply to Andrew Pinski from comment #4) > Hmm, why was libcppdap.so compiled with _GLIBCXX_DEBUG turned on in the > first place? i don't know. That was a packaging thing from arch. I just got the raw binary

[Bug libstdc++/115585] --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 --- Comment #2 from cqwrteur --- https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655427.html patch is here

[Bug libstdc++/115585] --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 --- Comment #1 from cqwrteur --- cqwrteur@otsiningo:~/toolchains_build/build/native/mold$ cmake -GNinja ../../../mold -DCMAKE_BUILD_TYPE=Release -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=On -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAK

[Bug libstdc++/115585] New: --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 Bug ID: 115585 Summary: --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30 Product: gcc Version:

[Bug other/115268] New: gcc --target --sysroot support?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115268 Bug ID: 115268 Summary: gcc --target --sysroot support? Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other

[Bug target/115094] x86_64-w64-mingw32 multilib overrides libraries for 64 and 32 since they both copy to bin.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115094 --- Comment #1 from cqwrteur --- https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651670.html

[Bug target/115094] New: x86_64-w64-mingw32 multilib overrides libraries for 64 and 32 since they both copy to bin.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115094 Bug ID: 115094 Summary: x86_64-w64-mingw32 multilib overrides libraries for 64 and 32 since they both copy to bin. Product: gcc Version: 15.0 Status: UNCONFIRMED

[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 --- Comment #14 from cqwrteur --- libgcc: /home/cqwrteur/toolchains_build/gcc/libgcc/libgcov.h:49:10: fatal error: sys/mman.h: No such file or directory 49 | #include | ^~~~ compilation terminated. make[4]: *** [Makef

[Bug target/115083] undefined reference for aarch64-w64-mingw32 target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115083 --- Comment #6 from cqwrteur --- (In reply to Richard Earnshaw from comment #5) > Please give the port developers time to finish working on the port. Only > the initial patches have been pushed so far and there is plenty of work left > to do.

[Bug target/115083] undefined reference for aarch64-w64-mingw32 target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115083 --- Comment #4 from cqwrteur --- Created attachment 58203 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58203&action=edit Patch i have added a naive patch here.

[Bug target/115083] undefined reference for aarch64-w64-mingw32 target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115083 --- Comment #3 from cqwrteur --- (In reply to Richard Biener from comment #2) > is this a build issue of GCC itself? yes

[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 --- Comment #13 from cqwrteur --- /home/cqwrteur/toolchains_build/gcc/gcc/c-family/c-format.cc:5159:(.text+0x7c1): undefined reference to `msformat_init()' /usr/local/lib/gcc/x86_64-pc-linux-gnu/15.0.0/../../../../x86_64-pc-linux-gnu/bin/ld: c-f

[Bug target/115083] undefined reference for aarch64-w64-mingw32 target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115083 --- Comment #1 from cqwrteur --- Created attachment 58200 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58200&action=edit error.txt

[Bug target/115083] New: undefined reference for aarch64-w64-mingw32 target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115083 Bug ID: 115083 Summary: undefined reference for aarch64-w64-mingw32 target Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug libstdc++/109926] fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926 --- Comment #11 from cqwrteur --- (In reply to cqwrteur from comment #10) > (In reply to Jonathan Wakely from comment #8) > > Comment on attachment 55135 [details] > > config > > > > configure:18893: checking fenv.h usability > > configure:1889

[Bug libstdc++/109926] fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926 --- Comment #10 from cqwrteur --- (In reply to Jonathan Wakely from comment #8) > Comment on attachment 55135 [details] > config > > configure:18893: checking fenv.h usability > configure:18893: i586-msdosdjgpp-c++ -c -g -O2 -std=c++11 > -

[Bug libstdc++/109926] fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926 --- Comment #9 from cqwrteur --- (In reply to Jonathan Wakely from comment #8) > Comment on attachment 55135 [details] > config > > configure:18893: checking fenv.h usability > configure:18893: i586-msdosdjgpp-c++ -c -g -O2 -std=c++11 > -f

[Bug ipa/114215] -Os or -Oz inlining seems wrong for vague linkage functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114215 --- Comment #8 from cqwrteur --- (In reply to Andrew Pinski from comment #5) > Still waiting on a full application rather then small benchmark type > sources. The heurstic here is that if you call operator[] multiple times, it > might be better

[Bug ipa/114215] -Os or -Oz inlining seems wrong for vague linkage functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114215 --- Comment #7 from cqwrteur --- __builtin_trap() is just to crash the program.

[Bug ipa/114215] -Os or -Oz inlining seems wrong for vague linkage functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114215 --- Comment #6 from cqwrteur --- (In reply to Andrew Pinski from comment #5) > Still waiting on a full application rather then small benchmark type > sources. The heurstic here is that if you call operator[] multiple times, it > might be better

[Bug ipa/114215] GCC makes wrong decision for inline with -Os or -Oz to deal with trivial functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114215 --- Comment #4 from cqwrteur --- void test_demovector(checkedvector& vec, __SIZE_TYPE__ x) noexcept { for(__SIZE_TYPE__ i = 0; i < x; i++) vec[i]=5; } void test_demovector_forceinline(checkedvector& vec, __SIZE_TYPE__ x) noexcept { for(

[Bug ipa/114215] GCC makes wrong decision for inline with -Os or -Oz to deal with trivial functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114215 --- Comment #3 from cqwrteur --- test_demovector(checkedvector&): pushq %rbx movq%rdi, %rbx pushq $4 popq%rsi callcheckedvector::operator[](unsigned long) movq%rbx, %rdi

[Bug rtl-optimization/114215] New: GCC makes wrong decision for inline with -Os or -Oz to deal with trivial functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114215 Bug ID: 114215 Summary: GCC makes wrong decision for inline with -Os or -Oz to deal with trivial functions Product: gcc Version: 14.0 Status: UNCONFIRMED Sever

[Bug target/113501] i think -lntdll should by default by included in windows targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113501 --- Comment #1 from cqwrteur --- https://github.com/gcc-mirror/gcc/blob/56778b69ce558bb7e3ab7c561ee4ee48ac20263b/gcc/config/i386/mingw32.h#L192

[Bug target/113501] New: i think -lntdll should by default by included in windows targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113501 Bug ID: 113501 Summary: i think -lntdll should by default by included in windows targets Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug libgcc/113497] error: implicit declaration of function 'abort' on enable-execute-stack.c on i686-w64-mingw32 target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113497 --- Comment #2 from cqwrteur --- https://github.com/gcc-mirror/gcc/blob/9693459e030977d6e906ea7eb587ed09ee4fddbd/libgcc/config/i386/enable-execute-stack-mingw32.c#L31 Looks like it misses stdlib.h

[Bug libgcc/113497] error: implicit declaration of function 'abort' on enable-execute-stack.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113497 cqwrteur changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #1 from

[Bug libgcc/113497] New: error: implicit declaration of function 'abort' on enable-execute-stack.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113497 Bug ID: 113497 Summary: error: implicit declaration of function 'abort' on enable-execute-stack.c Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: norm

[Bug libstdc++/113283] missing C++26 freestanding headers.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 --- Comment #10 from cqwrteur --- also. how do deal with other headers. like cstdlib which C++26 requires qsort to be freestanding.

[Bug libstdc++/113283] missing C++26 freestanding headers.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 --- Comment #7 from cqwrteur --- (In reply to Arsen Arsenović from comment #5) > C does not have a freestanding error.h, indeed. > > We were considering making up some numbers in a high-up range so that we can > provide some non-OS-provided err

[Bug libstdc++/113283] missing C++26 freestanding headers.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 --- Comment #6 from cqwrteur --- if someone writes an operating system or libc，he can ensure the abi being the same. Get Outlook for Android From: arsen at gcc dot gnu.org Sent: Tuesday,

  1   2   3   4   5   6   7   8   9   >