https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86476
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115514
Bug ID: 115514
Summary: Nonconforming reverse_iterator::operator->
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
Bug ID: 111357
Summary: __integer_pack fails to work with values of dependent
type convertible to integers
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110844
Bug ID: 110844
Summary: LTO sometimes fail with -save-temp -dumpdir options
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240
--- Comment #9 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #8)
> I don't think that's true. If __GXX_MERGED_TYPEINFO_NAMES is true then the
> out-of-line definition is correct. You can't just redefine that mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240
--- Comment #7 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #6)
> What are the mangled type names that are unordered? (that's all you need to
> describe, everything about flat_map and partition_point is irrelev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240
--- Comment #5 from frankhb1989 at gmail dot com ---
There are multiple issues.
1. The out-of-line definition and the inline definition of
std::type_info::before do different things. Specifically, only one name is
detected against to '*' in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108771
Bug ID: 108771
Summary: Incorrect noexcept for merging in
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107189
Bug ID: 107189
Summary: Inconsistent range insertion implementations in
std::_Rb_tree in
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104191
--- Comment #4 from frankhb1989 at gmail dot com ---
Well, surrendering at the possibility of huge amount of node allocations,
because there is LWG 2794. (I'd complain this is over-restrictive and pure loss
of functionality for allocators used on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104191
--- Comment #2 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to frankhb1989 from comment #0)
> > and it should be solely determined by the internal node count type.
>
> What is the internal node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104191
Bug ID: 104191
Summary: Incorrect max_size() for node-based containers
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92137
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937
--- Comment #10 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to frankhb1989 from comment #7)
> The toolchain might not be ELF-specific, but
> on targets that *do* use ELF, of course the ELF speci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100682
Bug ID: 100682
Summary: Outdated manual about the debug mode using
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100472
Bug ID: 100472
Summary: [C++17] Wrong template non-type argument handling on
function reference to noexcept functions
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
--- Comment #8 from frankhb1989 at gmail dot com ---
The first diagnostic message of `#pragma GCC poison __deref` points to
in my MSYS2 installation.
The change is made here:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/555bee806560144c6a590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82955
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
--- Comment #1 from frankhb1989 at gmail dot com ---
To clarify a bit: is installed by the VC++ toolchain or WDK, not by
Windows SDK. Nevertheless, it is a system header both MS's CRT and Win32
headers rely on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
Bug ID: 97362
Summary: __deref in in debug mode clashes with
Windows SDK internal macro
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
26 matches
Mail list logo
