[Bug c++/108290] New: QoI: bind_front captureless lambda is too big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108290
Bug ID: 108290
Summary: QoI: bind_front captureless lambda is too big
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lichray at gmail dot com
Target Milestone: ---
libstdc++ does not give the following guarantee, while libc++ and MS STL can:
auto captureless = [](FILE *, void *, size_t) { return 0; };
static_assert(sizeof(std::bind_front(captureless, stdin)) ==
sizeof(stdin));
See https://godbolt.org/z/TrWP6KohG
The expectation is that some form of EBO is implemented to treat the empty
callable as the base. libc++ did this by laying down all state entities in a
std::tuple. MS STL did this by storing compressed_pair> (so they have this optimization even when their
std::tuple doesn't do EBO).
[Bug c++/71954] template partial specialization for constexpr error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71954
Zhihao Yuan changed:
What|Removed |Added
CC||lichray at gmail dot com
--- Comment #5 from Zhihao Yuan ---
Please fix. The workaround is to write
struct Struct {
template
constexpr static bool use_cond = false;
};
template
constexpr bool Struct::use_cond = true;
But when the enclosing context is a class template, writing such a partial
specialization will be very tedious.
[Bug c++/97198] __is_constructible(int[], int) should return true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198 --- Comment #8 from Zhihao Yuan --- (In reply to Jonathan Wakely from comment #7) > (In reply to Zhihao Yuan from comment #5) > > Encountered this today. In case I cannot show up when discussing LWG3486, my > > use case is that C(in_place_type, a, b, c) should "just works." It's up > > to C how to deal with it. In my case, it's new T[]. > > I was going to add a note to the issue, but I don't know what to add. What > is C? Why wouldn't it work today? Why does std::is_constructible affect it? I meant to let C stand for some type C's constructor here. I wanted to express the following: in_place_type is often used by type-erasures to forward all information that is expression-equivalent to some form of initialization. Let's say I want to create an object of type C with C obj(in_place_type, a, b, c); where obj erases the type of a hypothetical object created in U x(a, b, c); Because type erasure means to erase the U in in_place_type, it doesn't matter if U != decltype(x). It works according to the literal interpretation of the standard today. But if we say std::is_constructible_v == false, extra efforts are needed to restore the meaning of in_place_type.
[Bug c++/97198] __is_constructible(int[], int) should return true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198 Zhihao Yuan changed: What|Removed |Added CC||lichray at gmail dot com --- Comment #5 from Zhihao Yuan --- Encountered this today. In case I cannot show up when discussing LWG3486, my use case is that C(in_place_type, a, b, c) should "just works." It's up to C how to deal with it. In my case, it's new T[].
[Bug c++/104653] New: Derived class looks for a definition of its inherited constexpr virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104653
Bug ID: 104653
Summary: Derived class looks for a definition of its inherited
constexpr virtual destructor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lichray at gmail dot com
Target Milestone: ---
The following -std=c++20 code fails to compile:
#include
struct B {
virtual ~B() = default;
};
struct D : B {};
struct C : B {};
bool foo(std::byte *p) {
constexpr D obj;
return __builtin_memcmp(p, , sizeof(void *)) == 0;
}
: In function 'bool foo(std::byte*)':
:12:17: error: 'virtual constexpr D::~D()' used before its definition
12 | constexpr D obj;
| ^~~
The code compiles in MSVC 19.29 and Clang 10.
GCC seems to understand that D inherited a defaulted, constexpr virtual
destructor, but reports that it needs a definition. The problem doesn't arise
if D is dependent. A workaround is the following:
struct D : B {
virtual constexpr ~D() override;
};
constexpr D::~D() = default;
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 Zhihao Yuan changed: What|Removed |Added CC||lichray at gmail dot com --- Comment #11 from Zhihao Yuan --- The example in this bug is not as severe and frequent as the one in bug 44841. Users are more likely to encounter this issue when adding a new API to existing interface or type erasure. Calling this a "well-known issue" is irresponsible. The issue significantly increases the bar to learners to consume and accept new paradigms in the language. The issue has not been fixed for ten years. It is a shame rather than some arcane knowledge that worth to be proud of. MSVC has no such issue. The error message reads as "undefined reference to Class::that_virtual_function." Some possible fixes: 1. Adjust the error message to say, "The first non-inline, non-pure function may not have a definition in ." 2. Add extra information to name the key function, and pass it to the linker, generate an error message to match MSVC's quality.
[Bug c++/90190] New: [8/9 regression] CTAD confuses with {one element} initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90190
Bug ID: 90190
Summary: [8/9 regression] CTAD confuses with {one element}
initializer_list
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lichray at gmail dot com
Target Milestone: ---
Created attachment 46213
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46213=edit
test case
https://godbolt.org/z/f8rKSG
#include
#include
enum class X {};
struct Term {
double a;
X i;
};
template
struct sum {
sum(std::initializer_list) {}
};
int main() {
auto c2 = sum{{1, X()}, {2, X()}};
auto c1 = sum{{1, X()}}; // fails only this
auto c0 = sum{{}};
}
:18:25: note: cannot convert '{1, (X)0}' (type '') to type 'std::initializer_list'
auto c1 = sum{{1, X()}};
-- It's certainly convertible if you add <>.
Works in GCC 7, MSVC, Clang.
[Bug c++/84849] Ambiguous resolution of braze initializer list to a class with explicit constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84849
Zhihao Yuan changed:
What|Removed |Added
CC||lichray at gmail dot com
--- Comment #6 from Zhihao Yuan ---
Here is a possibly related case:
#include
template
struct pair
{
using value_type = pair>;
T a, b;
constexpr pair& operator=(value_type const& other)
{
a = other.a;
b = other.b;
return *this;
}
constexpr pair& operator=(value_type&& other)
{
a = std::move(other.a);
b = std::move(other.b);
return *this;
}
};
template
constexpr pair tie(T& a, T& b) noexcept
{
return { a, b };
}
int main()
{
int a = 3;
int b = 5;
tie(a, b) = { b, a % b }; // works
tie(a, b) = { b, a }; // wat
}
Error messages are very similar https://godbolt.org/z/4FSeOO.
[Bug c++/88631] New: CTAD cannot deduce from () value initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88631
Bug ID: 88631
Summary: CTAD cannot deduce from () value initialization
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lichray at gmail dot com
Target Milestone: ---
#include
template
class A {};
// A() -> A<>;
int main()
{
auto x = A(); // #1
auto x2 = A{}; // #2
A y;// #3
}
#1 fails, #2 and #3 succeeds, adding or removing the deduction guide doesn't
matter (thankfully). This causes users not able to write std::less().
[Bug c++/70347] [5.x Regression] default member initializer not picked up by union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70347 --- Comment #1 from Zhihao Yuan --- In c++1y, c++14 modes, not c++11.
[Bug c++/70347] New: [5.x Regression] default member initializer not picked up by union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70347
Bug ID: 70347
Summary: [5.x Regression] default member initializer not picked
up by union
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lichray at gmail dot com
Target Milestone: ---
#include
//struct A {
union A {
int a = 3;
int b;
};
//};
int main() {
A c{};
std::cout << c.a << "\n";
}
Prints 0 in 5.x, 3 in 4.9.2, same for anonymous union.
[Bug c++/66735] [C++14] lambda init-capture fails for const references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66735 Zhihao Yuan changed: What|Removed |Added CC||lichray at gmail dot com --- Comment #3 from Zhihao Yuan --- As the standardization of `std::as_const`, this bug becomes a blocker.
[Bug c++/63192] non-mutable lambda capture by value on reference does not apply const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63192 Zhihao Yuan changed: What|Removed |Added CC||lichray at gmail dot com --- Comment #3 from Zhihao Yuan --- Confirmed, please fix. As the standardization of `std::as_const`, this bug becomes significant.
[Bug c++/63192] non-mutable lambda capture by value on reference does not apply const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63192 --- Comment #4 from Zhihao Yuan --- (In reply to Zhihao Yuan from comment #3) > Confirmed, please fix. As the standardization of `std::as_const`, this bug > becomes significant. Never mind, I will create another bug report to demonstrate my issue (very likely to have the same cause but with different result).
[Bug libstdc++/68925] New: uniform_int_distribution needs not to be thread_local in std::experimental::randint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68925 Bug ID: 68925 Summary: uniform_int_distribution needs not to be thread_local in std::experimental::randint Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lichray at gmail dot com Target Milestone: --- libstdc++'s uniform_int_distribution is stateless, thus just return _Dist(a, b)(_S_randint_engine()); will do the work, and produces more compact binary.
[Bug c++/56480] Explicit specialization in a namespace enclosing the specialized template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480 Zhihao Yuan lichray at gmail dot com changed: What|Removed |Added CC||lichray at gmail dot com --- Comment #3 from Zhihao Yuan lichray at gmail dot com --- (In reply to Nathan Ridge from comment #2) (In reply to comment #1) I think this is http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#374 Ah, I see. The code is accepted if a declaration (without definition) of the specialization is placed in the namespace. Didn't realize that. ?? That was the c++03 status, and the new wording (or to a specialization thereof) relaxed this requirement. Has this been implemented?
[Bug libstdc++/58403] New: __normal_iterator triggers odr-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58403 Bug ID: 58403 Summary: __normal_iterator triggers odr-use Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lichray at gmail dot com Some __normal_iterator's operators take `const difference_type`, which triggers odr-use of its argument and results in a linker-error. Both reverse_iterator and move_iterator take `difference_type`, and libc++ does it for its __wrap_iter as well. I think this should be a recommended choice.
[Bug libstdc++/58403] __normal_iterator triggers odr-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58403 --- Comment #2 from Zhihao Yuan lichray at gmail dot com --- Created attachment 30807 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30807action=edit test case
[Bug libstdc++/58403] __normal_iterator triggers odr-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58403 --- Comment #5 from Zhihao Yuan lichray at gmail dot com --- (In reply to Jonathan Wakely from comment #4) Although I see no harm in changing the library to take those arguments by value, the testcase is of course invalid. Can you elaborate?
[Bug libstdc++/58403] __normal_iterator triggers odr-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58403 --- Comment #9 from Zhihao Yuan lichray at gmail dot com --- (In reply to Jonathan Wakely from comment #7) [...] It is unspecified whether it += A::a is an odr-use or not. Well, it's true, but I guess the primary purpose of making containers' iterator implementation-defined is to allow raw pointers instead of to make it harder to use... I think we have the consensus that this is OK to change, though.
[Bug c++/48399] New: gcc46 show error when initializing a static const member with base class's constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48399 Summary: gcc46 show error when initializing a static const member with base class's constructor Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lich...@gmail.com Created attachment 23846 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23846 A sample factory pattern program ~ uname -a FreeBSD compaq.yuetime 8.2-STABLE FreeBSD 8.2-STABLE #0: Mon Mar 14 02:51:28 CDT 2011 root@compaq.yuetime:/usr/obj/usr/src/sys/HOUKAGO amd64 ~ gcc46 -v Using built-in specs. COLLECT_GCC=gcc46 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd8.2/4.6.1/lto-wrapper Target: x86_64-portbld-freebsd8.2 Configured with: ./../gcc-4.6-20110325/configure --disable-nls --libdir=/usr/local/lib/gcc46 --libexecdir=/usr/local/libexec/gcc46 --program-suffix=46 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc46/include/c++/ --with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local --with-system-zlib --disable-libgcj --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc46 --build=x86_64-portbld-freebsd8.2 Thread model: posix gcc version 4.6.1 20110325 (prerelease) (GCC) This problem exists on a snapshot version. Please check whether it exists in the release vesion. Try to compile the program in the attachment, ~ g++46 a.cc a.cc:20:15: error: uninitialized const 'Derived::kInstance' [-fpermissive] a.cc:9:7: note: 'const class Derived' has no user-provided default constructor But actually, it has a inherited constructor, and it's safe. This problem makes gcc46 can not compile firefox4 when -fpermissive is not set.
[Bug c++/48399] gcc46 show error when initializing a static const member with base class's constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48399 --- Comment #3 from Zhihao Yuan lichray at gmail dot com 2011-04-01 11:15:48 UTC --- Fine. Sorry to disturbing you.
