https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118951
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=117293
--- Comment #8 from m.cencora at gmail dot com ---
(In reply to Patrick Palka from comment #7)
> Substituting U=string into overload_set::type during
> overload resolution certainly has the side effect of instantiating that
> class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #4 from m.cencora at gmail dot com ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I am not sure this is related to SFINAE though.
> >
> > Rather it is in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #6 from m.cencora at gmail dot com ---
Another argument for not showing the deprecation is that if I change:
string a;
to
const string a;
I don't get any deprecation warnings, but only for gcc-11+.
This means that int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #3 from m.cencora at gmail dot com ---
I think it should be marked rejects-valid because it makes valid program
ill-formed if compiled with -Werror. The problematic diagnostic is user-defined
but in code that is never reached, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117293
--- Comment #5 from m.cencora at gmail dot com ---
> I'd say that warning is not expected, because user's code didn't (directly
> or indirectly) call the deprecated constructor.
Or to state it differently: user calls
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
It seems like the deprecation warning is kept even if triggered due to failed
substitution in context of class partial speciali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115798
--- Comment #2 from m.cencora at gmail dot com ---
(In reply to m.cencora from comment #1)
> Also this is specific to types exported from GMF, if type is declared
> directly in named module it works fine, i.e.
>
> $ cat base.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115798
--- Comment #1 from m.cencora at gmail dot com ---
Also this is specific to types exported from GMF, if type is declared directly
in named module it works fine, i.e.
$ cat base.cpp
export module base;
export
{
using int8_t = signed char
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
$ cat base.cpp
module;
#include
export module base;
export
{
using ::int8_t;
}
export namespac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #15 from m.cencora at gmail dot com ---
Thanks!
Unfortunately it seems that your changes broke reexporting of types declared in
other module. It works fine on gcc-14.
$ cat base.cpp
module;
#include
export module base;
export
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852
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=115445
--- Comment #1 from m.cencora at gmail dot com ---
Works fine on gcc-14 and clang
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
$ cat op_new.cpp
module;
void* operator new(unsigned long, void*);
namespace std
{
template
auto construct_at(_Tp*) -> decltype(::new((void*)0) _Tp())
{
ret
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
$ cat repeated_using.cpp
module;
namespace std
{
void make_error_code();
}
export module std;
export namespace std
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=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
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
: 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
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
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=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
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 :
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
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
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
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=113064
--- Comment #11 from m.cencora at gmail dot com ---
This is surprising to say the least because apparently for following code
(where both conversion operators return same type) the compiler somehow
correctly chooses && qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113219
--- Comment #2 from m.cencora at gmail dot com ---
So I guess this falls into the "confusing overload resolution for user-defined
conversion" but I fail to see what can be confusing here.
createInt() returns prvalue, so later it binds
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code when compiled on any gcc version (checked all available on
godbolt since gcc-7) triggers conversion warnings.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #5 from m.cencora at gmail dot com ---
(In reply to m.cencora from comment #4)
> This also might be a just another symptom of the same root cause:
This one is actually a regression (worked on gcc 8.3 and older)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #4 from m.cencora at gmail dot com ---
This also might be a just another symptom of the same root cause:
struct bar
{
bar() = default;
bar(const bar&);
bar(bar&&);
bar& operator=(const bar&);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #2 from m.cencora at gmail dot com ---
> When invoking the conversion operator the problem does not occur.
When invoking the conversion operator *explicitly* the problem does not occur.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #1 from m.cencora at gmail dot com ---
Fixed sample (a typo in else branch of WORKAROUND2):
struct no_copy
{
no_copy() = default;
no_copy(const no_copy&) = delete;
no_copy(no_copy&&);
no_copy&
Severity: normal
Priority: P3
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 with any selected language
version. Works with clang.
When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259
--- Comment #7 from m.cencora at gmail dot com ---
This seems to be fixed in gcc 12.3 and gcc 13+
Can we close this?
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=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=110303
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
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=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=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=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
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=109482
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
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
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)
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=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
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 #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
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=35560
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=107675
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=106567
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=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=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=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).
: 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=105592
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=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=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 #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
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=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
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
++
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=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=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=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=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=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=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=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=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 #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 #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
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=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
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
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=99186
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
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
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
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
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
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 #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=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.
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 #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 #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 #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 #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
1 - 100 of 124 matches
Mail list logo
