[Bug libstdc++/110990] New: `format_to_n` returns wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110990
Bug ID: 110990
Summary: `format_to_n` returns wrong value
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://godbolt.org/z/4fv71hhGe
#include
#include
int main() {
char buf[10] = "@";
auto result = std::format_to_n(buf, std::size(buf), "a");
std::cout << result.out - buf << '\n';
}
On libstdc++, `result.out - buf` evaluates to 10. I expect it to be 1. Both
libc++ and MSVC STL produce 1.
[Bug c++/109756] New: "internal compiler error: tree check" when using the [[assume]] attribute with pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109756
Bug ID: 109756
Summary: "internal compiler error: tree check" when using the
[[assume]] attribute with pack expansion
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://godbolt.org/z/WPn9aq8sr
bool f(auto... args) {
[[assume(args > 0)...]];
return ((args == 0) && ...);
}
bool g(int a, int b) {
return f(a, b);
}
: In function 'bool f(auto:1 ...)':
:2:28: internal compiler error: tree check: expected tree that contains
'common' structure, have 'expr_pack_expansion' in list_length, at tree.cc:3414
2 | [[assume(args > 0)...]];
|^
0x235945e internal_error(char const*, ...)
???:0
0x96da3a tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
???:0
0xb20632 process_stmt_assume_attribute(tree_node*, tree_node*, unsigned int)
???:0
0xc7212f c_parse_file()
???:0
0xdb0d99 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
I believe that [[assume(args > 0)...]] is a valid pack expansion. The standard
says ([temp.variadic]/5):
> Pack expansions can occur in the following contexts:
> (5.8) - In an attribute-list ([dcl.attr.grammar]); the pattern is an
> attribute.
[Bug libstdc++/105505] New: P1951R1 (Default Arguments for pair's Forwarding Constructor) is unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105505
Bug ID: 105505
Summary: P1951R1 (Default Arguments for pair's Forwarding
Constructor) is unimplemented
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
CC: redi at gcc dot gnu.org
Target Milestone: ---
https://en.cppreference.com/w/cpp/compiler_support claims that P1951R1 (Default
Arguments for pair's Forwarding Constructor) is supported in GCC libstdc++ 12,
but it seems that libstdc++ 12 doesn't actually add default template arguments
for said forwarding constructor.
For example, the following still does not work with libstdc++ (but works with
latest libc++ and MSVC STL: https://godbolt.org/z/6oY3G77oT).
```
#include
struct MoveOnly {
MoveOnly();
MoveOnly(MoveOnly&&);
};
std::pair p{42, {}};
```
[Bug c++/105351] [concepts] Constraint checking does correctly match static member attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105351 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #3 from ensadc at mailnesia dot com --- I believe that `T::attr2` is a valid expression when it appears in a requirement. So I think GCC and Clang are correct. [expr.prim.id.general]/3: An id-expression that denotes a non-static data member or non-static member function of a class can only be used: - [...] - if that id-expression denotes a non-static data member and it appears in an unevaluated operand. [expr.prim.req.general]/2: Expressions appearing within a requirement-body are unevaluated operands.
[Bug c++/104981] New: [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981
Bug ID: 104981
Summary: [coroutines] Internal compiler error when promise
object's constructor takes a base class of the object
parameter
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
CC: iains at gcc dot gnu.org
Target Milestone: ---
#include
class Base {};
struct PromiseType;
struct Result {
using promise_type = PromiseType;
};
struct PromiseType {
PromiseType(const Base& parser, auto&&...) {}
Result get_return_object() { return {}; }
static std::suspend_never initial_suspend() { return {}; }
static std::suspend_always final_suspend() noexcept { return {}; }
[[noreturn]] static void unhandled_exception() { throw; }
void return_value(int) {}
};
struct Derived : Base {
Result f() {
co_return 42;
}
};
int main() {
Derived d;
d.f();
}
test.cpp: In member function ‘Result Derived::f()’:
test.cpp:26:5: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have reference_type in lookup_base, at
cp/search.cc:233
26 | }
| ^
0x8e421c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.cc:8724
0x751a6a tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
../../gcc/gcc/tree.h:3490
0x751a6a lookup_base(tree_node*, tree_node*, int, base_kind*, int)
../../gcc/gcc/cp/search.cc:233
0xa58c38 convert_to_base(tree_node*, tree_node*, bool, bool, int)
../../gcc/gcc/cp/class.cc:627
0xa2cfc2 convert_like_internal
../../gcc/gcc/cp/call.cc:8166
0xa2c5b0 convert_like_internal
../../gcc/gcc/cp/call.cc:8122
0xa316e1 convert_like_with_context
../../gcc/gcc/cp/call.cc:8466
0xa316e1 build_over_call
../../gcc/gcc/cp/call.cc:9579
0xa34d5b build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.cc:11171
0xa36147 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/gcc/cp/call.cc:10645
0xa9375d morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
../../gcc/gcc/cp/coroutines.cc:4912
0xade26f finish_function(bool)
../../gcc/gcc/cp/decl.cc:17718
0xbd22f2 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.cc:31242
0xbd2645 cp_parser_late_parsing_for_member
../../gcc/gcc/cp/parser.cc:32161
0xba8c71 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.cc:26176
0xba9f7c cp_parser_class_specifier
../../gcc/gcc/cp/parser.cc:26200
0xba9f7c cp_parser_type_specifier
../../gcc/gcc/cp/parser.cc:19344
0xbab06c cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.cc:15903
0xbabc04 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.cc:15151
0xbd9f32 cp_parser_declaration
../../gcc/gcc/cp/parser.cc:14964
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/104919] New: [modules] enum in constexpr function causes "failed to read compiled module cluster 1: Bad file data"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104919
Bug ID: 104919
Summary: [modules] enum in constexpr function causes "failed to
read compiled module cluster 1: Bad file data"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://godbolt.org/z/d3sdeEz1r
$ cat mod.cpp
export module mod;
export constexpr void f() {
enum { a };
a;
}
$ cat example.cpp
import mod;
int main() {
f();
}
$ g++ -std=c++20 -fmodules-ts mod.cpp example.cpp
In module imported at example.cpp:1:1:
mod: In function ‘int main()’:
mod: error: failed to read compiled module cluster 1: Bad file data
mod: note: compiled module file is ‘gcm.cache/mod.gcm’
example.cpp:4:5: fatal error: failed to load binding ‘::f@mod’
4 | f();
| ^
compilation terminated.
It compiles fine without `constexpr`.
[Bug c++/104752] New: `Concept auto(x)` should not be a valid function-style cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104752 Bug ID: 104752 Summary: `Concept auto(x)` should not be a valid function-style cast Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com CC: mpolacek at gcc dot gnu.org Target Milestone: --- https://godbolt.org/z/KbPMrbKsK template concept C = true; auto x = auto(1); // valid (P0849R8) auto y = C auto(1); // expect a error The initializer of `y` should be an error, but is currently accepted by GCC. [dcl.type.auto.deduct]: > For an explicit type conversion ([expr.type.conv]), T is the specified type, > which shall be auto. Note that the specified type cannot be 'type-constraint auto'. GCC does emit an error for `C<> auto(1)`.
[Bug libstdc++/104032] New: Cannot move-assign a spanstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104032
Bug ID: 104032
Summary: Cannot move-assign a spanstream
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://godbolt.org/z/GxdYrYYrj
#include
int main() {
std::ispanstream a(""), b("");
a = std::move(b);
}
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20220114/include/c++/12.0.0/spanstream: In
instantiation of 'std::basic_spanbuf<_CharT, _Traits>&
std::basic_spanbuf<_CharT, _Traits>::operator=(std::basic_spanbuf<_CharT,
_Traits>&&) [with _CharT = char; _Traits = std::char_traits]':
/opt/compiler-explorer/gcc-trunk-20220114/include/c++/12.0.0/spanstream:258:24:
required from here
/opt/compiler-explorer/gcc-trunk-20220114/include/c++/12.0.0/spanstream:89:7:
error: base operand of '->' has non-pointer type 'std::basic_spanbuf'
89 | basic_spanbuf(std::move(__rhs))->swap(*this);
| ^
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 66839, which changed state. Bug 66839 Summary: g++ accepts NSDMI with -std=c++98 when the intializer is a macro defined in a standard header https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66839 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/103347] [9/10/11 Regression] Non-static data member initialization is erroneously allowed in C++03 with assignment to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103347 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #12 from ensadc at mailnesia dot com --- *** Bug 66839 has been marked as a duplicate of this bug. ***
[Bug c++/66839] g++ accepts NSDMI with -std=c++98 when the intializer is a macro defined in a standard header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66839 ensadc at mailnesia dot com changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from ensadc at mailnesia dot com --- Seems to be fixed by r12-5488 *** This bug has been marked as a duplicate of bug 103347 ***
[Bug c++/101140] [modules] no matching function for call to ‘operator new(sizetype, void*)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101140 --- Comment #1 from ensadc at mailnesia dot com --- https://godbolt.org/z/EaPf3anxx
[Bug c++/101449] [modules] internal compiler error: in cxx_eval_call_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101449 --- Comment #1 from ensadc at mailnesia dot com --- https://godbolt.org/z/fMr9acG15
[Bug c++/101589] New: Incorrect implementation of LWG 3533 for elements_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101589 Bug ID: 101589 Summary: Incorrect implementation of LWG 3533 for elements_view Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com CC: ppalka at gcc dot gnu.org Target Milestone: --- LWG 3533 changed the const& overload of `elements_view::iterator::base` to return a const reference, but it seems that g:eb1aa9ad incorrectly applied the change to `elements_view::base` (that is, the `base()` member of the *view*, when it's supposed to change the member of the *iterator*).
[Bug c++/101449] New: [modules] internal compiler error: in cxx_eval_call_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101449
Bug ID: 101449
Summary: [modules] internal compiler error: in
cxx_eval_call_expression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
$ cat str.cpp
export module str;
export struct str {
constexpr str() {
ptr = new char[42];
}
constexpr ~str() { delete[] ptr; }
const char* ptr = nullptr;
};
export constexpr str get_str() { return str{}; }
$ cat main.cpp
import str;
int main() {
str a = get_str();
}
$ g++ -std=c++2b -fmodules-ts str.cpp main.cpp
main.cpp: In function ‘int main()’:
main.cpp:4:21: in ‘constexpr’ expansion of ‘get_str@str()()’
main.cpp:4:21: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.c:2742
4 | str a = get_str();
| ^
0x652ee9 cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.c:2742
0x9e54f1 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:6250
0x9e8829 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:7282
0x9ed921 maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/constexpr.c:7556
0xa20665 cp_fully_fold(tree_node*)
../../gcc/gcc/cp/cp-gimplify.c:2146
0xa207f4 cp_fully_fold(tree_node*)
../../gcc/gcc/cp/cp-gimplify.c:2140
0xa207f4 cp_fully_fold_init(tree_node*)
../../gcc/gcc/cp/cp-gimplify.c:2167
0xc16e03 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/gcc/cp/typeck2.c:816
0xa3a300 check_initializer
../../gcc/gcc/cp/decl.c:7169
0xa5dfd0 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:8103
0xb4a89f cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:22258
0xb2608d cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:14801
0xb27d69 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:13936
0xb28743 cp_parser_statement
../../gcc/gcc/cp/parser.c:12066
0xb2904e cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:12433
0xb29128 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:12382
0xb48ff0 cp_parser_function_body
../../gcc/gcc/cp/parser.c:24448
0xb48ff0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:24499
0xb49aea cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:30572
0xb4ac96 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:30488
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/101140] New: [modules] no matching function for call to ‘operator new(sizetype, void*)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101140
Bug ID: 101140
Summary: [modules] no matching function for call to ‘operator
new(sizetype, void*)’
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
$ cat new.hpp
extern "C++" {
void* operator new(__SIZE_TYPE__, void* p);
}
$ cat foo.cpp
module;
#include "new.hpp"
export module foo;
export template
T* construct_at(T* p) {
return ::new((void*)p) T();
}
$ cat bar.cpp
export module bar;
import foo;
void f(int* p) {
construct_at(p);
}
$ g++ -std=c++20 -fmodules-ts -c foo.cpp
$ g++ -std=c++20 -fmodules-ts -c bar.cpp
In module foo, imported at bar.cpp:3:
foo.cpp: In instantiation of ‘T* construct_at@foo(T*) [with T = int]’:
bar.cpp:6:17: required from here
foo.cpp:7:12: error: no matching function for call to ‘operator new(sizetype,
void*)’
7 | return ::new((void*)p) T();
|^~~
: note: candidate: ‘void* operator new(long unsigned int)’
: note: candidate expects 1 argument, 2 provided
: note: candidate: ‘void* operator new(long unsigned int,
std::align_val_t)’
: note: no known conversion for argument 2 from ‘void*’ to
‘std::align_val_t’
bar.cpp:1:8: warning: not writing module ‘bar’ due to errors
1 | export module bar;
|^~
The error disappears if "new.hpp" is included or imported in `bar.cpp`.
I originally encountered this problem when using `std::construct_at` (defined
in``) in a module.
[Bug c++/100134] [modules] ICE when using a vector in a module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100134
--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:
vector
namespace std {
template struct __replace_first_arg;
template class _Template, typename _Up,
typename _Tp, typename... _Types>
struct __replace_first_arg<_Template<_Tp, _Types...>, _Up> {
using type = _Template<_Up, _Types...>;
};
template struct allocator {
typedef _Tp value_type;
friend constexpr bool operator==(const allocator &,
const allocator &) noexcept {
return true;
}
};
} // namespace std
namespace __gnu_cxx {
template
struct __alloc_traits {
template struct rebind {
typedef std::__replace_first_arg<_Alloc, _Tp> other;
};
};
} // namespace __gnu_cxx
namespace std {
template > class vector {
typedef
typename __gnu_cxx::__alloc_traits<_Alloc>::template rebind<_Tp>::other
_Tp_alloc_type;
};
} // namespace std
foo.cpp
export module foo;
import ;
export struct Foo {
std::vector v;
};
build commands:
g++ -I . -x c++-system-header -fmodules-ts -std=c++20 vector
g++ -I . -std=c++20 -fmodules-ts foo.cpp
[Bug c++/99682] New: [modules] Module implementation unit is unable to indirectly import its corresponding interface unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99682 Bug ID: 99682 Summary: [modules] Module implementation unit is unable to indirectly import its corresponding interface unit Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com Target Milestone: --- $ cat src/foo.cpp export module foo; $ cat src/bar.cpp export module bar; import foo; $ cat src/foo-impl.cpp module foo; import bar; $ g++ -fmodules-ts -c src/foo.cpp $ g++ -fmodules-ts -c src/bar.cpp $ g++ -fmodules-ts -c src/foo-impl.cpp In module imported at src/foo-impl.cpp:2:1: bar: error: cannot import module in its own purview In module imported at src/foo-impl.cpp:1:1: foo: note: module ‘foo’ declared here In module imported at src/foo-impl.cpp:2:1: bar: error: failed to read compiled module: Bad import dependency bar: note: compiled module file is ‘gcm.cache/bar.gcm’ bar: fatal error: returning to the gate for a mechanical issue compilation terminated. AFAIK, although a module implementation unit cannot *directly* imports its module interface unit (http://eel.is/c++draft/module.import#9 ), *indirect* import should not be prohibited (and should probably be a no-op, because the primary module interface unit has been imported by `module foo;`). MSVC compiles this test case without any errors.
[Bug c++/99643] New: internal compiler error in build_over_call, involving array new and copy elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99643
Bug ID: 99643
Summary: internal compiler error in build_over_call, involving
array new and copy elision
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://godbolt.org/z/8TWG9d
struct Foo {};
Foo get_foo();
int main() {
new Foo[1]{get_foo()};
}
: In function 'int main()':
:5:25: internal compiler error: in build_over_call, at cp/call.c:9360
5 | new Foo[1]{get_foo()};
| ^
0x1cfa0d9 internal_error(char const*, ...)
???:0
0x6ba797 fancy_abort(char const*, int, char const*)
???:0
0x6df07c build_new_method_call(...)
???:0
0x6e07e0 build_special_member_call(...)
???:0
0x76a7cf ocp_convert(...)
???:0
0x7f46a8 build_aggr_init(tree_node*, tree_node*, int, int)
???:0
0x7f30c0 build_vec_init(...)
???:0
0x7f8051 build_new(...)
???:0
0x8e12dd c_parse_file()
???:0
0xa5f8d2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
This seems like a regression from GCC 10.
[Bug c++/98767] Function signature lost in concept diagnostic message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98767 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- The parameter list is printed by `pp_cxx_parameter_declaration_clause` defined in gcc/cp/cxx-pretty-print.c (https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/cxx-pretty-print.c;h=a22eea5239c33ed946abe46539e588b04e7beca7;hb=HEAD#l1538 ), where the parameter types are printed in a loop that starts with: >for (; args; args = TREE_CHAIN (args), types = TREE_CHAIN (types)) Here `args` was initialized with: > args = type_p ? NULL : FUNCTION_FIRST_USER_PARM (t); It seems that when a type is passed to `pp_cxx_parameter_declaration_clause`, `args` is always set to NULL, and the loop is never entered.
[Bug c++/98756] Suspicious "(*this)." in mangled symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98756
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:
```
class a {};
struct f {
template
int operator()(d, double, e);
};
struct i : f {
template
auto h(g...) -> decltype(operator()(g()...)) {}
// { dg-final { scan-assembler
"_ZN1i1hIJ1adS1_EEEDTcldtdefpTonclspcvT__EEEDpS2_" } }
};
a m, n;
int p = i{}.h(m, 1.0, n);
```
This is similar to the case mentioned in
https://itanium-cxx-abi.github.io/cxx-abi/cxx-abi-dev/archives/2011-July/002420.html
(but Clang does emit 'dtdefpT' in that example).
Itanium C++ ABI does not (yet) specify what to do in this case.
[Bug c++/98388] New: Throwing move-only parameter results in hard error in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98388
Bug ID: 98388
Summary: Throwing move-only parameter results in hard error in
SFINAE context
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://godbolt.org/z/xn8fYz
struct moveonly {
moveonly() = default;
moveonly(moveonly&&) = default;
};
template
constexpr auto is_throwable(T t) -> decltype(throw t, true) {
return true;
}
template
constexpr bool is_throwable(...) { return false; }
constexpr bool b = is_throwable(moveonly{});
: In substitution of 'template constexpr decltype
((, true)) is_throwable(T) [with T = moveonly]':
:13:43: required from here
:7:46: error: use of deleted function 'constexpr
moveonly::moveonly(const moveonly&)'
7 | constexpr auto is_throwable(T t) -> decltype(throw t, true) {
| ^~~
:1:8: note: 'constexpr moveonly::moveonly(const moveonly&)' is
implicitly declared as deleted because 'moveonly' declares a move constructor
or move assignment operator
1 | struct moveonly {
|^~~~
:7:52: note: in thrown expression
7 | constexpr auto is_throwable(T t) -> decltype(throw t, true) {
|^
I'm not sure what the value of `b` should be, but I believe that it should not
be a hard error. (Clang and MSVC initialize `b` to `true`.)
[Bug c++/98360] sizeof in template difference between g++/icc and clang++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98360 --- Comment #2 from ensadc at mailnesia dot com --- Apparently clang++ rewrites `uintset::values` in question to `this->uintset::values`, because it believes that `uintset::values` is valid only if someone specializes `uintset::traits` to make it inherit from `uintset`, but clang++ seems to fail at realizing that `uintset::values` appears in an unevaluated operand.
[Bug c++/98360] sizeof in template difference between g++/icc and clang++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98360 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- I think this is reject-valid in clang++. [expr.prim.id.general]/2 ( http://eel.is/c++draft/expr.prim.id.general#2 ): > An id-expression that denotes a non-static data member or non-static member > function of a class can only be used: > > - [...] > - if that id-expression denotes a non-static data member and it appears in an > unevaluated operand.
[Bug c++/97934] Adding an operator== breaks implicit operator== generation from defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97934 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #2 from ensadc at mailnesia dot com --- Per [class.compare.default] (http://eel.is/c++draft/class.compare.default#5.sentence-1 ), the == operator is implicitly generated if the member-specification does not declare *any* operator==. So the current behavior seems correct?
[Bug libstdc++/97828] std::ranges::search_n does not work with counted_iterator<_List_iterator<...>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828
--- Comment #2 from ensadc at mailnesia dot com ---
This seems to fix the bug (note: not thoroughly tested)
diff --git a/libstdc++-v3/include/bits/ranges_algo.h
b/libstdc++-v3/include/bits/ranges_algo.h
index f1a4cc24c0d..414ce0b1baa 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -579,21 +579,24 @@ namespace ranges
}
}
- if constexpr (sized_sentinel_for<_Sent, _Iter>)
+ if constexpr (random_access_iterator<_Iter>
+ && sized_sentinel_for<_Sent, _Iter>)
{
auto __tail_size = __last - __first;
auto __remainder = __count;
while (__remainder <= __tail_size)
{
+ auto __t = __remainder;
__first += __remainder;
__tail_size -= __remainder;
auto __backtrack = __first;
while (__value_comp(std::__invoke(__proj, *--__backtrack)))
{
- if (--__remainder == 0)
+ if (--__t == 0)
return {__first - __count, __first};
}
+ __remainder = __count - __remainder + __t;
}
auto __i = __first + __tail_size;
return {__i, __i};
[Bug libstdc++/97828] std::ranges::search_n does not work with counted_iterator<_List_iterator<...>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828 --- Comment #1 from ensadc at mailnesia dot com --- Compilation failure with `std::list`: https://godbolt.org/z/vbqhax Wrong result with `std::vector`: https://godbolt.org/z/axYbYr (expected output: "42 42 42"; actual: "42 0 42") It appears that `__remainder` is not reset when the sequence of equal values is interrupted. When the algorithm sees `0, 42, 42`, it decrements `__remainder` to 1, but when it sees that the next value is 0, it does not increment `__remainder`.
[Bug libstdc++/97828] New: std::ranges::search_n does not work with counted_iterator<_List_iterator<...>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828
Bug ID: 97828
Summary: std::ranges::search_n does not work with
counted_iterator<_List_iterator<...>>
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
```
#include
#include
#include
#include
int main() {
using namespace std::ranges;
std::list a = {0,42,42,0,42,42,42,0};
auto b = a | views::take(5);
auto count = 3;
auto res = search_n(b, count, 42);
for (int v : res) std::cout << v << ' ';
std::cout << '\n';
}
```
This gives a rather long error message.
It appears that the `sized_sentinel_for` branch of std::ranges::search_n uses
random access iterator operations, without checking if the iterator is actually
random access.
(This branch also returns incorrect results for certain input, which can be
observed by changing `std::list` to `std::vector`.)
[Bug c++/97700] Bogus error when a class containing a function pointer is used as a non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97700
ensadc at mailnesia dot com changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=83258
--- Comment #1 from ensadc at mailnesia dot com ---
The lambda is not needed to reproduce the bug. This also triggers the error:
void fun() {}
struct S
{
void (*f)();
};
template struct X {};
using x = X;
[Bug c++/97700] New: Bogus error when a class containing a function pointer is used as a non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97700
Bug ID: 97700
Summary: Bogus error when a class containing a function pointer
is used as a non-type template parameter
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
CC: jason at redhat dot com
Target Milestone: ---
Originally discovered by cigien on StackOverflow. See
https://stackoverflow.com/questions/64655958/can-a-class-containing-a-function-pointer-be-used-as-a-non-type-template-parameter
GCC does not like this program:
struct S
{
void (*f)();
};
constexpr S s {[]{}};
template struct X {};
using x = X;
It complains with:
error: '::_FUN' is not a valid template argument of type 'void (*)()'
because '::_FUN' is not a variable
using x = X;
^
As mentioned in the StackOverflow post, it appears that
`invalid_tparm_referent_p` (called by `get_template_parm_object`) fails to
account for the pointer-to-function case.
[Bug c++/95310] [concepts] Unrelated template parameters printed in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95310
--- Comment #3 from ensadc at mailnesia dot com ---
When verifying the fix, I noticed a new bug:
template requires true
using iter_reference_t = decltype(*T{});
template
struct result {
using type = iter_reference_t;
};
template
concept indirectly_writable = requires(Out&& o, T&& t) {
iter_reference_t(*o) = 0;
};
template
requires indirectly_writable>
void copy(In in, Out out) {}
void test(const int* p, int* q) {
copy(q, p);
}
: In function 'void test(const int*, int*)':
:19:14: error: no matching function for call to 'copy(int*&, const
int*&)'
19 | copy(q, p);
| ^
:16:6: note: candidate: 'template requires
indirectly_writable void copy(In, Out)'
16 | void copy(In in, Out out) {}
| ^~~~
:16:6: note: template argument deduction/substitution failed:
:16:6: note: constraints not satisfied
: In substitution of 'template requires
indirectly_writable void copy(In, Out) [with In = int*; Out
= const int*]':
:19:14: required from here
:10:9: required for the satisfaction of 'indirectly_writable >' [with Out = const int*; In = int*]
:10:31: in requirements with 'Out&& o', 'T&& t' [with T = int&; Out =
const int*]
:11:29: note: the required expression 'decltype(*{})(*o)=0' is invalid
11 | iter_reference_t(*o) = 0;
| ~~^~~
cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
detail
In
:10:9: required for the satisfaction of 'indirectly_writable >' [with Out = const int*; In = int*]
Note the mismatch between `F` and `In`.
GCC 10.2 prints `F = int*` instead of `In = int*`:
:10:9: required for the satisfaction of 'indirectly_writable >' [with Out = const int*; F = int*]
The name `F` comes from a completely unrelated class template, but at least the
names match in GCC 10.2.
(Interestingly, the alias template is not expanded in this line.)
[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 --- Comment #2 from ensadc at mailnesia dot com --- See also LWG 3408 (https://wg21.link/lwg3408), which also suggests that the `iterator_traits>` specialization is problematic. I think the standard could remove this specialization (and define `iterator_concept` in `counted_iterator`), since this specialization seems to have only negative effect.
[Bug libstdc++/95983] New: `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 Bug ID: 95983 Summary: `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator` Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com Target Milestone: --- https://wandbox.org/permlink/rUZlUGG4UFeWicbM #include #include #include using R = std::ranges::basic_istream_view>; using It = std::ranges::iterator_t; static_assert(std::input_or_output_iterator>); prog.cc:5:20: error: static assertion failed 5 | static_assert(std::input_or_output_iterator>); | ~^~ prog.cc:5:20: note: constraints not satisfied In file included from /opt/wandbox/gcc-head/include/c++/11.0.0/bits/stl_iterator_base_types.h:71, from /opt/wandbox/gcc-head/include/c++/11.0.0/iterator:61, from /opt/wandbox/gcc-head/include/c++/11.0.0/ranges:44, from prog.cc:1: /opt/wandbox/gcc-head/include/c++/11.0.0/bits/iterator_concepts.h:536:13: required for the satisfaction of 'weakly_incrementable<_Iter>' [with _Iter = std::counted_iterator >::_Iterator > >] /opt/wandbox/gcc-head/include/c++/11.0.0/bits/iterator_concepts.h:538:10: in requirements with '_Iter __i' [with _Tp = std::counted_iterator >::_Iterator > >; _Iter = std::counted_iterator >::_Iterator > >] /opt/wandbox/gcc-head/include/c++/11.0.0/bits/iterator_concepts.h:540:11: note: the required type 'std::iter_difference_t<_Iter>' is invalid 540 | typename iter_difference_t<_Iter>; | ~^ /opt/wandbox/gcc-head/include/c++/11.0.0/bits/iterator_concepts.h:541:21: note: nested requirement '__is_signed_integer_like::type>::type, std::incrementable_traits::type>::type> >::type::difference_type>' is not satisfied 541 | requires __detail::__is_signed_integer_like>; | ~~^~ cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more detail It seems that in this case, `iter_difference_t` is treated as an alias of `std::iterator_traits>::difference_type` (which doesn't exist), because libstdc++ defines a specialization of `std::iterator_traits>`. (The error message is worse than it should be, due to bug 94862 and bug 95303.)
[Bug c++/95944] Concept diagnostic has multiple copies of irrelevant type and displays correct type incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95944 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- bug95303, bug95310
[Bug c++/95310] New: [concepts] Unrelated template parameters printed in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95310
Bug ID: 95310
Summary: [concepts] Unrelated template parameters printed in
diagnostic
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
CC: asutton at gcc dot gnu.org
Target Milestone: ---
https://godbolt.org/z/M8CVwc
template
using iter_reference_t = decltype(*T{});
template
struct result {
using type = iter_reference_t;
};
template
concept indirectly_writable = requires(Out&& o, T&& t) {
iter_reference_t(*o) = 0;
};
static_assert(indirectly_writable);
:13:15: error: static assertion failed
13 | static_assert(indirectly_writable);
| ^
:13:15: note: constraints not satisfied
:10:9: required by the constraints of 'template
concept indirectly_writable'
:10:31: in requirements with 'Out&& o', 'T&& t' [with F = const int*;
T = int&; Out = const int*]
:11:29: note: the required expression 'decltype(*{})(*o)=0' is invalid
11 | iter_reference_t(*o) = 0;
| ~~^~~
cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
detail
Note "[with F = const int*; T = int&; Out = const int*]". The 'F = const int*;'
part is spurious.
When the template parameter of `result` has the same name as the parameter of
the concept (which is the case I originally encountered), the output can be
quite confusing.
The expression 'decltype(*{})(*o)=0' also seems wrong.
Might be related to bug 94862.
[Bug c++/95303] New: Member type of class template is incorrectly printed in diagnostics when it fails to satisfy a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95303
Bug ID: 95303
Summary: Member type of class template is incorrectly printed
in diagnostics when it fails to satisfy a concept
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
CC: asutton at gcc dot gnu.org
Target Milestone: ---
https://godbolt.org/z/F5Hj38
template
struct A {
struct B {};
};
template
concept C = requires (T&& t) {
t.a;
};
static_assert(C::B>);
:11:15: error: static assertion failed
11 | static_assert(C::B>);
| ^~~~
:11:15: note: constraints not satisfied
:7:9: required by the constraints of 'template concept C'
:7:13: in requirements with 'T&& t' [with T = A::B]
:8:7: note: the required expression 't.a' is invalid
8 | t.a;
| ~~^
cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
detail
Note '[with T = A::B]'. It should be '[with T = A::B]', without
the second ``.
[Bug c++/86142] hard error for bad delete-expression in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86142 ensadc at mailnesia dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||10.1.0 Known to fail||9.3.0 Resolution|--- |FIXED --- Comment #3 from ensadc at mailnesia dot com --- Fixed in GCC 10
[Bug c++/86142] hard error for bad delete-expression in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86142 --- Comment #2 from ensadc at mailnesia dot com --- I was misled by Clang. Seems like there's a Clang bug then.
[Bug c++/95093] Implement DR 1966, Colon following enumeration elaborated-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95093 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- Probably related/covered in https://wg21.link/cwg2141 (PR50169).
[Bug c++/94568] template specialization of equivalent nontype template argument involving member pointer considered distinct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94568
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #2 from ensadc at mailnesia dot com ---
struct C { int a[2]; };
template struct D { };
constexpr int i_{ };
typedef D DC01;
void f(DC01) {}
The name of `f` is mangled as `_Z1f1DIXtl1CtlA2_iLKi0ELi1E`. The `LKi0E`
part seems to suggest that the element corresponding to `i_` has type `const
int`, where it should be a plain `int`.
[Bug c++/94490] Ternary expression with 3 consts is “not” a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94490
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #2 from ensadc at mailnesia dot com ---
reduced & modified:
```
template
constexpr int fake_tuple_size_v = 3;
template struct intseq {};
template using genseq = intseq<__integer_pack(N)...>;
template>
struct arith_result
{ };
template
auto Mul(const T&)
{
return [](auto) { return arith_result> { }; }(0);
}
auto x = Mul(0);
```
[Bug c++/55227] designated initializer for char array by string constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #4 from ensadc at mailnesia dot com ---
This is accepted in `-Wno-pedantic` mode:
struct A { int x; char a[10]; };
A a = { .x = 1, { .a = "" } }; // #1
This is rejected:
struct A { int x; char a[10]; };
A a = { .x = 1, .a = "" }; // #2
It seems that #1 should be rejected, and #2 should be accepted.
I suspect that the bug is related to r182391 (which is a fix for PR51458),
which added call to `has_designator_problem` in `reshape_init_r`:
/* If it's a string literal, then it's the initializer for the array
as a whole. Otherwise, continue with normal initialization for
array types (one value per array element). */
if (TREE_CODE (stripped_str_init) == STRING_CST)
{
if (has_designator_problem (d, complain))
return error_mark_node;
d->cur++;
return str_init;
}
[Bug c++/94453] [10 Regression] ICE in make_decl_rtl since r10-3591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94453
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #2 from ensadc at mailnesia dot com ---
void *ay();
template f ay() { return *static_cast(ay()); }
template
void bf() {
ay()();
}
struct az {
template
az(h);
using bk = void (*)();
bk bl;
};
template
az::az(h) { bl = bf; }
struct A {};
void da(az);
void di(A, int);
void dk(A, az, az);
void b() {
int data = 0;
auto n = [] {};
constexpr auto p = A{};
auto q = [=] { di(p, data); };
da([=] { dk(p, n, q); });
}
[Bug c++/93295] ICE in alias_ctad_tweaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93295 --- Comment #3 from ensadc at mailnesia dot com --- It appears that alias_ctad_tweaks assumes the deduction of the right hand side of the deduction guide from the alias template does not fail. > int err = unify (ftparms, targs, ret, utype, UNIFY_ALLOW_NONE, false); > gcc_assert (!err); But this can fail if the RHS of the deduction guide contains `T*` or the like. I guess this is exactly where the simplification mentioned in r278786 fails to work.
[Bug c++/93295] New: ICE in alias_ctad_tweaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93295
Bug ID: 93295
Summary: ICE in alias_ctad_tweaks
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://wandbox.org/permlink/B02uUhc2QP8OChB9
template
struct A { A(int); };
template
A(T) -> A;
template
using B = A;
B a(0);
prog.cc:10:12: internal compiler error: in alias_ctad_tweaks, at cp/pt.c:28223
10 | B a((int*)0);
|^
0x5b9faa alias_ctad_tweaks
../../source/gcc/cp/pt.c:28223
0x5b9faa deduction_guides_for
../../source/gcc/cp/pt.c:28395
0x7048b3 do_class_deduction
../../source/gcc/cp/pt.c:28500
0x7048b3 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../source/gcc/cp/pt.c:28629
0x6693e6 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../source/gcc/cp/decl.c:7463
0x6eb461 cp_parser_init_declarator
../../source/gcc/cp/parser.c:20762
0x6ce805 cp_parser_simple_declaration
../../source/gcc/cp/parser.c:13627
0x6f3962 cp_parser_declaration
../../source/gcc/cp/parser.c:13325
0x6f4084 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4723
0x6f4084 c_parse_file()
../../source/gcc/cp/parser.c:43563
0x7bb56b c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1186
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
The error disappears if `A` is changed to `A`, or if `, class = int` is
removed.
[Bug c++/92552] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:3045 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:
template struct basic_mixin {
basic_mixin() requires true;
};
template
struct mixin : basic_mixin {
using basic_mixin::basic_mixin;
};
int main() {
(void)__is_constructible(mixin);
// noexcept(mixin()); also triggers ICE
}
[Bug c++/91930] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:2423 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91930
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:
template struct basic_mixin {
basic_mixin() requires true;
};
struct mixin : basic_mixin {
using basic_mixin::basic_mixin;
};
auto test() {
noexcept(mixin());
}
[Bug c++/91791] ICE when throwing exception in a ternary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91791 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- Duplicate of PR 90393?
[Bug c++/91675] [9/10 Regression] Memory corruption with std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91675 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #2 from ensadc at mailnesia dot com --- Duplicate of PR 90393?
[Bug libstdc++/91488] [9/10 Regression] char_traits::length causes "inlining failed in call to always_inline" error with -fgnu-tm -O2 -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91488
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
It seems that the inliner does not like the `static` specifier in
`__constant_string_p`. This also triggers "inlining failed in call to
always_inline" error:
static __attribute__((always_inline)) constexpr bool
f()
{
return __builtin_is_constant_evaluated();
}
int main() {
(void)f();
}
[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90393 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #7 from ensadc at mailnesia dot com --- It seems that r260272 changed `build_conditional_expr_1` to not create lvalue-to-rvalue conversion for such conditional expressions, but failed to change `lvalue_kind` to treat such expressions as glvalue, so GCC still thinks they are prvalue (https://gcc.gnu.org/viewvc/gcc/trunk/gcc/cp/tree.c?view=markup#l303) and applies copy elision (and probably other weird things).
[Bug c++/90784] A loop inside a constexpr function in a constexpr context is not evaluated at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90784 --- Comment #2 from ensadc at mailnesia dot com --- But curiously, gcc does replace the loop with the constant if `#undef _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED` is added before `#include `: https://godbolt.org/z/mVdLVP . (Why) is `__builtin_is_constant_evaluated` pessimizing?
[Bug c++/90784] A loop inside a constexpr function in a constexpr context is not evaluated at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90784 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- `CTest::length(psz)` is *not* a constexpr context when `psz` names a parameter. It might be a missed optimization, but it's not wrong AFAIK.
[Bug c++/90769] Template instantiation recursion when trying to do a conversion template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90769
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #3 from ensadc at mailnesia dot com ---
It seems that `f == B` triggers overload resolution which treats `operator==`
declared latter as a candidate, which then causes the instantiation of the
constructor template, which requires overload resolution for `f == B`
Reduced:
enum E {B};
struct X
{
template
constexpr X(int v);
};
bool operator==(X const& lhs, int) {
return X(1);
}
[Bug libstdc++/90704] New: filesystem::path overloads for file streams are not conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704 Bug ID: 90704 Summary: filesystem::path overloads for file streams are not conforming Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com Target Milestone: --- https://gcc.gnu.org/ml/libstdc++/2017-10/msg00110.html mentions: > This isn't entirely conforming, because a type that is convertible to > filesystem::path will not match these new function templates. We can > revisit it once the symbols are added to libstdc++.so but > this should be OK for now. Now it seems to be time to revisit it. Notably, the current overloads prevent `string_view` from working with file streams.
[Bug libstdc++/90686] New: Libstdc++ C++20 status table is missing entry for P1357R1 "Traits for [Un]bounded Arrays"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90686 Bug ID: 90686 Summary: Libstdc++ C++20 status table is missing entry for P1357R1 "Traits for [Un]bounded Arrays" Product: gcc Version: unknown Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com CC: redi at gcc dot gnu.org Target Milestone: --- P1357R1 "Traits for [Un]bounded Arrays" has been implemented in r269420 (and feature test macro added in r269426), but this is not mentioned in the status table (https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2020). It seems that other papers approved in Kona 2019 are also missing.
[Bug c++/89062] class template argument deduction failure with parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #3 from ensadc at mailnesia dot com --- I think this should be treated as a different bug from bug 87709. In bug 87709, the error is emitted in cp_parser_type_id_1. In this bug, the error is produced by grokdeclarator.
[Bug c++/88977] New: __builtin_is_constant_evaluated() as function template argument causes substitution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88977 Bug ID: 88977 Summary: __builtin_is_constant_evaluated() as function template argument causes substitution failure Product: gcc Version: unknown Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com Target Milestone: --- https://wandbox.org/permlink/LYuJZ4w7YLgidqdi template int f(); int x = f<__builtin_is_constant_evaluated()>(); prog.cc:3:46: error: no matching function for call to 'f<__builtin_is_constant_evaluated()>()' 3 | int x = f<__builtin_is_constant_evaluated()>(); | ^ prog.cc:1:20: note: candidate: 'template > int f()' 1 | template int f(); |^ prog.cc:1:20: note: template argument deduction/substitution failed: It works fine with class/variable/alias templates.
[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 --- Comment #7 from ensadc at mailnesia dot com --- (In reply to Zhihao Yuan from comment #6) > Here is a possibly related case: > > [...] I think this is a different bug. GCC thinks the implicitly-deleted move assignment operator `pair& pair::operator=(pair&&)` is a candidate for the assignment, which causes ambiguity with `operator=(value_type&&)` (where value_type = pair). But as part of resolution of CWG 1402, [class.copy.assign] specifies that "A defaulted move assignment operator that is defined as deleted is ignored by overload resolution".
[Bug c++/86356] "invalid use of pack expansion" with fold expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86356
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:
template struct mp_bool { static constexpr bool value = B; };
template using mp_any =
mp_bool<(static_cast(T::value) || ...)>;
template
struct A { static constexpr bool value = true; };
template struct variant_base_impl {};
template using variant_base
= variant_base_impl, A...>::value>;
int main()
{
variant_base();
}
[Bug c++/88762] C++17 Deduction guide and operator expression produces missing template argument error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88762 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- Duplicate of bug 87709?
[Bug c++/88761] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478 when chaining lambda calls & fold-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88761
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #2 from ensadc at mailnesia dot com ---
Reduced:
template
void a() {
int b;
[&](auto c) {
if constexpr (sizeof(c) != 42) {
[&] { b; };
}
}(0);
}
template void a<1>();
[Bug c++/88759] New: `decltype(auto)` as return type of abbreviated function template strips cv-qualifications and referenceness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88759
Bug ID: 88759
Summary: `decltype(auto)` as return type of abbreviated
function template strips cv-qualifications and
referenceness
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://wandbox.org/permlink/hPwFtdVsAd4kIu44
(-fconcepts is required to silent the warning "use of 'auto' in parameter
declaration only available with -fconcepts", but otherwise the default setting
is enough to trigger the error.)
decltype(auto) f(auto x) {
return x[0];
}
const int x[] = {0};
extern decltype(f(x)) a;
extern const int& a;
prog.cc:8:19: error: conflicting declaration 'const int& a'
8 | extern const int& a;
| ^
prog.cc:7:23: note: previous declaration as 'int a'
7 | extern decltype(f(x)) a;
| ^
Originally discovered in
https://stackoverflow.com/questions/54062172/understanding-decltypeauto-difference-in-case-of-template-vs-auto-functions.
I rewrote the code to better illustrate the issue.
`decltype(f(x))` should be `const int&`, but GCC thinks it's `int`.
It seems that `decltype(auto)` is treated the same as `auto` when used as
return type of abbreviated function template.
Changing the abbreviated function template to a regular function template (i.e.
changing `decltype(auto) f(auto x)` to `template decltype(auto) f(T
x)`) removes the error.
Probably related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69448.
[Bug c++/80916] [7/8/9 Regression] Spurious "declared 'static' but never defined" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80916
--- Comment #7 from ensadc at mailnesia dot com ---
Note that the "never defined" part is also misleading: the warning persists
when `i::dispatch` does have a definition
(https://wandbox.org/permlink/MKif1shXFjt7aT6C):
struct j {
virtual void dispatch(void *) {}
};
template
struct i : j {
void dispatch(void *) {} // warning: 'void i<
>::dispatch(void*) [with = {anonymous}::l]' declared
'static' but never defined [-Wunused-function]
};
namespace {
struct l : i {};
}
void f(j *k) {
k->dispatch(0);
}
[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
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #5 from ensadc at mailnesia dot com ---
This is also ambiguous and seems to have the same cause (i.e. overload
resolution accepts list-initialization that calls explicit constructor when
forming the implicit conversion sequence):
template
struct in_place_type_t { explicit in_place_type_t() = default; };
struct A { };
int f(A);
int f(in_place_type_t);
int x = f({});
[Bug c++/88694] constexpr isn't captured correctly in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88694
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #4 from ensadc at mailnesia dot com ---
Further reduced:
template struct A {
static constexpr T e = U;
constexpr operator int () { return e; }
};
struct D { template void print (); };
int
main ()
{
D d;
[&](auto i) { auto x = [&] { d.print(); }; }(A{});
}
[Bug c++/87513] [8/9 Regression] ICE in write_expression, at cp/mangle.c:3050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #9 from ensadc at mailnesia dot com ---
struct A { template void foo (); };
template auto bar () -> decltype (&A::foo);
void foo ()
{
bar<0> ();
}
[Bug c++/88385] [9 regression] ICE in tsubst_pack_expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88385 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #2 from ensadc at mailnesia dot com --- Duplicate of bug 87814?
[Bug c++/88595] Template type lacking template-id-expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88595
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
As far as I know, CTAD (class template argument deduction) is like `auto`; both
are not allowed in non-static member declarations. So gcc is correct in both
places.
```
template struct Any
{
constexpr Any (int x) {}
};
struct Container
{
auto c = 1; // error
Any car; // also error
};
auto c = 1; // OK
Any x (2); // also OK
```
The error message can probably be improved though.
[Bug c++/87125] [9 Regression] ICE in tsubst_copy starting with r261084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87125
--- Comment #3 from ensadc at mailnesia dot com ---
(In reply to ensadc from comment #2)
> Reduced:
>
> template struct ch {
> template constexpr ch(by) noexcept(br());
> };
> class ce : ch {
> using ch::ch;
> };
>
> void f() {
> noexcept(ce(0));
> }
This appears similar to bug 87814 (which is fixed in r267155). Maybe a
duplicate?
[Bug c++/88146] ice in tsubst_copy, at cp/pt.c:16014
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88146 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #4 from ensadc at mailnesia dot com --- Related to bug 87814?
[Bug c++/88020] Deduction guides fail inside sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88020 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #2 from ensadc at mailnesia dot com --- This has the same cause as bug 87709
[Bug c++/86574] ICE on std::prev with ranges::view::transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86574 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #5 from ensadc at mailnesia dot com --- Duplicate of bug 86212 or bug 87814?
[Bug c++/87814] [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962 with range-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87814
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:
template
struct box {
template
constexpr box(E && e)
noexcept(noexcept(Element(e)))
{}
};
template
struct compressed_tuple_ : box ... {
template
constexpr compressed_tuple_(Args &&... args)
noexcept((noexcept(box(args)) && ...))
: box(args)...
{}
};
struct adaptor_cursor : compressed_tuple_ {
using compressed_tuple_::compressed_tuple_;
};
int main() {
(void)noexcept(adaptor_cursor{(int*)0});
}
[Bug c++/87783] New: `class A;` is incorrectly accepted at namespace or class scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87783
Bug ID: 87783
Summary: `class A;` is incorrectly accepted at namespace
or class scope
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://wandbox.org/permlink/L5JYCDnEfKmftRlr
template class A {};
class A;
Both Clang and MSVC appear to treat `class A;` as an invalid explicit
template specialization. GCC does the same at block scope, but incorrectly
accepts this declaration at namespace or class scope.
[Bug c++/87781] New: template disambiguator not after `::`, `.` or `->` is incorrectly accepted in an elaborated-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87781 Bug ID: 87781 Summary: template disambiguator not after `::`, `.` or `->` is incorrectly accepted in an elaborated-type-specifier Product: gcc Version: unknown Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com Target Milestone: --- https://wandbox.org/permlink/97lV1nw6gMGSDOct template class A; class template A *p; GCC allows this with no warning or error. Both clang and MSVC reject this.
[Bug c++/87770] ICE in type_dependent_expression_p, at cp/pt.c:25230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87770
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:
template struct d {
template d(e);
};
template <> template d::d(e);
template <> template d::d(e) {
long g;
(void)g;
}
template d::d(char);
[Bug c++/87658] Cannot use move ctor when inserting to std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87658 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- > dynamicParts[mf->getName()] = std::move(part); operator[] calls the default constructor of the mapped_type (which seems to be `VehicleObject::Part` in this case), and since the mapped_type does not have a default constructor, this of course fails. I don't think this is a bug.
[Bug libstdc++/87431] valueless_by_exception() should unconditionally return false if all the constructors are noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87431
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #7 from ensadc at mailnesia dot com ---
This "optimization" might be unsafe in the presence of throwing conversion
operator:
// https://wandbox.org/permlink/ADEIfSv120QMrKeS
#include
#include
struct weird {
operator int() { throw 0; }
};
int main() {
std::variant v;
try {
v.emplace<1>(weird{});
} catch (...) {
assert((v.index() == std::variant_npos) ==
(v.valueless_by_exception()));
}
}
Maybe we can fix the optimization by making `emplace` restore the original
value (or not destroy in the first place) when the optimization is present and
an exception is thrown.
[Bug c++/87322] [GCC 8.1+] GCC fails to parse captured lambda of 2nd inner lambda if the captured lambda has "," (having 2 arguments)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87322
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:
int main()
{
[](auto x) {
[inner_func2 = [] (auto a, auto b) {} ] {};
}(0);
}
[Bug c++/84075] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #4 from ensadc at mailnesia dot com ---
Further reduced:
template < int > struct b { };
template < typename n > struct g {
typedef b< sizeof(n) > l;
};
template < typename h, typename = typename g< h >::l > class aa {};
template < typename h, typename bz >
void bj(aa< h, bz >, int);
template < template < class > class ct > void bj(ct< class U >);
void f() {
bj(aa(), 0);
}
(`__attribute__((__used__))` in the original example matters because it ensures
that the call is instantiated.)
[Bug c++/80916] Spurious "declared 'static' but never defined" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80916
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #3 from ensadc at mailnesia dot com ---
Reduced:
struct j {
virtual void dispatch(void *);
};
template
struct i : j {
void dispatch(void *);
};
namespace {
struct l : i {};
}
void f(j *k) {
k->dispatch(0);
}
[Bug c++/87125] [9 Regression] ICE in tsubst_copy starting with r261084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87125
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #2 from ensadc at mailnesia dot com ---
Reduced:
template struct ch {
template constexpr ch(by) noexcept(br());
};
class ce : ch {
using ch::ch;
};
void f() {
noexcept(ce(0));
}
[Bug c++/87152] internal compiler error: in tsubst_copy, at cp/pt.c:15484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87152
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:
template
int int_from_bits()
{
int a[1] = {};
for (int index = 0; int _ : a)
{
index;
}
return 0;
}
int j = int_from_bits<>();
[Bug c++/86970] Rejected constexpr expression involving lambdas and inheritance, "use of this in a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86970
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Removed `#include`:
template
struct faketuple
{
template
constexpr faketuple(U&& u) { }
constexpr faketuple(const faketuple&) = default;
};
namespace ns {
template
class Foo : private A
{
public:
template
explicit constexpr Foo(FA&& a)
: A{static_cast(a)}
{}
};
template
Foo(A)->Foo;
template
constexpr auto frobnicate(T&& val)
{
return [val = static_cast(val)] {};
}
template
class Bar
{
A a;
faketuple b;
public:
template
explicit constexpr Bar(FA&& a, FB&& b)
: a{a}
, b{b}
{}
};
template
Bar(A, B)->Bar;
constexpr auto Baz = ns::Foo{ns::frobnicate(ns::Bar{[] {}, [](int) {}})};
}
But `std::tuple` has a move constructor, unlike `faketuple` :/
[Bug c++/85457] enum and auto template parameter mixup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85457 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- This seems to have been fixed. Duplicate of bug 79092?
[Bug libstdc++/86603] New: `__cpp_lib_list_remove_return_type` misplaced in the header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86603 Bug ID: 86603 Summary: `__cpp_lib_list_remove_return_type` misplaced in the header Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com CC: redi at gcc dot gnu.org Target Milestone: --- In , __cpp_lib_list_remove_return_type is defined when __cplusplus == 201703. This is inconsistent with and , where the macro is defined (and the corresponding feature is enabled) only in C++2a mode.
[Bug c++/86142] New: hard error for bad delete-expression in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86142 Bug ID: 86142 Summary: hard error for bad delete-expression in SFINAE context Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com Target Milestone: --- https://wandbox.org/permlink/9gfZwtKZC9Tu92fs template void f(); template int f(...); int x = f(); int y = f(); int z = f(); prog.cc: In substitution of 'template void f() [with T = int; = ]': prog.cc:7:16: required from here prog.cc:1:19: error: type 'int' argument given to 'delete', expected pointer template ^ prog.cc: In substitution of 'template void f() [with T = int (*)(); = ]': prog.cc:8:21: required from here prog.cc:1:19: error: cannot delete a function. Only pointer-to-objects are valid arguments to 'delete' prog.cc: In substitution of 'template void f() [with T = void*; = ]': prog.cc:9:18: required from here prog.cc:1:19: warning: deleting 'void*' is undefined [-Wdelete-incomplete] prog.cc:9:18: error: call of overloaded 'f()' is ambiguous int z = f(); ^ prog.cc:2:6: note: candidate: 'void f() [with T = void*; = void]' void f(); ^ prog.cc:4:5: note: candidate: 'int f(...) [with T = void*]' int f(...); ^ These variable definitions should call the second overload of `f`. No warning or error should be triggered. The code is accepted by clang.
[Bug c++/85901] New: Error message contains "#'offset_type' not supported by simple_type_specifier#)#'offset_type' not supported by direct_abstract_declarator#"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85901
Bug ID: 85901
Summary: Error message contains "#'offset_type' not supported
by simple_type_specifier#)#'offset_type' not supported
by direct_abstract_declarator#"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://wandbox.org/permlink/IQV1PEfIFY8M5T5C
template struct A;
template
struct A {
template
static auto c(int U::*p, TT o) -> decltype(o.*p);
};
struct X {};
int x = A::c();
prog.cc:11:24: error: no matching function for call to 'A::c()'
int x = A::c();
^
prog.cc:6:17: note: candidate: 'template static decltype
(A<#'offset_type' not supported by simple_type_specifier#)#'offset_type' not
supported by direct_abstract_declarator#>::c::o.*A<#'offset_type' not supported
by simple_type_specifier#)#'offset_type' not supported by
direct_abstract_declarator#>::c::p) A::c(int U::*, TT) [with TT = TT;
U = X]'
static auto c(int U::*p, TT o) -> decltype(o.*p);
^
prog.cc:6:17: note: template argument deduction/substitution failed:
prog.cc:11:24: note: candidate expects 2 arguments, 0 provided
int x = A::c();
^
"#'offset_type' not supported by simple_type_specifier#)#'offset_type' not
supported by direct_abstract_declarator#" shouldn't be present in the error
message.
Maybe the nested-name-specifier before o and p are all redundant. That is, it
should be just "decltype(o.*p)", not
"decltype(A::c::o.*A::c::p)".
[Bug c++/85842] New: Bogus -Wreturn-type with generic lambda and constexpr if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85842
Bug ID: 85842
Summary: Bogus -Wreturn-type with generic lambda and constexpr
if
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://wandbox.org/permlink/qSgjLEWzpsJmkHNU
template
auto f = [](auto&& arg) -> T* {
if constexpr (sizeof(arg) == 1) {
return nullptr;
} else {
return static_cast(&arg);
}
};
auto p = f(0);
prog.cc: In instantiation of 'auto f':
prog.cc:10:10: required from here
prog.cc:2:6: warning: no return statement in function returning non-void
[-Wreturn-type]
auto f = [](auto&& arg) -> T* {
^
This warning is bogus because both branches of `if constexpr` have a return
statement.
The warning will disappear when `if constexpr` is changed to `if`.
[Bug c++/85739] [8/9 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:3057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85739
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #4 from ensadc at mailnesia dot com ---
struct l { int k; };
template class b { };
template class B { using e = int; };
template
bool operator!=(B, b);
bool bb = (B<&l::k>() != b<&l::k>());
also reproduces it.
[Bug c++/85765] Missing SFINAE in default template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85765
ensadc at mailnesia dot com changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #1 from ensadc at mailnesia dot com ---
This bug can be triggered by libstdc++'s `std::bind`, even when user code does
not use `volatile` (in which case the error is quite hard to discern):
#include
#include
#include
struct begin_fn {
template())),
decltype(*I(), 0) = 0>
static I impl_(T& t, long) noexcept(noexcept(begin(t))) { return begin(t);
}
template
auto operator()(T& t) noexcept(noexcept(impl_(t, 0))) -> decltype(impl_(t,
0)) { return impl_(t, 0); }
};
std::initializer_list x = {1};
auto a = std::bind(begin_fn{}, x)(); // error, even though begin_fn{}(x) is
fine
Similar pattern is used by range-v3 and has caused their example failing to
build with g++ 8.1. See https://github.com/ericniebler/range-v3/issues/826
[Bug c++/85765] New: Missing SFINAE in default template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85765
Bug ID: 85765
Summary: Missing SFINAE in default template argument
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://wandbox.org/permlink/lxHtJOjvghJiLiIO
struct il { il(); il(const il&); };
int* begin(il);
template T&& declval();
template())), decltype(*U(),0) =
0>
U g(T& t, long) { return begin(t); } // #1
template
int g(T& t, ...); // #2
volatile il a;
auto n = g(a, 0); // calls #1 and ends with a hard error, should call #2
prog.cc: In instantiation of 'U g(T&, long int) [with T = volatile il; U =
int*; decltype (((* U()), 0)) = 0]':
prog.cc:15:16: required from here
prog.cc:8:31: error: binding reference of type 'const il&' to 'volatile il'
discards qualifiers
U g(T& t, long) { return begin(t); } // #1
~^~~
prog.cc:1:19: note: initializing argument 1 of 'il::il(const il&)'
struct il { il(); il(const il&); };
^~
prog.cc:3:6: note: initializing argument 1 of 'int* begin(il)'
int* begin(il);
^
#1 should be SFINAE'ed out because `declval()` (of type `volatile il&`) is
not convertible to the parameter of `begin` (of type `il`), so #2 should called
without causing an error. But instead g++ 8.1 selects #1 and emits a hard
error.
g++ 7.3 and before calls #2, as do Clang and MSVC. g++ 8 and later will call #2
if ", decltype(*U(),0) = 0" is removed.
[Bug c++/85124] New: template template parameter is printed incorrectly in the error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85124
Bug ID: 85124
Summary: template template parameter is printed incorrectly in
the error message
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
https://wandbox.org/permlink/0ir0hnoy5jeX9KLT
template using ref = T&;
template
struct X {
template class F>
using apply = F;
};
X::apply a;
prog.cc: In substitution of 'template using ref = T& [with T = void]':
prog.cc:6:26: required by substitution of 'template
template class F> template template
class F> using apply = F [with F = ref; A = int]'
prog.cc:9:18: required from here
prog.cc:1:33: error: forming reference to void
template using ref = T&;
^
In the second line of the error message ("required by substitution of ..."), it
should be just `template class F`, not `template class
F> template template class F` (i.e. there should be only one
template-head for the template template parameter, not three).
Just to clarify, it's irrelevant what the actual error is.
[Bug c++/81086] [8 Regression] ICE with structured binding of initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81086 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #2 from ensadc at mailnesia dot com --- Fixed by r255705 ?
[Bug c++/83000] Constraints for union-templates do not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83000 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- Possible duplicate of issue 67217
[Bug c++/83003] Using the detection idiom and void_t causes an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83003
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #3 from ensadc at mailnesia dot com ---
There doesn't even need to be a specialization of Zod.
template class, class = void>
struct dtect1 { enum { value = 0 }; };
template class TT>
struct dtect1{}, void())> { enum { value = 1 }; };
template struct Zod { };
template using Zod_t = typename Zod::type;
static_assert(!dtect1::value, "");
Zod_t z2; // !!
[Bug c++/66839] g++ accepts NSDMI with -std=c++98 when the intializer is a macro defined in a standard header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66839
ensadc at mailnesia dot com changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #1 from ensadc at mailnesia dot com ---
Minimum reproducer (https://wandbox.org/permlink/rSm6lgfooMFZxvsI):
// file a.h
#pragma GCC system_header
#define TEST 0
// file prog.cc
#include "a.h"
struct X {
int t = TEST;
};
int main() {}
[Bug c++/52202] [C++11][DR 1376] Should not extend lifetime of temporary wrapped in static_cast to reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52202 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #2 from ensadc at mailnesia dot com --- Superseded by issue 1299? See http://wg21.link/p0727.
[Bug c++/79994] Concepts technical specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79994
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Simplified:
template
concept bool Graph = requires (G& g) {
add(g);
};
template
void add(T& g) {
};
class Directed_Graph_impl {};
int main() {
Directed_Graph_impl t;
add(t);
}
The problem seems to be that the instantiation of `add` requires the
instantiation of `Graph` concept, but the latter, in turn, requires the former.
This leads to an infinite recursion and eventually causes segfault.
