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 #16 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:91e6226f880b048275a7ceedef716e159c7cefd9
commit r11-2720-g91e6226f880b048275a7ceedef716e159c7cefd9
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #15 from Jonathan Wakely ---
(In reply to m.cencora from comment #14)
> Whether Bar is empty class or not is irrelevant for this bug.
No it isn't. Your examples already work for tuples of non-empty classes.
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
> > constructor ill-formed fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #13 from Jonathan Wakely ---
(In reply to m.cencora from comment #12)
> So unless I am missing something, I see no escape hatch for making such
> constructor ill-formed for some types.
Consider:
#include
struct X
{
template
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&&>
>
> Where does it say that?
>
> The fact a co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #11 from Jonathan Wakely ---
> Standard says that if:
> std::is_constructible_v
> then
> std::is_constructible_v, Foo&&>
Where does it say that?
The fact a constructor participates in overload resolution doesn't mean it has
to be w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #10 from Jonathan Wakely ---
No.
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 and PR 93147
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #8 from Jonathan Wakely ---
(In reply to m.cencora from comment #7)
> But I guess to fix this you would have to break ABI (or change C++ standard).
No, we can switch to using a data member with the [[no_unique_address]]
attribute, wh
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() const;
> };
>
> struct tuple : Bar1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #6 from Jonathan Wakely ---
Further reduced:
struct Bar1
{
Bar1(Bar1&&) = delete;
};
struct Foo1
{
operator Bar1() const;
};
struct tuple : Bar1
{
tuple() : Bar1(Foo1{}) { }
};
tuple t;
elide.cc: In constructor 'tuple::tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
Jonathan Wakely changed:
What|Removed |Added
Component|libstdc++ |c++
--- Comment #5 from Jonathan Wakel
13 matches
Mail list logo
