[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]: ***

[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=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:

[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=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

[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 > >

[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 >

[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 {

[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

[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:

[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

[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:

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 --- Comment #4 from cqwrteur --- Created attachment 57012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57012=edit Proposed errno numbers These numbers come from Linux Kernel Headers and redhat Newlib-Cygwin. I guess these numbers

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 --- Comment #3 from cqwrteur --- I do not see errno.h in freestanding C. Am i correct? Should compiler provide an errno.h? https://en.cppreference.com/w/c/language/conformance

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 --- Comment #2 from cqwrteur --- (In reply to Jonathan Wakely from comment #1) > We can just make up our own numbers, since we won't be getting errno values > from the OS. i would like to make libcxx to have the same numbers as libstdc++. My

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283 Bug ID: 113283 Summary: missing C++26 freestanding headers. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

[Bug libstdc++/113046] Standard algorithms should do de-iterator optimizations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113046 --- Comment #1 from cqwrteur --- -Os optimization could observe the issue more clearly. The number of instructions reduced 51.94%, which is huge. https://godbolt.org/z/Eh1P1vvo5 I guarantee you this will improve the overall performance of C++

[Bug libstdc++/113046] New: Standard algorithms should do de-iterator optimizations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113046 Bug ID: 113046 Summary: Standard algorithms should do de-iterator optimizations Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[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 cqwrteur changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED

[Bug libstdc++/112997] _Unwind_Exception conflicts with void*. failed to build with clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112997 --- Comment #7 from cqwrteur --- (In reply to Andrew Pinski from comment #5) > (In reply to cqwrteur from comment #4) > > (In reply to Andrew Pinski from comment #1) > > > Why are you building libstdc++ sources with clang? I doubt that is > >

[Bug libstdc++/112997] _Unwind_Exception conflicts with void*. failed to build with clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112997 --- Comment #4 from cqwrteur --- (In reply to Andrew Pinski from comment #1) > Why are you building libstdc++ sources with clang? I doubt that is supported. GCC does not support WebAssembly backend

[Bug libstdc++/112997] New: _Unwind_Exception conflicts with void*. failed to build with clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112997 Bug ID: 112997 Summary: _Unwind_Exception conflicts with void*. failed to build with clang Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug c++/112414] New: Does gcc need __builtin_assume_separate_storage?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112414 Bug ID: 112414 Summary: Does gcc need __builtin_assume_separate_storage? Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug libstdc++/111687] New: libstdc++ fails to work for clang 18 any more

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111687 Bug ID: 111687 Summary: libstdc++ fails to work for clang 18 any more Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353 --- Comment #5 from cqwrteur --- It's evident that there's a flaw in the standard, making it impossible to allocate uninitialized memory for freestanding environments. That's precisely why I reported it as a potential issue for future

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353 --- Comment #3 from cqwrteur --- what i am talking about is uninitialized memory for later initialization like implementing containers for example From: redi at gcc dot gnu.org Sent: Saturday, September 9,

[Bug libstdc++/111353] New: bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353 Bug ID: 111353 Summary: bits/new_allocator.h: No such file or directory in freestanding C++ toolchain Product: gcc Version: 14.0 Status: UNCONFIRMED Severity:

[Bug middle-end/111209] GCC fails to understand adc pattern what its document describes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111209 --- Comment #5 from cqwrteur --- (In reply to Jakub Jelinek from comment #4) > (In reply to cqwrteur from comment #3) > > (In reply to Jakub Jelinek from comment #1) > > > Just use __int128 addition if all you want is double-word addition (or

[Bug middle-end/111209] GCC fails to understand adc pattern what its document describes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111209 --- Comment #3 from cqwrteur --- (In reply to Jakub Jelinek from comment #1) > Just use __int128 addition if all you want is double-word addition (or long > long for 32-bit arches)? Well, I've presented this merely as an illustrative example.

[Bug tree-optimization/111209] New: GCC fails to understand adc pattern

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111209 Bug ID: 111209 Summary: GCC fails to understand adc pattern Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug target/110953] Introducing the "wincall" Calling Convention for GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110953 --- Comment #2 from cqwrteur --- Parameters 9+ 8 7 6 5 4 3 2 1 floating-point and __m128 stack  XMM7  XMM6  XMM5  XMM4  XMM3  XMM2  XMM1  XMM0 __m256 stack YMM7  YMM6  YMM5  YMM4  YMM3  YMM2  YMM1  YMM0 __m512 stack ZMM7  ZMM6  ZMM5  ZMM4  

[Bug target/110953] Introducing the "wincall" Calling Convention for GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110953 --- Comment #1 from cqwrteur --- TLDR: floating-point and __m128 stack XMM8  XMM7  XMM6  XMM5  XMM4  XMM3  XMM2  XMM1  XMM0 __m256 stack YMM8  YMM7  YMM6  YMM5  YMM4  YMM3  YMM2  YMM1  YMM0 __m512 stack ZMM8  ZMM7  ZMM6  ZMM5  ZMM4  ZMM3  

[Bug target/110953] New: Introducing the "wincall" Calling Convention for GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110953 Bug ID: 110953 Summary: Introducing the "wincall" Calling Convention for GCC Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug libgcc/110868] crossback build fails for x86_64-pc-linux-gnu due to check on build environment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110868 --- Comment #2 from cqwrteur --- make[5]: Leaving directory '/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-pc-linux-gnu/artifacts/hostbuild/x86_64-w64-mingw32/gcc/x86_64-pc-linux-gnu/32/libgcc' make[4]: Leaving directory

[Bug libgcc/110868] crossback build fails for x86_64-pc-linux-gnu due to check on build environment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110868 --- Comment #1 from cqwrteur --- Created attachment 55670 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55670=edit config

[Bug libgcc/110868] New: crossback build fails for x86_64-pc-linux-gnu due to check on build environment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110868 Bug ID: 110868 Summary: crossback build fails for x86_64-pc-linux-gnu due to check on build environment Product: gcc Version: unknown Status: UNCONFIRMED

[Bug libgcc/110775] New: arm-openwrt-linux-uclibcgnueabi bug

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110775 Bug ID: 110775 Summary: arm-openwrt-linux-uclibcgnueabi bug Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #19 from cqwrteur --- (In reply to cqwrteur from comment #18) > Would you mind if I clarified a few points regarding your query? I'm > referring to implementing "sub borrow" with sub_overflow, as demonstrated in > the code snippet

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #18 from cqwrteur --- Would you mind if I clarified a few points regarding your query? I'm referring to implementing "sub borrow" with sub_overflow, as demonstrated in the code snippet at https://godbolt.org/z/ev3TfeTvd , correct?

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #16 from cqwrteur --- ok Would you mind looking at the following link, https://godbolt.org/z/z7K79YMWr, and sharing your thoughts? I would greatly appreciate your feedback. Thank you very much.

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #14 from cqwrteur --- https://godbolt.org/z/4ej4dnr4b I find a bug here: f0 = __builtin_subcl(f0,v,0,); f1 = __builtin_subcl(f1,zero,carry,); The compiler generates: setb %cl//redundant movzbl %cl, %ecx//redundant

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #13 from cqwrteur --- See this: https://godbolt.org/z/eozPahn9G addcarry pattern it recognizes but not subcarry. You can see it does not recognize the following: template inline constexpr T sub_carry(T x,T y,T carryin,T&

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #11 from cqwrteur --- Actually mine template<::std::unsigned_integral T> inline constexpr T add_carry(T a,T b,T carryin,T& carryout) noexcept { [[assume(carryin==0||carryin==1)]]; a+=b; carryout=a

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #10 from cqwrteur --- i do not know whether | would provide the same performance as + here would due to chain adding. GMP uses all + it seems. Just like i do https://gmplib.org/list-archives/gmp-devel/2021-September/006013.html

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #9 from cqwrteur --- well. user can use __builtin_unreachablecor C++23 assume before calling that then it would be safe to know it is zero or one Get Outlook for Android

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #7 from cqwrteur --- for example lets assume you design the interface with both bool carryin and bool * carryout char unsigned carryin=foo(); bool carryout __builtin_addcl(a,b,carryin,);//carryin will do implicit cast for

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #6 from cqwrteur --- i can guarantee my implementation is optimal on these no flags architectures without the need of optimizations from backend. Then there would be no need to do backend specific optimizations on mips riscv and

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #3 from cqwrteur --- (In reply to cqwrteur from comment #2) > https://godbolt.org/z/bz3PjeMdY https://github.com/animetosho/md5-optimisation Here was an example that shows + is faster than | since + uses a lot for dependency

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #2 from cqwrteur --- https://godbolt.org/z/bz3PjeMdY

[Bug c++/110304] __builtin_adcs missing and jakub you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 --- Comment #1 from cqwrteur --- Also mine is exactly what GCC would generate exactly the same as clang without builtin. Clang internally implements this as mine one. Since on wasm, riscv or loongarch where these architectures do not provide

[Bug c++/110304] New: __builtin_adcs missing and you miss the point of builtin_adcb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110304 Bug ID: 110304 Summary: __builtin_adcs missing and you miss the point of builtin_adcb Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug target/102974] GCC optimization is very poor for add carry and multiplication combos

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102974 --- Comment #15 from cqwrteur --- template<::std::unsigned_integral T> inline constexpr T add_carry_no_carry_in(T a,T b,T& carryout) noexcept { T res{a+b}; carryout=res inline constexpr T add_carry(T a,T b,T carryin,T& carryout)

[Bug target/102974] GCC optimization is very poor for add carry and multiplication combos

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102974 --- Comment #14 from cqwrteur --- template inline constexpr T add_carry_no_carry_in(T a,T b,T& carryout) noexcept { T res{a+b}; carryout=res inline constexpr T add_carry(T a,T b,T carryin,T& carryout) noexcept {

[Bug target/102974] GCC optimization is very poor for add carry and multiplication combos

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102974 --- Comment #13 from cqwrteur --- Hi, the problem comes out GCC does not do a very good job to deal with crypto computations that usually exploit all sorts of patterns. template inline constexpr T add_carry_no_carry_in(T a,T b,T& carryout)

[Bug libgcc/110017] Crossback Compilation for multilib fails on latest ubuntu due to -mx32 being disabled by the linux kernel

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110017 --- Comment #4 from cqwrteur --- Created attachment 55182 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55182=edit Here is the build script (need to install a x86_64-w64-mingw32 cross compiler first)

[Bug libgcc/110017] Crossback Compilation for multilib fails on latest ubuntu due to -mx32 being disabled by the linux kernel

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110017 --- Comment #3 from cqwrteur --- (In reply to Andrew Pinski from comment #2) > How are you configuring GCC? gcc/configure --disable-nls --disable-werror --enable-languages=c,c++ --enable-multilib --with-multilib-list=m64,m32,mx32

[Bug libgcc/110017] Crossback Compilation for multilib fails on latest ubuntu due to -mx32 being disabled by the linux kernel

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110017 --- Comment #1 from cqwrteur --- (In reply to cqwrteur from comment #0) > I attempted crossback compilation for GCC, where the compiler is built on > Linux, runs on Windows, and is targeted for Linux again. However, the build > system of libgcc

[Bug libgcc/110017] New: Crossback Compilation for multilib fails on latest ubuntu due to -mx32 being disabled by the linux kernel

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110017 Bug ID: 110017 Summary: Crossback Compilation for multilib fails on latest ubuntu due to -mx32 being disabled by the linux kernel Product: gcc Version: unknown Status:

[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 #7 from cqwrteur --- Created attachment 55135 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55135=edit config config

[Bug libstdc++/104605] _GLIBCXX_USE_C99_STDINT_TR1 macro is not defined for canadian cross freestanding C++ toolchain

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104605 cqwrteur changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING

[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 #4 from cqwrteur --- (In reply to Andrew Pinski from comment #2) > Where are the target header installed? The problem is that djgpp crx does not provide fenv.h libstdc++ provides a fenv.h, however, the build system cannot find it

[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 #3 from cqwrteur --- (In reply to Andrew Pinski from comment #2) > Where are the target header installed? The headers are installed in the cross toolchain

[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 #1 from cqwrteur --- /home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/i586-msdosdjgpp/artifacts/hostbuild/x86_64-w64-mingw32/gcc/i586-msdosdjgpp/libstdc++-v3/include/fenv.h:36:16: fatal error: fenv.h: No such file or

[Bug libstdc++/109926] New: 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 Bug ID: 109926 Summary: fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp Product: gcc Version: unknown Status: UNCONFIRMED

[Bug other/109584] Chinese Antimalware software Qihoo 360 delete entire GCC install and all programs compiled with GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109584 --- Comment #1 from cqwrteur --- Created attachment 54898 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54898=edit An example Example 360 deletes programs compiled with GCC

[Bug other/109584] New: Chinese Antimalware software Qihoo 360 delete entire GCC install and all programs compiled with GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109584 Bug ID: 109584 Summary: Chinese Antimalware software Qihoo 360 delete entire GCC install and all programs compiled with GCC Product: gcc Version: unknown Status:

[Bug libstdc++/108918] New: PR107701 breaks windows targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108918 Bug ID: 108918 Summary: PR107701 breaks windows targets Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

[Bug sanitizer/106998] [10/11/12/13 Regression] libsanitizer PATH_MAX not defined for linux new targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106998 --- Comment #4 from cqwrteur --- (In reply to Richard Biener from comment #3) > I don't see linux/limits.h included still, but limits.h is - should musl > include linux/limits.h by itself? > > Please link to upstream generated issues. musl

[Bug libstdc++/108332] dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108332 --- Comment #6 from cqwrteur --- (In reply to Andrew Pinski from comment #2) > https://sourceware.org/pipermail/binutils-cvs/2021-March/056031.html https://sourceware.org/bugzilla/show_bug.cgi?id=29973 I doubt this is the issue with ld

[Bug libstdc++/108490] New: circle compiler support for libstdc++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490 Bug ID: 108490 Summary: circle compiler support for libstdc++ Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

[Bug c++/108413] New: copyrights for gcc 2023

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108413 Bug ID: 108413 Summary: copyrights for gcc 2023 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee:

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 cqwrteur changed: What|Removed |Added Resolution|--- |MOVED Status|WAITING

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 cqwrteur changed: What|Removed |Added Status|RESOLVED|WAITING Resolution|MOVED

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #22 from cqwrteur --- (In reply to cqwrteur from comment #19) > (In reply to cqwrteur from comment #18) > > (In reply to cqwrteur from comment #17) > > > (In reply to Eric Botcazou from comment #16) > > > > > #if _WIN32_WINNT >=

[Bug libstdc++/108332] dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108332 --- Comment #4 from cqwrteur --- (In reply to Andrew Pinski from comment #3) > cygwin was improved here: > https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git; > h=801120c1f402f9b0f72b5a231bf9e1cf82614cac > > It might be the case mingw

[Bug libstdc++/108332] New: dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108332 Bug ID: 108332 Summary: dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base Product: gcc

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #20 from cqwrteur --- (In reply to cqwrteur from comment #19) > (In reply to cqwrteur from comment #18) > > (In reply to cqwrteur from comment #17) > > > (In reply to Eric Botcazou from comment #16) > > > > > #if _WIN32_WINNT >=

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #19 from cqwrteur --- (In reply to cqwrteur from comment #18) > (In reply to cqwrteur from comment #17) > > (In reply to Eric Botcazou from comment #16) > > > > #if _WIN32_WINNT >= 0x0600 > > > > #define __GTHREAD_HAS_COND 1 > > > >

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #18 from cqwrteur --- (In reply to cqwrteur from comment #17) > (In reply to Eric Botcazou from comment #16) > > > #if _WIN32_WINNT >= 0x0600 > > > #define __GTHREAD_HAS_COND 1 > > > #define __GTHREADS_CXX0X 1 > > > #endif > > > >

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

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

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

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

[Bug libstdc++/108331] New: ABI break of std::__c_file and std::fstream for win32 thread model of GCC for windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108331 Bug ID: 108331 Summary: ABI break of std::__c_file and std::fstream for win32 thread model of GCC for windows Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #12 from cqwrteur --- (In reply to cqwrteur from comment #11) > The problem is that it breaks gcc build too. GCC won't build any more due to > macro pollution of __FILE__

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

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

[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #6 from cqwrteur --- x86_64-w64-mingw32/artifacts/hostbuild/x86_64-w64-mingw32/gcc/./isl/include -I/home/cqwrteur/toolchains_build/gcc/isl/include -o cp/cvt.o -MT cp/cvt.o -MMD -MP -MF cp/.deps/cvt.TPo

  1   2   3   4   5   6   7   8   >