https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98471
Bug ID: 98471
Summary: libstdc++ fails to build with clang on windows because
of filesystem bug
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98576
cqwrteur changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98576
--- Comment #3 from cqwrteur ---
(In reply to cqwrteur from comment #2)
> The same issue can be found with any EXEC charset besides UTF-8.
>
> I really hope GCC could provide a macro to let me know what the current
> execution charset is so I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98576
--- Comment #2 from cqwrteur ---
The same issue can be found with any EXEC charset besides UTF-8.
I really hope GCC could provide a macro to let me know what the current
execution charset is so I can output the correct thing under the current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98576
Bug ID: 98576
Summary: std::source_location should return EBCDIC encoding
strings under EBCDIC execution charset charsets
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98576
--- Comment #5 from cqwrteur ---
(In reply to JeanHeyd Meneide from comment #4)
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560784.html
>
> A new version of GCC will include the execution charset and wide execution
> charset as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98359
--- Comment #1 from cqwrteur ---
This patch breaks all platforms it looks like. Even linux has this bug now.
Please fix it asap or it will break everything.
-things like cost calculations or profiling frequencies. The default\n\
+things like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98359
--- Comment #4 from cqwrteur ---
(In reply to Jakub Jelinek from comment #2)
> Maybe fixed by r11-6240-g4a7a3110c70da8bad6978a36d9da3836538a0cc3
Fixed confirm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98359
Bug ID: 98359
Summary: bootstrapping failure on windows
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98362
Bug ID: 98362
Summary: bad file data on Windows for C++ 20 module
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98364
Bug ID: 98364
Summary: C++20 module binary bloat
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98363
Bug ID: 98363
Summary: C++ 20 module ICE for fast_io library
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98363
cqwrteur changed:
What|Removed |Added
CC||unlvsur at live dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98430
--- Comment #1 from cqwrteur ---
inline functions should not emit anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98430
Bug ID: 98430
Summary: C++20 module binary bloat by introducing iostream
silently.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98363
--- Comment #6 from cqwrteur ---
(In reply to Nathan Sidwell from comment #4)
> FWIW I think it premature to start agressively filing these kinds of
> defects. We haven't added the module testsuite yet.
Same issue on Windows. Looks like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98362
cqwrteur changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98374
cqwrteur changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98377
cqwrteur changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98386
--- Comment #1 from cqwrteur ---
Created attachment 49805
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49805=edit
bugged image
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98386
Bug ID: 98386
Summary: C++20 module: file exists failure and success happen
alternatively for windows.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98386
--- Comment #2 from cqwrteur ---
My build of GCC for Windows can be found here.
https://github.com/expnkx/mingw-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98380
Bug ID: 98380
Summary: bootstrapping failure on windows 32bits for libcc1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98380
--- Comment #6 from cqwrteur ---
Created attachment 49801
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49801=edit
stdout logs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98380
--- Comment #5 from cqwrteur ---
Created attachment 49800
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49800=edit
stderr logs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98377
Bug ID: 98377
Summary: bootstrapping failure on windows for floating_to_chars
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98380
--- Comment #4 from cqwrteur ---
D:/msys64/mingw32/lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
../build-i686-w64-mingw32/libcpp/libcpp.a(lex.o):lex.c:(.text+0x8): undefined
reference to `LC0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98380
--- Comment #1 from cqwrteur ---
It works for 64 bit windows but failed for 32 bit windows. I do not know why. I
could build this tomorrow but now it failed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98380
--- Comment #3 from cqwrteur ---
Build again. still fails on 32 bits but succ on 64 bits. do not know why.
checking that generated files are newer than configure... done
configure: creating ./config.status
/bin/sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98380
cqwrteur changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98364
--- Comment #3 from cqwrteur ---
Created attachment 49824
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49824=edit
just compile them and link together to see assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98364
--- Comment #5 from cqwrteur ---
(In reply to cqwrteur from comment #3)
> Created attachment 49824 [details]
> just compile them and link together to see assembly.
compilation command
g++ -o main main.cc hello.cc -Ofast -std=c++20 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98364
--- Comment #4 from cqwrteur ---
(In reply to Nathan Sidwell from comment #2)
> Is this windows-specific? please privode preprocessed source and compilation
> command.
no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98422
Bug ID: 98422
Summary: C++ 20 module ICE with lto
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98364
--- Comment #6 from cqwrteur ---
(In reply to Nathan Sidwell from comment #2)
> Is this windows-specific? please privode preprocessed source and compilation
> command.
You need to just compile the code and then use objdump to view generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98364
--- Comment #7 from cqwrteur ---
Created attachment 49825
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49825=edit
header only naive version
g++ -o naive naive.cc -Ofast -std=c++20 -s -flto
compile both of them and compare assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98386
--- Comment #5 from cqwrteur ---
(In reply to Nathan Sidwell from comment #4)
> Created attachment 49823 [details]
> test patch
>
> This does an unlink before the rename, and also adds more logging. If it
> fails, please try with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98386
--- Comment #6 from cqwrteur ---
(In reply to Nathan Sidwell from comment #3)
> Hm does rename(2) fail on windows if the new name exists? (in posix it
> replaces, otherwise there's gonna be a race condition)
well. tbh, on windows, the safest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98386
--- Comment #8 from cqwrteur ---
(In reply to Nathan Sidwell from comment #7)
> Please take your diatribes to /dev/null. Are you able to test the patch?
Wait a second. I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98386
--- Comment #9 from cqwrteur ---
(In reply to Nathan Sidwell from comment #7)
> Please take your diatribes to /dev/null. Are you able to test the patch?
fixed confirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98362
--- Comment #5 from cqwrteur ---
Created attachment 49798
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49798=edit
Compilation Working patch. Tested on both x86_64-linux-gnu and
mingw-w64-x86_64-windows10
This also adds the support for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98374
Bug ID: 98374
Summary: No #include on windows. Bootstrapping
failure
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98363
--- Comment #5 from cqwrteur ---
(In reply to Nathan Sidwell from comment #4)
> FWIW I think it premature to start agressively filing these kinds of
> defects. We haven't added the module testsuite yet.
No problem. I will keep helping you. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98362
--- Comment #3 from cqwrteur ---
(In reply to Nathan Sidwell from comment #2)
> Created attachment 49797 [details]
> test patch
>
> care to try this?
Sure
BTW. Windows do provide a flag O_NOINHERIT which matches O_CLOSEXEC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98362
--- Comment #4 from cqwrteur ---
(In reply to Nathan Sidwell from comment #2)
> Created attachment 49797 [details]
> test patch
>
> care to try this?
I will modify your patch and try to support O_CLOSEXEC on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98374
--- Comment #5 from cqwrteur ---
(In reply to Jonathan Wakely from comment #4)
> Please stop adding random unrelated people to the CC list of your bugs.
bugs for libstdc++. CC you. What's wrong with it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98471
--- Comment #6 from cqwrteur ---
(In reply to Jonathan Wakely from comment #5)
> Should be fixed now.
thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98696
Bug ID: 98696
Summary: ICE when build x86_64-elf-cross compiler with
MinGW-w64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98471
--- Comment #1 from cqwrteur ---
Is this possible to fix? Is that anything wrong with the patch I provided?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98696
--- Comment #4 from cqwrteur ---
(In reply to David Malcolm from comment #3)
> Created attachment 49976 [details]
> Patch to fix the failing selftest
>
> Does the attached patch fix the build on Windows hosts?
Thank you it is working now. You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98471
--- Comment #3 from cqwrteur ---
(In reply to Jonathan Wakely from comment #2)
> The bug is already assigned to me so I get emailed about all updates to the
> bug, so stop CCing my other email addresses.
>
> Being annoying does not persuade me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98895
Bug ID: 98895
Summary: C++ module generates too many dead code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98895
cqwrteur changed:
What|Removed |Added
Target||All
Host|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
cqwrteur changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #8 from cqwrteur ---
(In reply to Marek Polacek from comment #6)
> I don't think this is a useful bug report. If/when the proposal gets
> accepted, it will be useful to track who's working on it, but until then I
> see no point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #11 from cqwrteur ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to cqwrteur from comment #3)
> > Relying on stdio.h even stdio.h is not freestanding.
>
> Nonsense.
>
> (In reply to cqwrteur from comment #4)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #14 from cqwrteur ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to cqwrteur from comment #11)
> > Functions without thread-safety are always terrible. Like all functions in
> > cctype. They should be avoided like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #20 from cqwrteur ---
(In reply to Jonathan Wakely from comment #19)
> (In reply to cqwrteur from comment #16)
> > That does not work in the real-world since your libstdc++'s freestanding
> > header never works correctly, (you get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #24 from cqwrteur ---
(In reply to Jonathan Wakely from comment #22)
> (In reply to cqwrteur from comment #20)
> > 1. Freestanding C++ in the current situation is very problematic. (You do
> > not have memcpy, you do not have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #29 from cqwrteur ---
(In reply to Jakub Jelinek from comment #23)
> And memcpy must be provided as documented in the GCC documentation:
> Most of the compiler support routines used by GCC are present in
> @file{libgcc}, but there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #30 from cqwrteur ---
> Great. So build with --disable-libstdcxx-verbose as well and stop
> complaining about a feature that other people find useful.
But even GCC bootstraps itself with EH, RTTI disabled (of course you are not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #3 from cqwrteur ---
After revert to the previous commit. Compilation success
https://github.com/gcc-mirror/gcc/commit/bfab355012ca0f5219da8beb04f2fdaf757d34b7
I think it has to do with the script you changed, Jakub.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #4 from cqwrteur ---
Created attachment 50071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50071=edit
bootstrap failure picture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #5 from cqwrteur ---
I do not know whether it has to do with the CRLF issue because GCC on Linux
emits the same result as it does on MinGW-w64 or msys2.
conftextx.c
#ifdef __x86_64__
#ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #1 from cqwrteur ---
The question is that why it says we are not cross-compiling? I am using the
same script I used before.
https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/PKGBUILD
It is so weird.
checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #2 from cqwrteur ---
I guess is because of this commit
https://github.com/gcc-mirror/gcc/commit/0411ae7f08e0f5a8b02ff313d26d27a0f6d1bb34
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0411ae7f08e0f5a8b02ff313d26d27a0f6d1bb34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
Bug ID: 98861
Summary: I want deterministic exceptions (Herbception)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
Bug ID: 98860
Summary: boostrap failure on MinGW-w64 windows 10
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #7 from cqwrteur ---
configure:3736: $? = 0
configure:3725: /home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #8 from cqwrteur ---
I tried to build this commit and it is successful.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0411ae7f08e0f5a8b02ff313d26d27a0f6d1bb34
which means it is another commit that breaks it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #6 from cqwrteur ---
configure:4069: ./conftest.exe
/home/unlvs/mcf_build/src/gcc-git/libgomp/configure: line 4071: ./conftest.exe:
cannot execute binary file: Exec format error
configure:4073: $? = 126
configure:4080: error: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #13 from cqwrteur ---
$ as --version
GNU assembler (GNU Binutils) 2.35.1
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #9 from cqwrteur ---
I tried to build this commit and it is successful.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0411ae7f08e0f5a8b02ff313d26d27a0f6d1bb34
which means it is another commit that breaks it.
Daily bump of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #11 from cqwrteur ---
(In reply to Jakub Jelinek from comment #10)
> In that range guess the only important change was the switch from -gdwarf-4
> to -gdwarf-5 by default. So either a bug in your assembler or linker or
> something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #14 from cqwrteur ---
(In reply to Jakub Jelinek from comment #12)
> So you need to figure it out, most people here don't have any access to
> Windows.
> If mingw64 is using binutils, there were important DWARF 5 related bugs in
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #2 from cqwrteur ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to cqwrteur from comment #0)
> > The mailing list requires me to request the feature here. I put it here.
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #3 from cqwrteur ---
> Ridiculous claims like "totally unusable" aren't going to convince anybody.
It is totally unusable. Binary bloat of runtime in bare-metal systems. Relying
on stdio.h even stdio.h is not freestanding.
C++ EH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #4 from cqwrteur ---
(In reply to cqwrteur from comment #3)
> > Ridiculous claims like "totally unusable" aren't going to convince anybody.
>
> It is totally unusable. Binary bloat of runtime in bare-metal systems.
> Relying on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #5 from cqwrteur ---
(In reply to cqwrteur from comment #4)
> (In reply to cqwrteur from comment #3)
> > > Ridiculous claims like "totally unusable" aren't going to convince
> > > anybody.
> >
> > It is totally unusable. Binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #27 from cqwrteur ---
> But portable code can't rely on deterministict exceptions either, yet you
> insist that it's essential and you can't live without it. It seems you're
> quite happy to rely on non-standard things when it suits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #25 from cqwrteur ---
> > 1. Freestanding C++ in the current situation is very problematic. (You do
> > not have memcpy, you do not have std::move. You do not have std::forward.
> > You do not have std::addressof(). you do not have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #18 from cqwrteur ---
I can confirm it is the commit that breaks the bootstrap on windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #19 from cqwrteur ---
After reverting the change, the compilation succeeds. However, this is a
temporary solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #12 from cqwrteur ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to cqwrteur from comment #3)
> > Relying on stdio.h even stdio.h is not freestanding.
>
> Nonsense.
stdio.h should not get included in any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #7 from cqwrteur ---
(In reply to Marek Polacek from comment #6)
> I don't think this is a useful bug report. If/when the proposal gets
> accepted, it will be useful to track who's working on it, but until then I
> see no point.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #16 from cqwrteur ---
(In reply to Jonathan Wakely from comment #15)
> > > (In reply to cqwrteur from comment #12)
> > > > stdio.h should not get included in any circumstances for EH. You are
> > > > implementing the operating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #17 from cqwrteur ---
(In reply to Jonathan Wakely from comment #15)
> > > (In reply to cqwrteur from comment #12)
> > > > stdio.h should not get included in any circumstances for EH. You are
> > > > implementing the operating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #28 from cqwrteur ---
(In reply to cqwrteur from comment #27)
> > But portable code can't rely on deterministict exceptions either, yet you
> > insist that it's essential and you can't live without it. It seems you're
> > quite happy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101093
Bug ID: 101093
Summary: C++20 Module ICE cannot define 'enum class
std::align_val_t' in different module
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100959
Bug ID: 100959
Summary: -fuse-ld=lld does not work when -flto is enabled
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101136
--- Comment #1 from cqwrteur ---
However, std::basic_string_view works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101136
Bug ID: 101136
Summary: msdosdjgpp toolchain cannot find std::wstring_view
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101183
Bug ID: 101183
Summary: gcc mingw for precompiled header file.
MapViewOfFileEx: Attempt to access invalid address.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101183
--- Comment #2 from cqwrteur ---
(In reply to Andrew Pinski from comment #1)
> Dup of bug 91440.
>
> https://github.com/msys2/MINGW-packages/issues/5719
>
> So you have to manually setdllcharacteristics on cc1.exe and cc1plus.exe
>
> ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
Bug ID: 101197
Summary: __builtin_memmove does not perform constant
optimizations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100663
Bug ID: 100663
Summary: dietlibc build fail 'FP_NAN' was not declared in this
scope
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100598
--- Comment #3 from cqwrteur ---
I've seen the same issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100726
--- Comment #7 from cqwrteur ---
(In reply to cqwrteur from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > (In reply to Andrew Pinski from comment #2)
> > > I really doubt anything before Windows XP is supported really.
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100726
--- Comment #6 from cqwrteur ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Andrew Pinski from comment #2)
> > I really doubt anything before Windows XP is supported really.
>
> I have no interest in making the filesystem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100726
cqwrteur changed:
What|Removed |Added
CC||unlvsur at live dot com
--- Comment #3 from
1 - 100 of 784 matches
Mail list logo
