: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code does not compile on any gcc version that supports C++17
standard.
It compiles fine on clang.
While the static asserts pass, we get compilation error on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #1 from m.cencora at gmail dot com ---
Ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #4 from m.cencora at gmail dot com ---
Ping(In reply to Jonathan Wakely from comment #2)
> I guess you're compiling in C++17 mode, but I shouldn't have to guess the
> options you're passing to the compiler. Pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #7 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #6)
> Further reduced:
>
> struct Bar1
> {
> Bar1(Bar1&&) = delete;
> };
>
> struct Foo1
> {
> operator Bar1(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #9 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #8)
> No, we can switch to using a data member with the [[no_unique_address]]
> attribute, which is on my TODO list for gcc-11. See PR 55713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #12 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #11)
> > Standard says that if:
> > std::is_constructible_v
> > then
> > std::is_constructible_v, Foo&&>
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #14 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to m.cencora from comment #12)
> > So unless I am missing something, I see no escape hatch for making such
> > constru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #17 from m.cencora at gmail dot com ---
Ah, I see. I was under the impression, that tuple elements were always stored
as base classes, but now I see that it is only the case if element type is
empty non-final class.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code snippet compiles fine with gcc 9 and earlier, but ICEs on gcc
10.0.0 20191229 (verified on godbolt.org)
#include
struct base
{
std::string bla
++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
using Array = int[];
auto && array = Array { 1, 2, 3 };
decltype(array) differs depending on if it is declared inside function, or
function template.
I.e. following
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code does not compile on any gcc version regardless of chosen C++
standard version, but compiles correctly on clang, msvc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740
--- Comment #1 from m.cencora at gmail dot com ---
Ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259
--- Comment #2 from m.cencora at gmail dot com ---
Ping
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code is miscompiled in C++14 mode and -O2 optimization level.
This works fine when compiled:
- in C++17 mode, or lower optimization level
- on previous gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90858
--- Comment #2 from m.cencora at gmail dot com ---
This bug exists since the beginning of C++11 constexpr support (gcc 4.7).
Here is a reproducer for C++11:
struct Base
{
int a;
template
static constexpr int for_all_data_members(F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91606
--- Comment #6 from m.cencora at gmail dot com ---
Just a wild guess, but maybe it is related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90858 and there it just manifests
itself in compilation error because it is in constexpr context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91606
--- Comment #13 from m.cencora at gmail dot com ---
You can remove my_array from the test case. I put there only to show that using
it instead of std::array allows to workaround the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90858
--- Comment #3 from m.cencora at gmail dot com ---
Ping?
As reporter can I do anything more to move this bug forward?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90858
--- Comment #5 from m.cencora at gmail dot com ---
Nice! Do you plan on backporting the fix to active branches? (all gcc versions
since 4.7 are affected)
++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Hi,
this is a minimal reproducer I could come up with. Compiles fine with clang.
It compiles fine if Foo1 is not nested inside Foo2.
#include
#include
template
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90858
--- Comment #1 from m.cencora at gmail dot com ---
Here is another repoducer, that does not use std::variant:
#include
#include
#include
struct Base
{
int a;
template
static constexpr auto for_all_data_members(F&&a
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
gcc 9 and trunk complains about ambiguous call when constructing or assigning
to f2.
This works fine with gcc 8 or earlier.
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90936
--- Comment #2 from m.cencora at gmail dot com ---
Hmm, if it is expected, shouldn't gcc also report ambiguous call for f1
construction and assignment as well?
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following program does not compile since gcc 6.3
(this looks similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79141)
#include
struct dummy
{
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86751
--- Comment #4 from m.cencora at gmail dot com ---
That was fast, thanks a lot!
Confirming with compiler explorer - this is fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86751
--- Comment #5 from m.cencora at gmail dot com ---
That was fast, thanks a lot!
Confirmed with compiler explorer - this is fixed on trunk.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code does not compile in g++8 and trunk, while it compiles with g++7
and older.
struct Foo
{
enum
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following program fails to compile with latest gcc, while it compiles with gcc
8 and earlier, and with clang as well.
#include
#include
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Hi,
the following code gets properly optimized-out if erasedTypeVTable is
initialized with &dtor (case [2]), but it is not optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70723
--- Comment #2 from m.cencora at gmail dot com ---
If that's the case then it should get automatically resolved once C++17 is
implemented - C++17 introduces constexpr lambdas.
But it would be great to have this optimization also in C++14 mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740
--- Comment #3 from m.cencora at gmail dot com ---
Still broken in gcc 10.2 and trunk, also in C++20 mode.
The problem seems to show up only when address of member function (virtual or
not) is passed as template parameter - only then gcc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259
--- Comment #3 from m.cencora at gmail dot com ---
Still fails on gcc 10.2 and trunk, in all std C++11-20 modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740
--- Comment #4 from m.cencora at gmail dot com ---
I have done some more experiments, and it seems the problem applies to all
pointer-to-member (not just pointer to member function, but also for pointer to
data member).
Also it doesn't matt
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code does not compile on gcc-10 and newer in all std C++14-20 modes.
This used to work in gcc-9 and
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code compiled in any gcc>=5, C++11 or higher, and
-Wmissing-field-initializers generate compiler warning:
g++ -std=c++20 -Wmissing-field-initializ
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
According to http://eel.is/c++draft/class.union#general-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99186
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185
--- Comment #6 from m.cencora at gmail dot com ---
Now that I think about and having read relevant chapters of C++20 spec,
observed behavior seems to be expected.
A cannot be constant initialized (because it has missing initializer for
'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185
--- Comment #8 from m.cencora at gmail dot com ---
It does not matter whether A constructor is default or empty. If class instance
cannot be constant-initialized then dynamic initialization will take place.
I think gcc just incorrectly performs
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
If waiter pool implementation is used in std::atomic::wait/notify for given
T, then notify_one must underneath call notify_all to make sure that proper
thread is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
--- Comment #1 from m.cencora at gmail dot com ---
This test assumes previous waiter implementation (I used gcc-11 available from
Ubuntu 21.04), latest atomic_wait impl has the same problem, it is just that
waiter is selected in a different way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
--- Comment #2 from m.cencora at gmail dot com ---
I have adapted the test to gcc trunk, but I am not entirely sure it is correct,
because I don't have gcc trunk locally, I was just testing this on wandbox.org
The problem is even bigger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
--- Comment #3 from m.cencora at gmail dot com ---
If my analysis is correct then:
- we need to force __all = true param in __waiter_pool_base::_M_notify,
- protect from spurious wakeups in __waiter_pool::_M_do_wait by rechecking if
the value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
--- Comment #5 from m.cencora at gmail dot com ---
Actually standard seems to require it - at least to my understanding of wait()
description in in chapter 31.8.1: it explicitly states that waiting is
performed in a loop, and loop is exited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Code below compiled on any gcc<11 crashes with following output:
during RTL pass: expand
: In function 'Derived ICE_createDerived()':
:37:5: internal c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
--- Comment #1 from m.cencora at gmail dot com ---
The problem seems to occur if base class has a tail padding, and derived class
is trying to reuse it to store its members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
--- Comment #4 from m.cencora at gmail dot com ---
(In reply to Andrew Pinski from comment #3)
> I am 99% sure this is the same issue as pr98995 even though this is a crash.
> The ice is the same as PR 93711.
>
> This code has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
--- Comment #7 from m.cencora at gmail dot com ---
Hmm, ok.
So if I wanted to workaround this in generic code, what kind of types should I
exclude from aggregate initialization? Any type that has a base class with a
tail padding? Or just the
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Gcc trunk on x86-64 produces much worse assembly for 'deserialize' func than
for equivalent 'deserialize2'.
These two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108506
--- Comment #1 from m.cencora at gmail dot com ---
"that is the only difference between the two funcs"
I mean that deserialize and deserialize2 differ only by the way they perform
store from v32uc to output (bit_cast vs memcpy)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108594
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code fails to compile on any gcc version. Works on all clang
versions.
It looks like inside template function get_templ_base the lookup of
v.templ_base::a
++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Given following files:
// main.cpp
using intfunc = int (*)();
intfunc getIntFunc(int i);
namespace
{
int test()
{
auto func = getIntFunc(1);
return func();
}
}
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104597
--- Comment #1 from m.cencora at gmail dot com ---
clang-12 optimizes it to:
Dump of assembler code for function main:
0x00401110 <+0>: mov$0x1,%eax
0x00401115 <+5>: ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104597
--- Comment #2 from m.cencora at gmail dot com ---
Similarly when indirect call is a result of virtual function call, gcc cannot
optimize it, while clang can:
// main.cpp
struct foo
{
virtual int getInt0() const = 0;
virtual int getInt1
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code leads to unnecessary stack spill of deserialized Foo variable:
g++ -std=c++17 -O2
#include
inline unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #4 from m.cencora at gmail dot com ---
I dont think ABI is an issue here. The Foo variable is spilled into stack, and
then reloaded back into RDI register before invoking dummyFunc.
Also clang generates optimal code as can be seen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #5 from m.cencora at gmail dot com ---
I've slighlty refactored the code, to remove the auto variables. This issue
remains
#include
inline unsigned deserializeUInt(const unsigned char* &in)
{
unsigned out;
__built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #6 from m.cencora at gmail dot com ---
Furthermore in all the scenarios the same function is called, with same
arguments, so the calling convention/ABI is same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Compiling following program on any gcc version, with C++14 or newer standard
fails with
"'__builtin_strlen(...)' is not a constant expression" fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740
--- Comment #5 from m.cencora at gmail dot com ---
I think I was able to narrow it down to the true root cause. Following fails in
all gcc versions that supports C++11 and newer:
struct foo
{
void baz();
void bar();
};
static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104302
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259
--- Comment #4 from m.cencora at gmail dot com ---
This might be related to CWG2487 "Type dependence of function-style cast to
incomplete array type"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103563
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Given code below compiled with g++ 11 or newer, compiler should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105592
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following program when compiled with -std=c++17 prints 1243, while it should
print 1234.
All gcc < 12 versions are affected.
#include
struct MyStruct
{
};
struct MyTu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105737
--- Comment #3 from m.cencora at gmail dot com ---
FWIW Ordered evaluation of elements in braced-init-list exists since C++11 (it
was not a part of P0145).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
--- Comment #5 from m.cencora at gmail dot com ---
Yeah, __is_same builtin beats custom unique-id comparisons, but it is available
only since gcc-10 so unavailable for me.
Recently I discovered this one (only works for unique types), and it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111511
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111511
--- Comment #4 from m.cencora at gmail dot com ---
Ack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109482
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109482
--- Comment #8 from m.cencora at gmail dot com ---
Ah, I see that gcc doesn't support nested designated initializer in C++ mode
(compared to C mode, or clang in both C and C++ modes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #11 from m.cencora at gmail dot com ---
Nvm, I understood this rule differently. You are saying that initialization is
two step:
- first zero-initialized,
- then default-initialized.
For me the way this rule is written is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #14 from m.cencora at gmail dot com ---
Yeah, in CWG issue comments it is much more clear - but I cannot find such a
wording in C++ latest draft.
English is not my native language so this one is on me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99637
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109770
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109770
--- Comment #8 from m.cencora at gmail dot com ---
(In reply to Richard Biener from comment #7)
>
> Ah, interesting. I was looking for an answer whether
>
> new T
>
> may produce anything other than an object with dynamic
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
$ cat std.cpp
module;
#include
export module std;
$ cat main.cpp
import std;
#include
int main()
{
}
$ g++ -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #1 from m.cencora at gmail dot com ---
gcc version info:
g++-14 (Ubuntu 14-20240330-1ubuntu2) 14.0.1 20240330 (experimental) [master
r14-9728-g6fc84f680d0]
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #7 from m.cencora at gmail dot com ---
Created attachment 57921
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57921&action=edit
Full "std" module
FYI if you want to stress test the modules impl w.r.t. simila
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
$ cat std.cpp
module;
#include "std.h&quo
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
$ cat lldiv_t.cpp
module;
#include "lldiv_t.h"
export module std;
export namespace std
{
using :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #9 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #8)
> Thanks. I hope we'll end up auto-generating a file like that from
> ../gcc/cp/cxxapi-data.csv
Hmm, then that file will have to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
m.cencora at gmail dot com changed:
What|Removed |Added
Attachment #57921|0 |1
is obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685
--- Comment #1 from m.cencora at gmail dot com ---
Oops, the -isystem and -std options are not necessary for reproduction.
This is enough:
$ g++ -fmodules-ts lldiv_t.cpp
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
$ cat future.cpp
module;
namespace std {
template
void swap(_Tp& a, _Tp& b);
namespace __exception_ptr
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
$ cat mod.cpp
export module mod;
export import :part;
export void foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685
--- Comment #4 from m.cencora at gmail dot com ---
I've stumbled upon a related error when trying to export std::vector after
inclusion of in GMF:
module;
namespace std
{
class vector;
namespace __format {
using std::vector;
}
}
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114867
--- Comment #1 from m.cencora at gmail dot com ---
The unreduced code is actually a regression from gcc-12.
@Jonathan Wakely:
Could you maybe workaround it in libstdc++ by declaring the std::swap overload
for exception_ptr in additional inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110303
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
1 - 100 of 124 matches
Mail list logo
