[Bug c++/99327] New: ENOTSUP macro does not exist on djgpp crt

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 Bug ID: 99327 Summary: ENOTSUP macro does not exist on djgpp crt Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 --- Comment #1 from cqwrteur --- Created attachment 50277 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50277&action=edit DJGPP's original errno This is djgpp crt's original errno.

[Bug c++/99330] New: module ICE with -std=c++2b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99330 Bug ID: 99330 Summary: module ICE with -std=c++2b Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee:

[Bug libstdc++/99396] New: std::rotl and std::rotr do not invoke intrinsics, leading to serious performance issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396 Bug ID: 99396 Summary: std::rotl and std::rotr do not invoke intrinsics, leading to serious performance issues Product: gcc Version: 11.0 Status: UNCONFIRMED Se

[Bug tree-optimization/99396] std::rotl and std::rotr Does not convert into ROTATE on the gimple level

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396 --- Comment #2 from cqwrteur --- (In reply to Andrew Pinski from comment #1) > return std::rotr(v,((unsigned int)t)&63); > Fixes the problem > int a = std::abs(t); > a &= 63; > return std::rotr(v,a); > > Also improves the si

[Bug tree-optimization/99396] std::rotl and std::rotr Does not convert into ROTATE on the gimple level

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396 --- Comment #4 from cqwrteur --- (In reply to Andrew Pinski from comment #3) > (In reply to cqwrteur from comment #2) > > I would like to see __builtin_cpp_rotl and __builtin_cpp_rotr to allow more > > aggressive optimizations since rotl and rotr

[Bug tree-optimization/99396] std::rotl and std::rotr Does not convert into ROTATE on the gimple level

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396 --- Comment #13 from cqwrteur --- (In reply to Jakub Jelinek from comment #12) > Created attachment 50305 [details] > gcc11-pr99396.patch > > Some further tweaks based on IRC discussions. shouldn't this be if constexpr ((_Nd & (_Nd - 1)) == 0)

[Bug tree-optimization/99396] std::rotl and std::rotr Does not convert into ROTATE on the gimple level

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396 --- Comment #16 from cqwrteur --- (In reply to Jakub Jelinek from comment #15) > Could be if _GLIBCXX17_CONSTEXPR (...) > sure. bit header is a new C++20 header. There is no reason the compiler does not support if constexpr. If you compile it w

[Bug tree-optimization/99396] std::rotl and std::rotr Does not convert into ROTATE on the gimple level

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396 --- Comment #17 from cqwrteur --- (In reply to cqwrteur from comment #16) > (In reply to Jakub Jelinek from comment #15) > > Could be if _GLIBCXX17_CONSTEXPR (...) > > sure. > > bit header is a new C++20 header. There is no reason the compiler d

[Bug tree-optimization/99396] std::rotl and std::rotr Does not convert into ROTATE on the gimple level

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396 --- Comment #18 from cqwrteur --- (In reply to cqwrteur from comment #17) > (In reply to cqwrteur from comment #16) > > (In reply to Jakub Jelinek from comment #15) > > > Could be if _GLIBCXX17_CONSTEXPR (...) > > > sure. > > > > bit header is a

[Bug target/99405] Rotate with mask not optimized on x86 for QI/HImode rotates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99405 --- Comment #4 from cqwrteur --- (In reply to Jakub Jelinek from comment #3) > Created attachment 50307 [details] > gcc11-pr99405.patch > > No particular reason, it just feeled weird to have constraints on pre-reload > splitters. > > Anyway, I'

[Bug target/99405] Rotate with mask not optimized on x86 for QI/HImode rotates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99405 --- Comment #6 from cqwrteur --- (In reply to Jakub Jelinek from comment #5) > The valid C code if it is correct without UB and is pattern matched is > definitely better than some intrinsics, it is portable and can be optimized > generally sooner

[Bug tree-optimization/99434] New: std::bit_cast generates more instructions than __builtin_bit_cast and memcpy with -march=native

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99434 Bug ID: 99434 Summary: std::bit_cast generates more instructions than __builtin_bit_cast and memcpy with -march=native Product: gcc Version: 11.0 Status: UNCONFIRMED

[Bug target/99434] std::bit_cast generates more instructions than __builtin_bit_cast and memcpy with -march=native

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99434 --- Comment #2 from cqwrteur --- (In reply to Andrew Pinski from comment #1) > This is just a register allocation issue dealing with mulx and TImode. > > If mulq was used instead (that is without -march=native), all of the > functions are done c

[Bug target/99434] std::bit_cast generates more instructions than __builtin_bit_cast and memcpy with -march=native

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99434 --- Comment #6 from cqwrteur --- (In reply to Jakub Jelinek from comment #5) > Testcase without includes: > template > constexpr _To > bit_cast(const _From& __from) noexcept > { > return __builtin_bit_cast(_To, __from); > } > > struct u64x2_t

[Bug sanitizer/99476] New: 'PATH_MAX' was not declared in this scope

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99476 Bug ID: 99476 Summary: 'PATH_MAX' was not declared in this scope Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitize

[Bug libstdc++/99499] New: bootstrap failure for bionic toolchains. error: '_U' was not declared in this scope

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99499 Bug ID: 99499 Summary: bootstrap failure for bionic toolchains. error: '_U' was not declared in this scope Product: gcc Version: 11.0 Status: UNCONFIRMED Severi

[Bug libstdc++/99499] build failure for android bionic toolchains. error: '_U' was not declared in this scope

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99499 --- Comment #1 from cqwrteur --- Probably just remove this file and use the generic one it would work? https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/config/os/bionic/ctype_base.h

[Bug sanitizer/99503] New: sanitizers build error for android cross toolchain. error: 'SA_ONSTACK' was not declared in this scope;

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99503 Bug ID: 99503 Summary: sanitizers build error for android cross toolchain. error: 'SA_ONSTACK' was not declared in this scope; Product: gcc Version: 11.0 Status: UNCONFIR

[Bug target/99499] build failure for android bionic toolchains. error: '_U' was not declared in this scope

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99499 --- Comment #3 from cqwrteur --- (In reply to Jonathan Wakely from comment #2) > Obviously _U worked at some point when that file was added. CCing Maxim to > figure out what changed and whether we want to support the old ctype > constants as well

[Bug target/99499] build failure for android bionic toolchains. error: '_U' was not declared in this scope

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99499 --- Comment #4 from cqwrteur --- Hi, jonathan. I found something different from old versions of android compared to GCC source. https://android.googlesource.com/toolchain/gcc/+/refs/heads/ndk-r11-release/gcc-4.9/libstdc++-v3/config/os/bionic/cty

[Bug target/99499] build failure for android bionic toolchains. error: '_U' was not declared in this scope

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99499 --- Comment #5 from cqwrteur --- Created attachment 50356 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50356&action=edit ctype.h ctype.h actually provides those macros. but they said "Internal implementation detail. Do not use." I try

[Bug target/99499] build failure for android bionic toolchains. error: '_U' was not declared in this scope

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99499 --- Comment #6 from cqwrteur --- Created attachment 50357 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50357&action=edit Bionic ctype patch for libstdc++ It looks macros are defined differently on different versions of bionic. The latest

[Bug target/99499] build failure for android bionic toolchains. error: '_U' was not declared in this scope

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99499 --- Comment #7 from cqwrteur --- Created attachment 50358 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50358&action=edit The patch works. No issue. Jonathan, you can merge my patch to master now.

[Bug target/99499] build failure for android bionic toolchains. error: '_U' was not declared in this scope

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99499 --- Comment #8 from cqwrteur --- Created attachment 50359 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50359&action=edit Hello world runs successfully

[Bug target/99499] build failure for android bionic toolchains. error: '_U' was not declared in this scope

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99499 --- Comment #9 from cqwrteur --- The only problem now is due to privilege issues, we cannot dynamic linking with libstdc++-6.so I think they can just use fast_io instead and that will avoid the bloating here.

[Bug rtl-optimization/99548] New: Help me! Lost the fight against the compiler.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99548 Bug ID: 99548 Summary: Help me! Lost the fight against the compiler. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-

[Bug target/99548] Help me! Lost the fight against the compiler.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99548 --- Comment #2 from cqwrteur --- (In reply to Andrew Pinski from comment #1) > For aarch64 we get: > ldp x4, x3, [x1] > mov x7, 38 > ldp x6, x5, [x2] > ldr x8, [x1, 16] > add x6, x4, x6

[Bug c++/99582] New: No intrinsics to access rcl or rcr instruction on x86_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99582 Bug ID: 99582 Summary: No intrinsics to access rcl or rcr instruction on x86_64 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priori

[Bug target/99582] No intrinsics to access rcl or rcr instruction on x86_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99582 --- Comment #2 from cqwrteur --- (In reply to Richard Biener from comment #1) > ROR can be open-coded, GCC tries hard to detect common patterns. > > RCR is difficult because it involves the carry flag and thus the carry > producer > would have t

[Bug c++/99677] New: [[gnu::const]] attribute does not prevent dead global variable gets emitted.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99677 Bug ID: 99677 Summary: [[gnu::const]] attribute does not prevent dead global variable gets emitted. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: nor

[Bug c++/99677] [[gnu::const]] attribute does not prevent dead global variable gets emitted.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99677 --- Comment #1 from cqwrteur --- Here is the GCC. it emits code of dead global variables https://godbolt.org/z/oWddaf

[Bug c++/99677] [[gnu::const]] attribute does not prevent dead global variable gets emitted.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99677 --- Comment #2 from cqwrteur --- Even with [[gnu::pure]] clang does not emit code either. https://godbolt.org/z/e4sG6r We can see it emits code only when we do not mark the functions are pure. https://godbolt.org/z/s3cEK3 That is not the case f

[Bug c++/99677] [[gnu::const]] attribute does not prevent dead global variable gets emitted.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99677 --- Comment #4 from cqwrteur --- (In reply to Andrew Pinski from comment #3) > I think this is a dup of bug 99456. I do not think so because this has nothing to do with constexpr. better @jakub to see whether he has some solutions.

[Bug c++/99695] New: Cannot static compile with C++ module

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99695 Bug ID: 99695 Summary: Cannot static compile with C++ module Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c++/99456] [11 regression] ABI breakage with some static initialization

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

[Bug c++/99677] [[gnu::const]] attribute does not prevent dead global variable gets emitted.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99677 --- Comment #6 from cqwrteur --- (In reply to Richard Biener from comment #5) > I think Andrew is correct. Note we can't elide "unused" not statically > initialized variables (since the initialization is seen as use). but here the result is alw

[Bug target/99719] New: ICE during RTL pass: pro_and_epilogue on MinGW-w64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99719 Bug ID: 99719 Summary: ICE during RTL pass: pro_and_epilogue on MinGW-w64 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug rtl-optimization/99719] ICE during RTL pass: pro_and_epilogue on MinGW-w64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99719 --- Comment #1 from cqwrteur --- Created attachment 50453 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50453&action=edit Preprocessed file

[Bug target/99719] ICE during RTL pass: pro_and_epilogue on MinGW-w64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99719 --- Comment #3 from cqwrteur --- yes it is a working gcc. it just fails in this specific case since today which i fixes my library. Get Outlook for Android From: rguenth at gcc dot gnu.org

[Bug target/99719] ICE during RTL pass: pro_and_epilogue on MinGW-w64

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

[Bug target/99582] No intrinsics to access rcl or rcr instruction on x86_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99582 --- Comment #4 from cqwrteur --- (In reply to Alexander Monakov from comment #3) > RCL and RCR are supported via microcode sequencer on Intel and involve many > (9) uops on modern AMD, so they are quite slow in comparison to simple > shifts/rotat

[Bug target/99719] ICE during RTL pass: pro_and_epilogue on MinGW-w64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99719 --- Comment #5 from cqwrteur --- (In reply to Richard Biener from comment #2) > Do you have a working GCC version as well? > > Please specify how you configured. Hello. I know why the bug happens. It looks like it is a bug when I use the attri

[Bug target/99719] ICE during RTL pass: pro_and_epilogue on MinGW-w64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99719 --- Comment #7 from cqwrteur --- (In reply to Eric Botcazou from comment #6) > > However, it looks like swapping to ms_abi from sysv_abi will cleanup SIMD > > registers. Is that correct? > > Fiddling with the ABI is highly discouraged in anythin

[Bug target/99719] ICE during RTL pass: pro_and_epilogue on MinGW-w64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99719 --- Comment #8 from cqwrteur --- (In reply to cqwrteur from comment #7) > (In reply to Eric Botcazou from comment #6) > > > However, it looks like swapping to ms_abi from sysv_abi will cleanup SIMD > > > registers. Is that correct? > > > > Fiddl

[Bug libstdc++/99789] New: std::span or std::string_view are not zero-overhead on MS abi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 Bug ID: 99789 Summary: std::span or std::string_view are not zero-overhead on MS abi Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal P

[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #2 from cqwrteur --- Created attachment 50476 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50476&action=edit demo source file

[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #3 from cqwrteur --- Created attachment 50477 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50477&action=edit demo assembly

[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #4 from cqwrteur --- (In reply to Jakub Jelinek from comment #1) > And what can libstdc++ do about that? > Just use a different OS with better ABIs... Well, I tested that with Rust on windows, the parameters are passed by registers.

[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #5 from cqwrteur --- (In reply to Jakub Jelinek from comment #1) > And what can libstdc++ do about that? > Just use a different OS with better ABIs... I use a lot of different systems. FreeBSD, MSDOS, Linux, Windows, etc. Using diffe

[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #7 from cqwrteur --- (In reply to Jonathan Wakely from comment #6) > Users of your library on Window will be affected by the ABI on Windows. > That's not a libstdc++ problem. > > Nobody said that std::span and std::string_view are gu

[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #9 from cqwrteur --- (In reply to Jakub Jelinek from comment #8) > Bugzilla is for reporting bugs, not for general programming advices. > > There is no bug here, the C++ standard for 64-bit architectures with its > requirements on st

[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #11 from cqwrteur --- (In reply to Jonathan Wakely from comment #10) > We don't want the assembly file. If you want to investigate what Rust does, > you are free to do that. But stop asking us to do that for you. There is no > GCC bug

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

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

[Bug libgcc/99962] New: Error: unknown mnemonic `type' -- `type(_init)' for crti.s, targetting aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99962 Bug ID: 99962 Summary: Error: unknown mnemonic `type' -- `type(_init)' for crti.s, targetting aarch64 Product: gcc Version: unknown Status: UNCONFIRMED Severity

[Bug libgcc/99962] Error: unknown mnemonic `type' -- `type(_init)' for crti.s, targetting aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99962 --- Comment #1 from cqwrteur --- i manually replace the macros with code and it worrks.

[Bug libgcc/99964] New: android(bionic) cannot find crti.o and crtn.o

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 Bug ID: 99964 Summary: android(bionic) cannot find crti.o and crtn.o Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: l

[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 --- Comment #2 from cqwrteur --- (In reply to Jim Wilson from comment #1) > (In reply to cqwrteur from comment #0) > > bionic simply does not provide crti.o and crtn.o > > https://github.com/aosp-riscv/platform_bionic/tree/master/libc/arch-common

[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 --- Comment #3 from cqwrteur --- (In reply to Jim Wilson from comment #1) > (In reply to cqwrteur from comment #0) > > bionic simply does not provide crti.o and crtn.o > > https://github.com/aosp-riscv/platform_bionic/tree/master/libc/arch-common

[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 --- Comment #4 from cqwrteur --- (In reply to cqwrteur from comment #3) > (In reply to Jim Wilson from comment #1) > > (In reply to cqwrteur from comment #0) > > > bionic simply does not provide crti.o and crtn.o > > > https://github.com/aosp-ris

[Bug libgcc/99962] Error: unknown mnemonic `type' -- `type(_init)' for crti.s, targetting aarch64

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

[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 --- Comment #5 from cqwrteur --- (In reply to Jim Wilson from comment #1) > (In reply to cqwrteur from comment #0) > > bionic simply does not provide crti.o and crtn.o > > https://github.com/aosp-riscv/platform_bionic/tree/master/libc/arch-common

[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64

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

[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 --- Comment #8 from cqwrteur --- (In reply to Marek Polacek from comment #7) > Why do you keep adding Jakub to CC? He's not a mingw maintainer. This is not mingw issue. it is libgcc's issue.

[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 --- Comment #9 from cqwrteur --- (In reply to Marek Polacek from comment #7) > Why do you keep adding Jakub to CC? He's not a mingw maintainer. You get the same error on Linux hosted system too because gcc needs to find crti.o and crtn.o for aa

[Bug libgomp/99984] New: bootstrap failure on uclibc for libgomp. error: 'local_thr' may be used uninitialized [-Werror=maybe-uninitialized]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99984 Bug ID: 99984 Summary: bootstrap failure on uclibc for libgomp. error: 'local_thr' may be used uninitialized [-Werror=maybe-uninitialized] Product: gcc Version: u

[Bug libgomp/99984] bootstrap failure on uclibc for libgomp. error: 'local_thr' may be used uninitialized [-Werror=maybe-uninitialized]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99984 --- Comment #1 from cqwrteur --- Created attachment 50533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50533&action=edit Demo patch I tried to initialize this struct in libgomp and the build of GCC succeed. Strange. I do not know what's

[Bug libgomp/99984] bootstrap failure on uclibc for libgomp. error: 'local_thr' may be used uninitialized [-Werror=maybe-uninitialized]

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

[Bug libgomp/99984] bootstrap failure on uclibc for libgomp. error: 'local_thr' may be used uninitialized [-Werror=maybe-uninitialized]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99984 --- Comment #5 from cqwrteur --- (In reply to Martin Sebor from comment #4) > The following Glibc bug calls for suppressing the warning by adding > attribute access none to the function declaration: > https://sourceware.org/bugzilla/show_bug.cgi?

[Bug c++/100012] New: MSDOS DJGPP host no socket while libcody does not block this

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100012 Bug ID: 100012 Summary: MSDOS DJGPP host no socket while libcody does not block this Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug c++/100012] MSDOS DJGPP host no socket while libcody does not block this

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100012 --- Comment #1 from cqwrteur --- Created attachment 50542 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50542&action=edit disable networking on MSDOS

[Bug bootstrap/100013] New: libiberty error PATH_MAX does not exist on DJGPP host.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100013 Bug ID: 100013 Summary: libiberty error PATH_MAX does not exist on DJGPP host. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 C

[Bug bootstrap/100013] libiberty error PATH_MAX does not exist on DJGPP host.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100013 cqwrteur changed: What|Removed |Added Target||i586-msdosdjgpp Host|

[Bug bootstrap/100013] libiberty error PATH_MAX does not exist on DJGPP host.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100013 --- Comment #2 from cqwrteur --- https://sourceware.org/bugzilla/show_bug.cgi?id=27716

[Bug target/100014] New: MSDOS DJGPP host endian unknown

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100014 Bug ID: 100014 Summary: MSDOS DJGPP host endian unknown Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug target/100015] New: MSDOS DJGPP host build mallinfo was not declared

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100015 Bug ID: 100015 Summary: MSDOS DJGPP host build mallinfo was not declared Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Compone

[Bug target/100015] MSDOS DJGPP host build mallinfo was not declared

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100015 --- Comment #1 from cqwrteur --- Created attachment 50543 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50543&action=edit Demo patch

[Bug c++/100012] MSDOS DJGPP host no socket while libcody does not block this

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100012 --- Comment #2 from cqwrteur --- Created attachment 50544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50544&action=edit there are more issues related to this I think the problem is that DJGPP toolchain defines __unix__ macro while it i

[Bug c++/100012] MSDOS DJGPP host no socket while libcody does not block this

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100012 --- Comment #3 from cqwrteur --- Created attachment 50545 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50545&action=edit libgcov should include

[Bug libgcc/100016] New: multilib mingw-w64 links to the wrong multilib path because of libtool

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100016 Bug ID: 100016 Summary: multilib mingw-w64 links to the wrong multilib path because of libtool Product: gcc Version: unknown Status: UNCONFIRMED Severity: norm

[Bug target/100016] multilib mingw-w64 links to the wrong multilib path because of libtool

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100016 --- Comment #1 from cqwrteur --- BTW. ucrt multilib should also provide as an option I think. m32 m64 mucrt32 mucrt64

[Bug libstdc++/100017] New: error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 Bug ID: 100017 Summary: error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build Product: gcc Version: 11.0 Status: UNCONFIRM

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #1 from cqwrteur --- I tried to build a full host GCC toolchain from Linux to Windows and fenv_t does not exist.

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

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

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

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

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #4 from cqwrteur --- (In reply to cqwrteur from comment #2) > not a bug it looks like it is a bug here.

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #5 from cqwrteur --- Created attachment 50548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50548&action=edit linux build, FreeBSD host, Windows target The error still exists. It looks MSVCRT does not always define those C11

[Bug target/100023] New: apple target cross compilation: fails configure: error: cannot compute suffix of object files: cannot compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100023 Bug ID: 100023 Summary: apple target cross compilation: fails configure: error: cannot compute suffix of object files: cannot compile Product: gcc Version: 11.0

[Bug target/100023] apple target cross compilation: fails configure: error: cannot compute suffix of object files: cannot compile

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

[Bug bootstrap/100026] New: cross GCC from clang fails: configure: error: *** A compiler with support for C++11 language features is required.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100026 Bug ID: 100026 Summary: cross GCC from clang fails: configure: error: *** A compiler with support for C++11 language features is required. Product: gcc Version:

[Bug bootstrap/100026] cross build GCC from clang fails: configure: error: *** A compiler with support for C++11 language features is required.

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

[Bug libstdc++/100057] New: There are no freestanding C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057 Bug ID: 100057 Summary: There are no freestanding C++ Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

[Bug libstdc++/100057] There are no freestanding C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057 --- Comment #1 from cqwrteur --- The funny stuff is that __STDC_HOSTED__ should not be set as true. I guess GCC incorrectly mark __STDC_HOSTED__ as 1 for C++, even we live in freestanding environment. #ifndef _GCC_WRAP_STDINT_H #if __STDC_HOSTE

[Bug libstdc++/100057] There are no freestanding C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057 --- Comment #2 from cqwrteur --- Then #if 0 the header. checking for stdalign.h... no checking for the value of EOF... configure: error: computing EOF failed make[1]: *** [Makefile:13313: configure-target-libstdc++-v3] Error 1 make[1]: Leaving

[Bug libstdc++/100057] There are no freestanding C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057 --- Comment #3 from cqwrteur --- Created attachment 50575 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50575&action=edit The log file shows it does check stdio.h conftest.c:10:10: fatal error: stdio.h: No such file or directory 10 |

[Bug libstdc++/100057] There are no freestanding C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057 --- Comment #4 from cqwrteur --- Try that without --with-newlib. checking how to hardcode library paths into programs... immediate checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [Ma

[Bug libstdc++/100057] There are no freestanding C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057 --- Comment #7 from cqwrteur --- I think the libstdc++'s scripting issue I can fix it.

[Bug libstdc++/100057] There are no freestanding C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057 --- Comment #8 from cqwrteur --- Created attachment 50576 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50576&action=edit Disable checking these macros with freestanding settings We predefine them if they do not exist in Freestanding.

[Bug libstdc++/100057] There are no freestanding C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057 --- Comment #9 from cqwrteur --- looking for a compliant stdint.h in stdint.h, checking for uintmax_t... no looking for a compliant stdint.h in inttypes.h, checking for uintmax_t... no looking for a compliant stdint.h in sys/inttypes.h, checking

[Bug libstdc++/100057] There are no freestanding C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057 --- Comment #10 from cqwrteur --- I guess nobody ever tries to build freestanding before. It just does not work tbh.

  1   2   3   4   5   6   7   8   9   >