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

[unlvsur at live dot com via Gcc-bugs]

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 Outlook for Android

From: redi at gcc dot gnu.org 
Sent: Monday, July 22, 2024 5:41:29 AM
To: unlv...@live.com 
Subject: [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 #58 from Jonathan Wakely  ---
(In reply to cqwrteur from comment #43)
> If GNU folks continue f things up, I can guarantee
> you everyone will move to LLVM

You keep saying this, but you're still here. Feel free to leave any time.

--
You are receiving this mail because:
You reported the bug.
You are on the CC list for the bug.

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

[unlvsur at live dot com via Gcc-bugs]

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 llvm is making
libc. We will finally see everyone moves to llvm.

Get Outlook for Android

From: redi at gcc dot gnu.org 
Sent: Monday, July 22, 2024 5:41:29 AM
To: unlv...@live.com 
Subject: [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 #58 from Jonathan Wakely  ---
(In reply to cqwrteur from comment #43)
> If GNU folks continue f things up, I can guarantee
> you everyone will move to LLVM

You keep saying this, but you're still here. Feel free to leave any time.

--
You are receiving this mail because:
You reported the bug.
You are on the CC list for the bug.

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #56 from cqwrteur  ---
(In reply to Andrew Pinski from comment #55)
> https://en.wikipedia.org/wiki/Forward_compatibility

This has nothing to do with forward compatibility. This is about satisfying C++
standard.

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

[unlvsur at live dot com via Gcc-bugs]

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. Old libc cannot build with the latest gcc since the
> > script messed up. People end up stuck with old versions of C++ standards,
> > which is unacceptable. If GNU folks continue f things up, I can guarantee
> > you everyone will move to LLVM
> Fix the build script then, rather than breaking the compiler.
> 
> (In reply to cqwrteur from comment #44)
> > https://github.com/trcrsired/glibc/commit/
> > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff-
> > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1
> > 
> > My patch just works perfectly. Don't know what's your opposition. I am not
> > even suggest an ABI lock down or something
> "WFM" is a dangerous and broken mindset that cannot be applied here.  The
> patch above is a nonsense hack in the libc.

https://www.youtube.com/watch?v=5PmHRSeA2c8&t=283s

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

[unlvsur at live dot com via Gcc-bugs]

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. Old libc cannot build with the latest gcc since the
> > script messed up. People end up stuck with old versions of C++ standards,
> > which is unacceptable. If GNU folks continue f things up, I can guarantee
> > you everyone will move to LLVM
> Fix the build script then, rather than breaking the compiler.
> 
> (In reply to cqwrteur from comment #44)
> > https://github.com/trcrsired/glibc/commit/
> > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff-
> > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1
> > 
> > My patch just works perfectly. Don't know what's your opposition. I am not
> > even suggest an ABI lock down or something
> "WFM" is a dangerous and broken mindset that cannot be applied here.  The
> patch above is a nonsense hack in the libc.

https://news.ycombinator.com/item?id=32471624

Everyone disagrees with gnu's policy here. Even linus torvalds disagrees

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

[unlvsur at live dot com via Gcc-bugs]

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 against majority of old sysroot just fine. I have built against the
> trunk of gcc against a centos 6 sysroot before (actually I have built on the
> trunk after it started to require C++11 on a centos 6 machine too).

Apple? No wonder why apple bs cannot take over windows because only Microsoft
does this right

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

[unlvsur at live dot com via Gcc-bugs]

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. Old libc cannot build with the latest gcc since the
> > script messed up. People end up stuck with old versions of C++ standards,
> > which is unacceptable. If GNU folks continue f things up, I can guarantee
> > you everyone will move to LLVM
> Fix the build script then, rather than breaking the compiler.
> 
> (In reply to cqwrteur from comment #44)
> > https://github.com/trcrsired/glibc/commit/
> > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff-
> > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1
> > 
> > My patch just works perfectly. Don't know what's your opposition. I am not
> > even suggest an ABI lock down or something
> "WFM" is a dangerous and broken mindset that cannot be applied here.  The
> patch above is a nonsense hack in the libc.

Again I do not do native compilation for linux. Do you understand? I do not
native compile linux binaries. I always build linux binaries on windows

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

[unlvsur at live dot com via Gcc-bugs]

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. Old libc cannot build with the latest gcc since the
> > script messed up. People end up stuck with old versions of C++ standards,
> > which is unacceptable. If GNU folks continue f things up, I can guarantee
> > you everyone will move to LLVM
> Fix the build script then, rather than breaking the compiler.
> 
> (In reply to cqwrteur from comment #44)
> > https://github.com/trcrsired/glibc/commit/
> > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff-
> > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1
> > 
> > My patch just works perfectly. Don't know what's your opposition. I am not
> > even suggest an ABI lock down or something
> "WFM" is a dangerous and broken mindset that cannot be applied here.  The
> patch above is a nonsense hack in the libc.

How is that a nonsense hack? It just works by forcing the version to be
stabilized as 2.34.

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #49 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 against majority of old sysroot just fine. I have built against the
> trunk of gcc against a centos 6 sysroot before (actually I have built on the
> trunk after it started to require C++11 on a centos 6 machine too).

I need to do Canadian compilation. I cannot install centos and I don't want
eithert

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #46 from cqwrteur  ---
(In reply to Andrew Pinski from comment #45)
> .

Even Microsoft does this right with _WIN32_WINNT and _WIN32_WINDOWS macros etc,
I don't know what's wrong with adding the similar mechanism for glibc.

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

[unlvsur at live dot com via Gcc-bugs]

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 tailored source) of libfreeimage which
> > has some calls to `sscanf` pulling the unwanted symbol references (to
> > `__isoc23_sscanf@GLIBC_2.38`) into the library
> 
> That is not a glibc issue but rather you are thinking glibc will be forwards
> compatible; glibc is not and never can be; this is true for almost all OS
> out there (Mac OS has a similar issue though they provide sysroots with all
> needed headers/libraries so it is slightly easier to handle rather than you
> need to go out and find one). It is definitely backwards compatiable. If you
> want to build a program that runs on older systems you 100% need to use the
> earliest version of glibc to link (and use headers from) against rather than
> the newest version.

https://github.com/trcrsired/glibc/commit/4a724a45761fe27000247267d6ea02cb64b17b3c#diff-e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1

My patch just works perfectly. Don't know what's your opposition. I am not even
suggest an ABI lock down or something

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #43 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 tailored source) of libfreeimage which
> > has some calls to `sscanf` pulling the unwanted symbol references (to
> > `__isoc23_sscanf@GLIBC_2.38`) into the library
> 
> That is not a glibc issue but rather you are thinking glibc will be forwards
> compatible; glibc is not and never can be; this is true for almost all OS
> out there (Mac OS has a similar issue though they provide sysroots with all
> needed headers/libraries so it is slightly easier to handle rather than you
> need to go out and find one). It is definitely backwards compatiable. If you
> want to build a program that runs on older systems you 100% need to use the
> earliest version of glibc to link (and use headers from) against rather than
> the newest version.

This is completely BS. Old libc cannot build with the latest gcc since the
script messed up. People end up stuck with old versions of C++ standards, which
is unacceptable. If GNU folks continue f things up, I can guarantee you
everyone will move to LLVM

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #39 from cqwrteur  ---
> > mingw has nothing to do with things here. it is a cross compiler. It has
> > nothing to do with sysroot in mingw. There is no need for sysroot at all.
> MINGW is required to build Windows programs, AFAIK (note that I've never
> built a Windows program..), at least due to the headers.  This implies that
> the headers (and probably libraries) need to be in the sysroot of the
> to-Windows cross-compiler.  This does not seem avoidable.

I don't think you understand what you are talking about. The crossback compiler
itself does not need to contain any sysroot and headers for mingw-w64. It only
needs to contain linux headers and libs.

https://github.com/trcrsired/gcc-releases/releases

Go and download the compiler itself and try it with wine.

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

[unlvsur at live dot com via Gcc-bugs]

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 has storage usages
quotes to the point of unable to do so.

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

[unlvsur at live dot com via Gcc-bugs]

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, arch linux. Neither of them allows me
> > to upgrade glibc. After setting LD_LIBRARY_PATH, the kernel just panics. I
> > guess you are using some sorts of the linux from scratch.
> You did something wrong.  Works fine here on Gentoo (and on Arch, when the
> distributor updates it.. you just screwed the process up).
> 
> (In reply to cqwrteur from comment #30)
> > In fact it is so bad even i access a directory that contains libc for cross
> > compiling. it crashes the system.
> > 
> > [cqwrteur@DESKTOP-9B705LH x86_64-pc-linux-gnu]$ cd lib64
> > [cqwrteur@DESKTOP-9B705LH lib64]$ ls
> > Floating point exception (core dumped)
> > [cqwrteur@DESKTOP-9B705LH lib64]$ pwd
> > /home/cqwrteur/toolchains/x86_64-w64-mingw32/x86_64-pc-linux-gnu/x86_64-pc-
> > linux-gnu/lib64
> > [cqwrteur@DESKTOP-9B705LH lib64]$
> Unfortunately, I can't magically debug it.  I certainly can't reproduce this
> issue.
> 
> Also, if that's the cross-compilers sysroot, would the target not be wrong?
> 
> (In reply to cqwrteur from comment #31)
> > The compiler builds on arch linux. runs on windows. produces binaries works
> > on linux again. This is crossback compilation.
> I see no reason why the sysroot would be irrelevant.  There are two sysroots
> involved here: the one containing MinGW stuff and the one containing
> *-linux-gnu stuff.
> 
> (In reply to cqwrteur from comment #32)
> > https://github.com/trcrsired/toolchainbuildscripts/blob/
> > a9eb4dbddde50e8993abde895d2d70c3e36dba79/gccbuild/x86_64-w64-mingw32/x86_64-
> > linux-gnu-crossback.sh#L202C209-L202C224
> > 
> > In fact the abi situation is so bad i have to ship windows GCC to build
> > linux programs.
> This is certainly not required.  I have literally never done that, and I've
> been producing binaries for all sorts of systems for a long time.
> 
> I presume there's no ABI problem here until you prove otherwise.  Compile
> something with an old enough glibc and it'll work on everything that has
> that version or newer.
> 
> (In reply to cqwrteur from comment #33)
> > 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
> > you’re building on. This is rare, so there is no common way of describing
> > it. There is a proposal to call this a crossback."
> > 
> > Here build == target == x86_64-pc-linux-gnu but host == x86_64-w64-mingw32
> I see.  I was not aware of the term.
> 
> (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 _GNU_SOURCE in C++ modes.  See
> > > the PRs Andrew referenced.
> > 
> > 
> > https://github.com/trcrsired/gcc-releases/releases
> > 
> > This one
> > x86_64-pc-linux-gnu.tar.xz in 20240707-x86_64-w64-mingw32
> > 
> > The compiler builds on arch linux. runs on windows. produces binaries works
> > on linux again. This is crossback compilation.
> I won't run your binaries to check.
> 
> I don't see why you need such a convoluted setup.  What are you trying to
> produce?  If you want *-linux-gnu binaries for building *-linux-gnu
> programs, I'd recommend one of a few options:
> 
> 1) Just use the system distributed one,
> 2) Build one with a prefix in some uncommon path like /opt/ and
> link it against old glibc,
> 3) Build glibc against the target system, if that system is known.

Unless the "old enough glibc" won't be able to build latest GCC. Even glibc
2.25 (which is centos stucks with).

Unless system distributed one is not an option for a lot of reasons.
1. Old enough glibc won't be able to build latest GCC
2. The machine itself is very slow to the point to unable to build gcc. For
example Raspi.
3. The environment itself stucks for many reasons to the point of unusable.
Like building GCC directly on windows natively.
4. Convience perspective. Testing MSVC, GCC and clang at the same time, testing
GCC cross compilers. The best way is to build cross back compiler and use it on
windows so that I can compile all the code on windows.


mingw has nothing to do with things here. it is a cross compiler. It has
nothing to do with sysroot in mingw. There is no need for sysroot at all.

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

[unlvsur at live dot com via Gcc-bugs]

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 you’re
building on. This is rare, so there is no common way of describing it. There is
a proposal to call this a crossback."

Here build == target == x86_64-pc-linux-gnu but host == x86_64-w64-mingw32

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

[unlvsur at live dot com via Gcc-bugs]

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 _GNU_SOURCE in C++ modes.  See
> > the PRs Andrew referenced.
> 
> 
> https://github.com/trcrsired/gcc-releases/releases
> 
> This one
> x86_64-pc-linux-gnu.tar.xz in 20240707-x86_64-w64-mingw32
> 
> The compiler builds on arch linux. runs on windows. produces binaries works
> on linux again. This is crossback compilation.

https://github.com/trcrsired/toolchainbuildscripts/blob/a9eb4dbddde50e8993abde895d2d70c3e36dba79/gccbuild/x86_64-w64-mingw32/x86_64-linux-gnu-crossback.sh#L49

https://github.com/trcrsired/toolchainbuildscripts/blob/a9eb4dbddde50e8993abde895d2d70c3e36dba79/gccbuild/x86_64-w64-mingw32/x86_64-linux-gnu-crossback.sh#L202C209-L202C224

In fact the abi situation is so bad i have to ship windows GCC to build linux
programs.

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

[unlvsur at live dot com via Gcc-bugs]

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 referenced.


https://github.com/trcrsired/gcc-releases/releases

This one
x86_64-pc-linux-gnu.tar.xz in 20240707-x86_64-w64-mingw32

The compiler builds on arch linux. runs on windows. produces binaries works on
linux again. This is crossback compilation.

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

[unlvsur at live dot com via Gcc-bugs]

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.
> > > 
> > > You are de facto, breaking abi without any good reason. You break
> > > cross-compiling for linux distribution for even the last year. Glibc 2.34
> > > (which was just 3 years ago) removed -lpthread dependency. I would accept
> > > glibc2.34 as a base. Then what about this __isoc99scanf that behaves
> > > differently under different C and C++ standard. How is this code even
> > > linkable? It easily becomes ODR violations.
> > 
> > It does not become an ODR violation.  Functions behave different in
> > different languages (such as C99 vs. C23 vs. C++11).  This is not unusual.
> > 
> > > https://news.ycombinator.com/item?id=32471624
> > > 
> > > The problem is that unlike libstdc++, glibc is not upgradable.
> > 
> > This is false.  I upgraded glibc a few days ago.
> > 
> > > Don't make any excuse tbh. If people are not happy with it, fix it. If 
> > > you give a
> > > reason for breaking abi for a good reason i would accept that, but you 
> > > don't
> > > you just break abi for no reason. In this case, it is more like a bug for 
> > > a
> > > C standard feature where C++ standard does not support, at least not yet.
> > 
> > No ABI was broken.
> > 
> > > (In reply to Andrew Pinski from comment #25)
> > > > _GNU_SOURCE issue is recorded as pr 69350 and pr 11196 and maybe 
> > > > others. 
> > > > 
> > > > 
> > > > The other issue is not a gcc issue but a build issue with not using a
> > > > sysroot.
> > > Except no matter i try with sysroot i does not really work out. Plus i am
> > > building crossback compiler. It should not even care about sysroot.
> > 
> > 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 referenced.
> 
> I don't know how you do that. It is impossible to upgrade glibc on any of my
> linux distributions. I tried ubuntu, arch linux. Neither of them allows me
> to upgrade glibc. After setting LD_LIBRARY_PATH, the kernel just panics. I
> guess you are using some sorts of the linux from scratch.

In fact it is so bad even i access a directory that contains libc for cross
compiling. it crashes the system.

[cqwrteur@DESKTOP-9B705LH x86_64-pc-linux-gnu]$ cd lib64
[cqwrteur@DESKTOP-9B705LH lib64]$ ls
Floating point exception (core dumped)
[cqwrteur@DESKTOP-9B705LH lib64]$ pwd
/home/cqwrteur/toolchains/x86_64-w64-mingw32/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/lib64
[cqwrteur@DESKTOP-9B705LH lib64]$

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #29 from cqwrteur  ---
(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.
> > 
> > You are de facto, breaking abi without any good reason. You break
> > cross-compiling for linux distribution for even the last year. Glibc 2.34
> > (which was just 3 years ago) removed -lpthread dependency. I would accept
> > glibc2.34 as a base. Then what about this __isoc99scanf that behaves
> > differently under different C and C++ standard. How is this code even
> > linkable? It easily becomes ODR violations.
> 
> It does not become an ODR violation.  Functions behave different in
> different languages (such as C99 vs. C23 vs. C++11).  This is not unusual.
> 
> > https://news.ycombinator.com/item?id=32471624
> > 
> > The problem is that unlike libstdc++, glibc is not upgradable.
> 
> This is false.  I upgraded glibc a few days ago.
> 
> > Don't make any excuse tbh. If people are not happy with it, fix it. If you 
> > give a
> > reason for breaking abi for a good reason i would accept that, but you don't
> > you just break abi for no reason. In this case, it is more like a bug for a
> > C standard feature where C++ standard does not support, at least not yet.
> 
> No ABI was broken.
> 
> > (In reply to Andrew Pinski from comment #25)
> > > _GNU_SOURCE issue is recorded as pr 69350 and pr 11196 and maybe others. 
> > > 
> > > 
> > > The other issue is not a gcc issue but a build issue with not using a
> > > sysroot.
> > Except no matter i try with sysroot i does not really work out. Plus i am
> > building crossback compiler. It should not even care about sysroot.
> 
> 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 referenced.

I don't know how you do that. It is impossible to upgrade glibc on any of my
linux distributions. I tried ubuntu, arch linux. Neither of them allows me to
upgrade glibc. After setting LD_LIBRARY_PATH, the kernel just panics. I guess
you are using some sorts of the linux from scratch.

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #26 from cqwrteur  ---
> The c++ frontend has defined _GNU_Source since at least 2001.

You are de facto, breaking abi without any good reason. You break
cross-compiling for linux distribution for even the last year. Glibc 2.34
(which was just 3 years ago) removed -lpthread dependency. I would accept
glibc2.34 as a base. Then what about this __isoc99scanf that behaves
differently under different C and C++ standard. How is this code even linkable?
It easily becomes ODR violations.

https://news.ycombinator.com/item?id=32471624

The problem is that unlike libstdc++, glibc is not upgradable. Don't make any
excuse tbh. If people are not happy with it, fix it. If you give a reason for
breaking abi for a good reason i would accept that, but you don't you just
break abi for no reason. In this case, it is more like a bug for a C standard
feature where C++ standard does not support, at least not yet.

(In reply to Andrew Pinski from comment #25)
> _GNU_SOURCE issue is recorded as pr 69350 and pr 11196 and maybe others. 
> 
> 
> The other issue is not a gcc issue but a build issue with not using a
> sysroot.
Except no matter i try with sysroot i does not really work out. Plus i am
building crossback compiler. It should not even care about sysroot.

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #24 from cqwrteur  ---
(In reply to Andrew Pinski from comment #23)
> The c++ frontend has defined _GNU_Source since at least 2001.

Then why C++ by default uses a C standard feature that hasn't yet been added
into C++ standard? This makes 0 sense.

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

[unlvsur at live dot com via Gcc-bugs]

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_SOURCES enables all features,
> including the C2X specific ones.
> 
> note that not enabling those would not fix downgrading being broken.

2b is not even a feature for C++ standard. So glibc is wrong here right. Don't
be mad about me. I don't see how this makes sense when you have different
standard options doing completely different things for no good reason.

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #21 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_SOURCES enables all features,
> including the C2X specific ones.
> 
> note that not enabling those would not fix downgrading being broken.

Then why is it not the case for C++98 or C18?

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

[unlvsur at live dot com via Gcc-bugs]

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 of GCC (which includes the target libraries)
> > > needs to be build against the oldest version of glibc you support. This is
> > > something which GCC cannot control.
> > > THIS IS HOW linking and backwards compatibility works.
> > 
> > You gnu guys should stop being ignorant on issues like this. Or everyone
> > will finally move to LLVM.
> 
> You run into the same issue there too.
> 
> Also you have been told a few times to stop with the insults.

Let's be real. You use upper case with insults here. I always say "please"
"thank you" etc here. You are ragging at me for no reason today.

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #17 from cqwrteur  ---
(In reply to Arsen Arsenović from comment #15)
> (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)
> > > needs to be build against the oldest version of glibc you support. This is
> > > something which GCC cannot control.
> > > THIS IS HOW linking and backwards compatibility works.
> > 
> > Also if you don't think this is a bug. Explain this to me. Why C++ will use
> > __isoc23_sscanf but C does not?
> 
> cc1plus defines _GNU_SOURCE which enables _ISOC2X_SOURCE in glibc features.h.
> 
> downgrading libraries at runtime is _never_ supported.  just downgrade the
> build sysroot, as I told you already.
> 
> this is indeed not a bug, in any component.  LLVM will not fix it either.

Then why? Why does it define _ISOC2X_SOURCE? C++ is not even C.

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

[unlvsur at live dot com via Gcc-bugs]

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)
> > needs to be build against the oldest version of glibc you support. This is
> > something which GCC cannot control.
> > THIS IS HOW linking and backwards compatibility works.
> 
> Also if you don't think this is a bug. Explain this to me. Why C++ will use
> __isoc23_sscanf but C does not?
> 
> #include 
> #include 
> 
> int main() {
>const char *input = "42 Alice";
>int number;
> 
>int result = sscanf(input, "%d", &number);
> 
>printf("Parsed number: %d\n", number);
> 
> }
> 
> g++ -S hello.cc -std=c++11
> g++ -S hello.cc -std=c++14
> g++ -S hello.cc -std=c++17
> g++ -S hello.cc -std=c++20
> g++ -S hello.cc -std=c++23
> 
> Why they all use __isoc23_sscanf in the latest glibc 2.40.
> 
> If we compile it with gcc
> 
> gcc -S hello.c -std=c11
> gcc -S hello.c -std=c14
> gcc -S hello.c -std=c18
> gcc -S hello.c -std=c23
> Only C23 uses __isoc23_sscanf.
> 
> It does not make any sense tbh.

C++98 uses scanf. every other C++ standard else uses __isoc23_sscanf. Only C23
uses __isoc23_sscanf while every other C standard, including c18 uses
__isoc99_sscanf. I am using the same GCC 15 toolchain. Why? This is just a bug.
Nothing more.

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

[unlvsur at live dot com via Gcc-bugs]

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 glibc you support. This is
> something which GCC cannot control.
> THIS IS HOW linking and backwards compatibility works.

Also if you don't think this is a bug. Explain this to me. Why C++ will use
__isoc23_sscanf but C does not?

#include 
#include 

int main() {
   const char *input = "42 Alice";
   int number;

   int result = sscanf(input, "%d", &number);

   printf("Parsed number: %d\n", number);

}

g++ -S hello.cc -std=c++11
g++ -S hello.cc -std=c++14
g++ -S hello.cc -std=c++17
g++ -S hello.cc -std=c++20
g++ -S hello.cc -std=c++23

Why they all use __isoc23_sscanf in the latest glibc 2.40.

If we compile it with gcc

gcc -S hello.c -std=c11
gcc -S hello.c -std=c14
gcc -S hello.c -std=c18
gcc -S hello.c -std=c23
Only C23 uses __isoc23_sscanf.

It does not make any sense tbh.

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

[unlvsur at live dot com via Gcc-bugs]

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 glibc you support. This is
> something which GCC cannot control.
> THIS IS HOW linking and backwards compatibility works.

Try to create a gcc cross compiler 15 for glibc 2.25 for me. You cannot even do
that. So what's the excuse?

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

[unlvsur at live dot com via Gcc-bugs]

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 glibc you support. This is
> something which GCC cannot control.
> THIS IS HOW linking and backwards compatibility works.

You gnu guys should stop being ignorant on issues like this. Or everyone will
finally move to LLVM.

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

[unlvsur at live dot com via Gcc-bugs]

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 glibc you support. This is
> something which GCC cannot control.
> THIS IS HOW linking and backwards compatibility works.

That is a bad idea. I do not want to use old glibc. It will break in the future
just like i cannot link against glibc 2.25 any more.

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #8 from cqwrteur  ---
this is the patch. avoid using it thank you

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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 symbols and that is by design.

The problem is that this will just break GCC build in the future. Many people
are stuck with old versions of GCC and can't upgrade due to small issues like
this. Please fix it by avoid using arc4random in libstdc++ for glibc. thank you

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #4 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 symbols and that is by design.

I am pretty sure this is a bug in glibc.
https://sourceware.org/bugzilla/show_bug.cgi?id=31974

#include 
#include 

int main() {
   const char *input = "42 Alice";
   int number;

   int result = sscanf(input, "%d", &number);

   printf("Parsed number: %d\n", number);

}

This will always generate __isoc23_sscanf for g++ no matter what standard it is
 while for C it only generates __isoc23_sscanf when user passes -std=c23.
Considering C++ does not even support 0B 0b for sscanf yet. It is perfectly
reasonable to say it is a bug in glibc.

However, libstdc++ should get rid of arc4random dependency.

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

I think we really need to relax the version requirements of glibc since version
2.34. I cannot use the upstream glibc due to the potential new and versioned
symbols from glibc itself. Glibc2.38 is just too new tbh. Majority of linux
distributions do not support glibc 2.38. Ubuntu 22.04 which is i guess the most
of people are using is still using glibc 2.35

libstdc++ built with latest glibc would introduce import symbols like

arc4random@GLIBC_2.36
__isoc23_strtoull@GLIBC_2.38

I have checked arc4random implementation in glibc. It does not do anything
meaningful in terms of performance but just a wrapper of /dev/random.

glibc only introduces the symbol since 2.36. I don't see why libstdc++ needs
this and in fact it can break abi silently since passing arc4random as a device
now has different behaviors across libstdc++ versions

https://github.com/gcc-mirror/gcc/blob/abf3964711f05b6858d9775c3595ec2b45483e14/libstdc%2B%2B-v3/src/c%2B%2B11/random.cc#L189

This is another thing which is useless for gcc and libstdc++ since libstdc++ 
won't use 0b 0B in scanf/printf.
https://github.com/bminor/glibc/blob/4b2a1b602fc1ade0de85084feb328203be3147c9/include/features.h#L481

while glibc does not break the abi until 2.34. I suggest libstdc++ to use glibc
below 2.34 functions.

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

[unlvsur at live dot com via Gcc-bugs]

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 merged.
> 
> > For translation units, inline function will get discarded in different
> > translation units and keep only one of them as weak symbol. I don't think
> > this applies to module
> 
> Within the global module it does; importing discards duplicate definitions
> much like the linker.

But does that apply to classes, templates or template specialization, etc.?

If someone writes a function=delete while in a module, it does not. Does it get
discarded?

Because for type_traits, unless the template specialization also gets
discarded, this won't work. I don't think other compilers are working here,
either. C++ standard never clarifies it but asks all inline function not to be
inline semantics.

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

[unlvsur at live dot com via Gcc-bugs]

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 I don't see how this could work.
> 
> It works because everything in a header unit is attached to the global
> module.  If the same global module declarations are imported from multiple
> module units, any duplicates are discarded.

For translation units, inline function will get discarded in different
translation units and keep only one of them as weak symbol. I don't think this
applies to module

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

[unlvsur at live dot com via Gcc-bugs]

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 I don't see how this could work.
> 
> It works because everything in a header unit is attached to the global
> module.  If the same global module declarations are imported from multiple
> module units, any duplicates are discarded.

But it is not declaration, but definition. The actual implementation duplicates
twice.

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

[unlvsur at live dot com via Gcc-bugs]

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 
> > > ‘bar’
> > > 4 | export inline void foo() noexcept;
> > >   |^~~
> > > In file included from bar.cppm:2:
> > > someheader.hpp:1:13: note: previously declared in global module
> > 
> > That is my problem. This just breaks header only libraries right?
> 
> No, you just need to #include the library header before the "export module"
> line.  Or better yet, use import  instead of #include.
> 
> > This is the same.
> > 
> > import std;
> > #include //it uses std features.
> > 
> > This is absolutely the standard bug.
> 
> This is a GCC bug, as described in comment #1.  If you
> 
> import ;
> 
> instead, it should work fine.  Naturally, that requires that you first
> 
> g++ -fmodules-ts -c -x c++-system-header aheaderonlylibrary

std is actually just one example. It applies to any library that have the same
dependency issue.

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

[unlvsur at live dot com via Gcc-bugs]

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 
> > > ‘bar’
> > > 4 | export inline void foo() noexcept;
> > >   |^~~
> > > In file included from bar.cppm:2:
> > > someheader.hpp:1:13: note: previously declared in global module
> > 
> > That is my problem. This just breaks header only libraries right?
> 
> No, you just need to #include the library header before the "export module"
> line.  Or better yet, use import  instead of #include.
> 
> > This is the same.
> > 
> > import std;
> > #include //it uses std features.
> > 
> > This is absolutely the standard bug.
> 
> This is a GCC bug, as described in comment #1.  If you
> 
> import ;
> 
> instead, it should work fine.  Naturally, that requires that you first
> 
> g++ -fmodules-ts -c -x c++-system-header aheaderonlylibrary

The question is still how this library could work. The same simply absolutely
conflicts. Unless the standard allows inline to be discarded across modules I
don't see how this could work.

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

[unlvsur at live dot com via Gcc-bugs]

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 included from bar.cppm:2:
> someheader.hpp:1:13: note: previously declared in global module

That is my problem. This just breaks header only libraries right?

This is the same.

import std;
#include //it uses std features.


This is absolutely the standard bug. I am 100% correct here.

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

[unlvsur at live dot com via Gcc-bugs]

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 definitions to be discarded in different
> > modules, just like "inline" does in the other translation units.
> 
> In the testcase all definitions are attached to the global module because
> they precede any "export module" line, so the usual merging applies.

My question is that

//someheader.hpp
inline void foo() noexcept
{
 //dosomethingheader
}


//bar.cppm
module;
#include
export module bar;
export inline void foo() noexcept;

//main.cpp
Import bar;
#include
Int main()
{
 foo(); //which foo()? The foo in the header or the foo in the module?
}

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

[unlvsur at live dot com via Gcc-bugs]

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 for classes and
templates that allow multiple definitions to be discarded in different modules,
just like "inline" does in the other translation units.

[Bug c++/115720] module symbol collision

[unlvsur at live dot com via Gcc-bugs]

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 not support it.

I suggest the solution is to allow the "inline" class to discord duplicated
classes or templates across different modules.

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

[unlvsur at live dot com via Gcc-bugs]

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++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

//mymodule.cppm
module;
#include
#include
export module mymodule;

export namespace test
{
enum class dll_mode: ::std::uint_least32_t
{};

inline constexpr dll_mode operator&=(dll_mode x, dll_mode y) noexcept
{
using utype = typename ::std::underlying_type::type;
return static_cast(static_cast(x) &
static_cast(y));
}
}


//main.cc
import mymodule;
#include
int main(){}

g++ -c mymodule.cppm -Ofast -std=c++26 -fmodules-ts
g++ -o main main.cc mymodule.o -Ofast -std=c++26 -fmodules-ts
In file included from main.cc:2:
D:/toolchains/gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/15.0.0/type_traits:2511:42:
error: default argument for template parameter for class enclosing 'using
std::__underlying_type_impl<_Tp,  >::type = __underlying_type(_Tp)'
 2511 |   using type = __underlying_type(_Tp);
  |  ^
D:/toolchains/gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/15.0.0/type_traits:2511:42:
error: template definition of non-template 'using
std::__underlying_type_impl<_Tp,  >::type = __underlying_type(_Tp)'
D:/toolchains/gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/15.0.0/type_traits:2515:12:
error: redefinition of
struct std::__underlying_type_impl<_Tp, false>'
 2515 | struct __underlying_type_impl<_Tp, false>
  |^~
In file included from mymodule.cppm:3,
of module mymodule, imported at main.cc:1:
D:/toolchains/gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/15.0.0/type_traits:2515:12:
note: previous definition of 'struct std::__underlying_type_impl<_Tp, false>'
 2515 | struct __underlying_type_impl<_Tp, false>
  |^~
D:/toolchains/gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/15.0.0/type_traits:2522:40:
error: wrong number of template arguments (1, should be 2)
 2522 | : public __underlying_type_impl<_Tp>
  |^
D:/toolchains/gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/15.0.0/type_traits:2509:12:
note: provided for 'template > struct
std::__underlying_type_impl'
 2509 | struct __underlying_type_impl
  |^~

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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 of contiguous_iterator if i am not allowed to use
std::to_address to optimize code? The whole point of contiguous_iterator is
that i am allowed to use pointer arithematics directly.

Get Outlook for Android

From: redi at gcc dot gnu.org 
Sent: Friday, June 28, 2024 7:41:47 AM
To: unlv...@live.com 
Subject: [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 #5 from Jonathan Wakely  ---
This optimization isn't valid if any iterator operations can throw, because
such an exception should terminate the loop early. Performing the algo on raw
pointers would alter the behaviour.

--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.

[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

[unlvsur at live dot com via Gcc-bugs]

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. My machine is super slow with no SSD.

BTW do I even make a decision on whether a patch would get merged into GCC? Did
you merge my patch on fixing libstdc++’s abi break? Oh it does not follow your
“code standard” plus you hate me for that freestanding thing and I get it. Ok,
then fix it yourself.

Sorry, I am not going to do either of them. I am not going to test it and I am
not going to fix the ABI bug. It is better you don’t fix the ABI regression and
let the GNU/Linux die.

Sent from Mail for Windows


From: redi at gcc dot gnu.org 
Sent: Friday, June 28, 2024 5:19:03 AM
To: unlv...@live.com 
Subject: [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 #20 from Jonathan Wakely  ---
Your attitude and behaviour is not acceptable, as you've been told many times
before.

You will be banned if you continue.

https://gcc.gnu.org/conduct.html

--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.

[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

[unlvsur at live dot com via Gcc-bugs]

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 shareholder to
test for him.

Sent from Mail for Windows


From: slyfox at gcc dot gnu.org 
Sent: Friday, June 28, 2024 5:07:40 AM
To: unlv...@live.com 
Subject: [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 #18 from Sergei Trofimovich  ---
(In reply to Evgeny Karpov from comment #13)
> Could you please confirm that the patch resolves the issue?

The change fixes --target=i686-w64-mingw32 for me. Thank you!

--
You are receiving this mail because:
You reported the bug.
You are on the CC list for the bug.

[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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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 Windows


From: Evgeny.Karpov at microsoft dot com 
Sent: Friday, June 28, 2024 4:39:24 AM
To: unlv...@live.com 
Subject: [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 #13 from Evgeny Karpov  ---
Could you please confirm that the patch resolves the issue?

--
You are receiving this mail because:
You reported the bug.
You are on the CC list for the bug.

[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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115692

cqwrteur  changed:

   What|Removed |Added

 CC||unlvsur at live dot com

--- Comment #6 from cqwrteur  ---
Created attachment 58535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58535&action=edit
Crashed file preprocessed

This is the one that crashes i think.

g++ -c ../modules/fast_io_core_impl.cppm -Ofast -std=c++26 -fmodules-ts
-I../include -freport-bug

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 58533
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58533&action=edit
preprocessor file

GCC ice for module.

cqwrteur@otsiningo:~/Libraries/fast_io/.tmp$ g++ -o hello
../modules/fast_io_core.ixx ../modules/fast_io_core_impl.cppm hello.cc -Ofast
-std=c++26 -fmodules-ts -I../include
In file included from
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/include/c++/15.0.0/type_traits:38,
 from ../modules/fast_io_core_impl.cppm:4:
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/include/c++/15.0.0/x86_64-pc-linux-gnu/bits/c++config.h:836:11:
internal compiler error: in push_namespace, at cp/name-lookup.cc:9110
  836 | namespace __gnu_cxx
  |   ^
0x26b7008 internal_error(char const*, ...)
???:0
0xa9b9b4 fancy_abort(char const*, int, char const*)
???:0
0xca55aa c_parse_file()
???:0
0xdf61b1 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
hello.cc: In function 'int main()':
hello.cc:5:48: error: 'posix_rtld_deepbind' is not a member of
'fast_io::dll_mode@fast_io.core'
5 | ::fast_io::dll_mode d{::fast_io::dll_mode::posix_rtld_deepbind};
  |^~~


here is the processor file

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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-do] Error 1
make[3]: 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/libgcc'
make[2]: *** [Makefile:127: all-multi] Error 2
make[2]: *** Waiting for unfinished jobs
make[2]: 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/libgcc'
make[1]: *** [Makefile:15805: all-target-libgcc] Error 2
make[1]: Leaving directory
'/home/nagisa/toolchains_build/build/x86_64-w64-mingw32/x86_64-w64-mingw32/artifacts/targetbuild/x86_64-w64-mingw32/gcc'
make: *** [Makefile:1069: all] Error 2

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

[unlvsur at live dot com via Gcc-bugs]

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: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

/tmp/ccPA6rty.s: Assembler messages:
/tmp/ccPA6rty.s:758: Error: cannot represent relocation type BFD_RELOC_64
make[4]: *** [Makefile:508: __main.o] Error

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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 make sure you follow
> https://gcc.gnu.org/contribute.html ?
> You are missing a changelog for one.
> Second since you are not using your real name, do you have a copyright
> assignment on file with the FSF? If not please resubmit with your real name
> and add a signed-off by. Or put in place a copyright assignment.

https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655461.html

Is this ok now?

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

[unlvsur at live dot com via Gcc-bugs]

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/sa1pr11mb713044b81eab485b95d8fb7fb2...@sa1pr11mb7130.namprd11.prod.outlook.com/

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

[unlvsur at live dot com via Gcc-bugs]

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 write descriptive messages to
> standard error for certain events such as calling a pure virtual function or
> the invocation of the standard terminate handler. Those messages cause the
> library to depend on the demangler and standard I/O facilities, which might
> be undesirable in a low-memory environment or when standard error is not
> available. This option disables those messages. This option does not change
> the library ABI.
> 
> Either the documentation is incorrect or we should provide an empty one.

i have provided an empty implementation that fixes the issue. Please review my
patch and merge it

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

[unlvsur at live dot com via Gcc-bugs]

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
from it.

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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++ -DCMAKE_ASM_COMPILER=clang
-DCMAKE_INSTALL_PREFIX=$HOME/toolchains/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu
-DCMAKE_C_FLAGS="--gcc-toolchain=$HOME/toolchains/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu
-fuse-ld=lld"
-DCMAKE_CXX_FLAGS="$HOME/toolchains/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu
-fuse-ld=lld"
cmake: symbol lookup error: /usr/lib/libcppdap.so: undefined symbol:
_ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30

The problem is the archlinux provides libcppdap which compiles with verbose one
but i disable the verbose build.

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

[unlvsur at live dot com via Gcc-bugs]

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: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

https://github.com/gcc-mirror/gcc/blob/ccbcde5ec0e481e1ea775649d59691b6f5fcc5a1/libstdc%2B%2B-v3/src/c%2B%2B11/assert_fail.cc#L28C8-L28C31

i think we should provide a dummy implementation of this function when
_GLIBCXX_VERBOSE_ASSERT is disabled by just calling abort, or it breaks abi.

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

[unlvsur at live dot com via Gcc-bugs]

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
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

clang supports --target --sysroot which is more convenient for integrating the
concept of native and cross compared to target-gcc.

Is there any possibility of supporting that for gcc?

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

[unlvsur at live dot com via Gcc-bugs]

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.

[unlvsur at live dot com via Gcc-bugs]

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
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 58207
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58207&action=edit
patch

Please accept my patch to fix it. This has been extremely annoying for me for
many years now.

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

[unlvsur at live dot com via Gcc-bugs]

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]: *** [Makefile:933: _gcov_interval_profiler.o] Error 1
make[4]: *** Waiting for unfinished jobs

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

[unlvsur at live dot com via Gcc-bugs]

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.

I am going to buy incoming lenovo aarch64 on windows machine next month. That
is why i need a fix to ensure i could run gcc on that machine.

windows on arm64 is very good now. It even runs world of warcraft.

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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-family/c-format.o: in function `cmp_attribs(char const*, char const*)':

Can you explain to me what is going on? Thank you!

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 58199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58199&action=edit
config.log

undefined reference to `msformat_init()'


Windows on ARM64 platform target aarch64-w64-mingw32

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

[unlvsur at live dot com via Gcc-bugs]

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:18893:  i586-msdosdjgpp-c++ -c -g -O2 -std=c++11
> > -fno-exceptions  conftest.cpp >&5
> > configure:18893: $? = 0
> > configure:18893: result: yes
> > configure:18893: checking fenv.h presence
> > configure:18893:  i586-msdosdjgpp-c++ -E  conftest.cpp
> > configure:18893: $? = 0
> > configure:18893: result: yes
> > configure:18893: checking for fenv.h
> > configure:18893: result: yes
> > 
> > This means configure is finding fenv.h in your sysroot.
> 
> i586-msdosdjgpp-c++ should use i586-msdosdjgpp-gcc to test, not
> i586-msdosdjgpp-c++ i think

https://github.com/gcc-mirror/gcc/blob/6fc84f680d098f82c1c43435fdb206099f0df4df/libstdc%2B%2B-v3/configure#L19263

my guess is that it tries to use detect it by using the cross toolchain's
libstdc++ fenv.h despite fenv.h does not exist. probably need to detect it with
-nostdinc++??

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

[unlvsur at live dot com via Gcc-bugs]

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
> -fno-exceptions  conftest.cpp >&5
> configure:18893: $? = 0
> configure:18893: result: yes
> configure:18893: checking fenv.h presence
> configure:18893:  i586-msdosdjgpp-c++ -E  conftest.cpp
> configure:18893: $? = 0
> configure:18893: result: yes
> configure:18893: checking for fenv.h
> configure:18893: result: yes
> 
> This means configure is finding fenv.h in your sysroot.

i586-msdosdjgpp-c++ should use i586-msdosdjgpp-gcc to test, not
i586-msdosdjgpp-c++ i think

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

[unlvsur at live dot com via Gcc-bugs]

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
> -fno-exceptions  conftest.cpp >&5
> configure:18893: $? = 0
> configure:18893: result: yes
> configure:18893: checking fenv.h presence
> configure:18893:  i586-msdosdjgpp-c++ -E  conftest.cpp
> configure:18893: $? = 0
> configure:18893: result: yes
> configure:18893: checking for fenv.h
> configure:18893: result: yes
> 
> This means configure is finding fenv.h in your sysroot.

fenv.h is in libstdc++. not in libc. djgpp libc does not provide fenv.h

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

[unlvsur at live dot com via Gcc-bugs]

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 not to inline it for size reasons.

llvm actually makes different decision here. Probably GCC thinks __builtin_trap
is expensive despite it is not.

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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 not to inline it for size reasons.

I know. but here the function is too small to the point it is always better to
inline it. Because all it does is an efficient bounds checking. You do not want
bounds checking to be a function call.

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

[unlvsur at live dot com via Gcc-bugs]

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(__SIZE_TYPE__ i = 0; i < x; i++)
vec.index_forceinline(i)=5;
}

still more instructions for the first one even with a loop.

test_demovector(checkedvector&, unsigned long):
pushq   %r12
movq%rdi, %r12
pushq   %rbp
movq%rsi, %rbp
pushq   %rbx
xorl%ebx, %ebx
.L10:
cmpq%rbp, %rbx
je  .L13
movq%rbx, %rsi
movq%r12, %rdi
incq%rbx
callcheckedvector::operator[](unsigned long)
movq$5, (%rax)
jmp .L10
.L13:
popq%rbx
popq%rbp
popq%r12
ret



test_demovector_forceinline(checkedvector&, unsigned long):
xorl%eax, %eax
.L15:
cmpq%rsi, %rax
je  .L18
movq(%rdi), %rcx
movq8(%rdi), %rdx
subq%rcx, %rdx
sarq$3, %rdx
cmpq%rdx, %rax
jb  .L16
ud2
.L16:
movq$5, (%rcx,%rax,8)
incq%rax
jmp .L15
.L18:
ret

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

[unlvsur at live dot com via Gcc-bugs]

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
movq$5, (%rax)
pushq   $6
popq%rsi
callcheckedvector::operator[](unsigned long)
movq%rbx, %rdi
movq$5, (%rax)
pushq   $10
popq%rsi
callcheckedvector::operator[](unsigned long)
movq%rbx, %rdi
movq$5, (%rax)
pushq   $5
popq%rsi
callcheckedvector::operator[](unsigned long)
movq$5, (%rax)
popq%rbx
ret
test_demovector_forceinline(checkedvector&):
movq(%rdi), %rax
movq8(%rdi), %rdx
subq%rax, %rdx
cmpq$32, %rdx
ja  .L7
.L8:
ud2
.L7:
movq$5, 32(%rax)
cmpq$48, %rdx
jbe .L8
movq$5, 48(%rax)
cmpq$80, %rdx
jbe .L8
movq$5, 80(%rax)
movq$5, 40(%rax)
ret

see? first one has more instructions than the 2nd one.

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

[unlvsur at live dot com via Gcc-bugs]

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
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

This is a very common example for implementing a bounds checking vecotr index.
GCC makes the wrong decision. This even increases the code size but not
decreases the size compared to -O3.

GCC with -Oz
https://godbolt.org/z/sa9YYqnYY
GCC with -Ofast
https://godbolt.org/z/b6jahvh6s

clang with -Oz
https://godbolt.org/z/GxPaxP66b

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

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
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

https://github.com/gcc-mirror/gcc/blob/f036d759ecee538555fa8c6b11963e4033732463/gcc/config/i386/ming

The mcf thread has already linked to -lntdll, and it's confirmed that even
Windows 95 includes ntdll.dll. Additionally, if users do not utilize any
functions from ntdll directly, the inclusion of -lntdll does not result in
linking to it. Therefore, I propose making it a default toggle to simplify
compilation for Windows.

On windows 95, if we do -lntdll, it won't still run. I have tried and confirmed
it.

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

[unlvsur at live dot com via Gcc-bugs]

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

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113497

cqwrteur  changed:

   What|Removed |Added

 CC||unlvsur at live dot com

--- Comment #1 from cqwrteur  ---
Created attachment 57153
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57153&action=edit
config.log

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

[unlvsur at live dot com via Gcc-bugs]

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: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 57152
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57152&action=edit
error file

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

[unlvsur at live dot com via Gcc-bugs]

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.

[unlvsur at live dot com via Gcc-bugs]

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 errors that the standard requires, too
> 
> why do you think having the same numbers for both libraries in freestanding
> would be beneficial?  this seems odd to me

Whatever, i will make clang/libc++ be compatible to gcc/libstdc++ here. The
LLVM folks wants to put errno.h into the compiler side as an extension for a
freestanding C header.

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

[unlvsur at live dot com via Gcc-bugs]

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, January 9, 2024 7:18:46 AM
To: unlv...@live.com 
Subject: [Bug libstdc++/113283] missing C++26 freestanding headers.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #5 from Arsen Arsenović  ---
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 errors that the standard requires, too

why do you think having the same numbers for both libraries in freestanding
would be beneficial?  this seems odd to me

--
You are receiving this mail because:
You reported the bug.
You are on the CC list for the bug.