[Bug libstdc++/97869] New: defines __cpp_lib_span even when doesn't provide an implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97869 Bug ID: 97869 Summary: defines __cpp_lib_span even when doesn't provide an implementation Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- defines __cpp_lib_span if __cplusplus > 201703L and _GLIBCXX_HOSTED, but only provides a definition of std::span when __cpp_lib_concepts is defined.
[Bug libstdc++/97935] New: Missing subsumption in iterator category detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97935
Bug ID: 97935
Summary: Missing subsumption in iterator category detection
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
In :
template
requires (!requires { typename _Iter::iterator_category; }
&& __detail::__cpp17_randacc_iterator<_Iter>)
struct __cat<_Iter>
{ using type = random_access_iterator_tag; };
template
requires (!requires { typename _Iter::iterator_category; }
&& __detail::__cpp17_bidi_iterator<_Iter>)
struct __cat<_Iter>
{ using type = bidirectional_iterator_tag; };
template
requires (!requires { typename _Iter::iterator_category; }
&& __detail::__cpp17_fwd_iterator<_Iter>)
struct __cat<_Iter>
{ using type = forward_iterator_tag; };
The !requires part of the constraints do not subsume each other, so any
iterator that is a __cpp17_bidi_iterator or stronger causes an ambiguity. It
needs to be extracted into a concept.
[Bug c++/99081] New: Misleading -Wmissing-field-initializers warning on out-of-order designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99081
Bug ID: 99081
Summary: Misleading -Wmissing-field-initializers warning on
out-of-order designated initializers
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
struct A {
int a; int b;
};
A a { .b = 1, .a = 2};
with g++ -std=c++2a -O3 -Wall -Wextra produces
:5:21: warning: missing initializer for member 'A::a'
[-Wmissing-field-initializers]
5 | A a { .b = 1, .a = 2};
| ^
:5:21: error: designator order for field 'A::a' does not match
declaration order in 'A'
The real problem is the error, of course, but the warning is just noise and
also incorrect - there is an initializer for a in the code, after all.
[Bug c++/99273] New: List initialization prefers initializer_list a little too strongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99273
Bug ID: 99273
Summary: List initialization prefers initializer_list a little
too strongly
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
This is basically bug 64665 but closed back in 2015 - I think incorrectly.
Reduced test case:
#include
struct S { S(int); };
void f(std::initializer_list);
int f(int);
using T = decltype(f({1}));
using T = int;
GCC rejects (picking the initializer_list overload); Clang accepts.
{1} to initializer_list is a user-defined conversion
(https://eel.is/c++draft/over.ics.list#5); {1} to int is a standard conversion
- in particular, the identity conversion
(https://eel.is/c++draft/over.ics.list#10.1). Since the conversion sequences
are not of the same basic form, https://eel.is/c++draft/over.ics.rank#2
controls and says that the latter is better.
DR 1467 modified what is now https://eel.is/c++draft/over.ics.rank#3.1 to say
that a list initialization sequence that converts to initializer_list is better
than any other list-initialization sequence "even if one of the other rules in
this paragraph would otherwise apply", but paragraph 3 only applies when the
two conversion sequences have the same basic form. In the above example, they
don't.
[Bug libstdc++/100290] New: join_view::_Iterator::operator++ copies _M_parent->_M_inner when _S_ref_is_glvalue is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100290
Bug ID: 100290
Summary: join_view::_Iterator::operator++ copies
_M_parent->_M_inner when _S_ref_is_glvalue is false
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
auto&& __inner_range = [this] () -> decltype(auto) {
if constexpr (_S_ref_is_glvalue)
return *_M_outer;
else
return _M_parent->_M_inner;
}();
This is a copy in the else case due to decltype(auto) producing the declared
type of _M_inner. The lambda should return auto&&.
[Bug c++/100368] New: Missing guaranteed elision in constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100368
Bug ID: 100368
Summary: Missing guaranteed elision in constexpr evaluation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
struct S {
S() = default;
S(const S&) = delete;
};
struct array {
S s[2];
};
struct PS {
constexpr array operator*() const { return {}; }
};
struct W {
constexpr W(const PS& p) // 1
: t(*p) {}
array t;
};
W w(PS{});
This issues a spurious complaint on trunk and then ICEs:
source>: In constructor 'constexpr W::W(const PS&)':
:17:14: error: use of deleted function 'array::array(array&&)'
17 | : t(*p) {}
| ^
:7:8: note: 'array::array(array&&)' is implicitly deleted because the
default definition would be ill-formed:
7 | struct array {
|^
:7:8: error: use of deleted function 'S::S(S&&)'
:4:3: note: declared here
4 | S(S&&) = delete;
| ^
:17:14: internal compiler error: tree check: expected target_expr, have
error_mark in bot_manip, at cp/tree.c:3095
17 | : t(*p) {}
| ^
0x1d002c9 internal_error(char const*, ...)
???:0
0x67b4e3 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0x13967e3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x9ad0ae break_out_target_exprs(tree_node*, bool)
???:0
0x72aa0a maybe_save_constexpr_fundef(tree_node*)
???:0
0x7b0711 finish_function(bool)
???:0
0x8e2c4d c_parse_file()
???:0
0xa63232 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
[Bug c++/100374] New: Type-constraints of member function templates should not be substituted into during implicit instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100374
Bug ID: 100374
Summary: Type-constraints of member function templates should
not be substituted into during implicit instantiation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
template
concept C = true;
template
struct Foo
{
template U>
void bar()
{
}
};
Foo f;
GCC trunk with -std=c++20 produces:
: In instantiation of 'struct Foo':
:13:12: required from here
:8:8: error: 'float' is not a class, struct, or union type
8 | void bar()
|^~~
[temp.inst]/17 says that type-constraints like C should
not be substituted into during the implicit instantiation of the declaration of
Foo::bar:
The type-constraints and requires-clause of a template specialization or member
function are not instantiated along with the specialization or function itself,
even for a member function of a local class; substitution into the atomic
constraints formed from them is instead performed as specified in
[temp.constr.decl] and [temp.constr.atomic] when determining whether the
constraints are satisfied or as specified in [temp.constr.decl] when comparing
declarations.
[Bug libstdc++/100479] New: range adaptors handle cached iterators incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100479
Bug ID: 100479
Summary: range adaptors handle cached iterators incorrectly
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
template
struct _CachedPosition<_Range>
{
private:
iterator_t<_Range> _M_iter{};
public:
constexpr bool
_M_has_value() const
{ return _M_iter != iterator_t<_Range>{}; }
constexpr iterator_t<_Range>
_M_get(const _Range&) const
{
__glibcxx_assert(_M_has_value());
return _M_iter;
}
constexpr void
_M_set(const _Range&, const iterator_t<_Range>& __it)
{
__glibcxx_assert(!_M_has_value());
_M_iter = __it;
}
};
- The domain of == for forward iterators is limited to iterators over the same
underlying sequence. While value-initialized forward iterators of the same type
may be compared against each other, comparing them against iterators into other
ranges is not required to be well-defined, so it cannot be used as a sentinel
value.
- The cache cannot be allowed to propagate when the view containing it is
copied/moved, and has to be invalidated when the view containing it is moved.
Any cached iterator points to the original underlying view, and not the new
one; also, moving from a view can change its value (if it is well-defined to
use the moved-from view), so the cache is no longer valid. (Handling this case
correctly was actually the original use case for non-propagating-cache in
range-v3.)
[Bug c++/100579] New: [coroutines] Poor codegen using an optional-like type with co_await
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100579
Bug ID: 100579
Summary: [coroutines] Poor codegen using an optional-like type
with co_await
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
#ifdef __clang__
#include
namespace stdx = std::experimental;
#else
#include
namespace stdx = std;
#endif
struct O {
~O() {}
struct promise_type {
O get_return_object() { return O{this};}
stdx::suspend_never initial_suspend() { return {}; }
stdx::suspend_never final_suspend() noexcept { return {}; }
void return_void(){ value->b = true; }
void unhandled_exception(){ throw; }
auto await_transform(O o) {
struct A {
bool await_ready() {
return o_.b;
}
void await_resume() {}
void await_suspend(stdx::coroutine_handle<> h){
h.destroy();
}
O o_;
};
return A{o};
}
O* value;
};
explicit O(promise_type* p){ p->value = this; }
explicit O(bool b) : b(b) {}
bool b = false;
};
O g();
O f() { co_await g(); co_return; }
This is basically a reduced version of
https://github.com/facebook/folly/blob/99f856ae2009a80b157b5121e44b1f70f61bd7c9/folly/Optional.h#L613-L678
GCC does not appear to be able to optimize away the coroutine frame allocation,
while Clang does: https://gcc.godbolt.org/z/7981o81ne
[Bug c++/100592] New: Bogus "qualifiers cannot be applied" error with reference type produced by dependent alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100592
Bug ID: 100592
Summary: Bogus "qualifiers cannot be applied" error with
reference type produced by dependent alias template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
template
struct meta {
template
using if_c = T;
};
template<>
struct meta {
template
using if_c = U;
};
template
using if_c = typename meta::template if_c;
template
inline constexpr bool b = false;
template
using foo = if_c, int, T>;
template
struct type {};
template
using test = type const&>;
template
test f();
void g() {
f();
}
GCC rejects:
: In function 'void g()':
:32:12: error: no matching function for call to 'f()'
32 | f();
| ~~~^~
:29:9: note: candidate: 'template test f()'
29 | test f();
| ^
:29:9: note: template argument deduction/substitution failed:
: In substitution of 'template using test = type >::if_c&> [with T = int&]':
:29:9: required by substitution of 'template test f()
[with T = int&]'
:32:12: required from here
:26:7: error: 'const' qualifiers cannot be applied to
'meta::if_c' {aka 'int&'}
26 | using test = type const&>;
| ^~~~
[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100631
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #4 from TC ---
(In reply to 康桓瑋 from comment #1)
> Another issue is that in elements_view::_Sentinel in ranges#L3677:
>
>
> templatetypename _Base2 = __detail::__maybe_const_t<_Const2, _Vp>>
> requires sized_sentinel_for, iterator_t<_Base2>>
> friend constexpr range_difference_t<_Base2>
> operator-(const _Iterator<_Const2>& __x, const _Sentinel& __y)
> { return __x._M_current - __y._M_end; }
>
>
> the return type of the function is range_difference_t<_Base2>, but in
> [range.elements#sentinel], it is defined as range_difference_t:
>
>
> template
> requires sized_sentinel_for, iterator_t const>>
> friend constexpr range_difference_t
> operator-(const iterator& x, const sentinel& y);
>
>
> Perhaps range_difference_t and range_difference_t<_Base2> are
> equivalent in this case, but I am not sure.
This one is a problem with the WP.
[Bug c++/100708] New: dynamic_cast can convert xvalue to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100708
Bug ID: 100708
Summary: dynamic_cast can convert xvalue to lvalue
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
GCC accepts
struct A { virtual ~A() {}; };
struct B : A {} b;
void g ()
{
dynamic_cast(static_cast(b));
}
[expr.dynamic.cast]/2 says that for dynamic_cast(v):
If T is an lvalue reference type, v shall be an lvalue of a complete class
type, and the result is an lvalue of the type referred to by T.
[Bug libstdc++/100768] New: Range iterator operations should be function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100768 Bug ID: 100768 Summary: Range iterator operations should be function objects Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- They are currently implemented as plain function templates, which don't meet the requirements in http://eel.is/c++draft/range.iter.ops.general#2
[Bug libstdc++/100823] New: Special member functions of common_iterator should be conditionally trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100823 Bug ID: 100823 Summary: Special member functions of common_iterator should be conditionally trivial Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- At least as a QoI matter, the special member functions of common_iterator should be trivial when the corresponding special member function of variant is. Given that the standard depicts a variant exposition-only member with implicitly declared special member functions, it is arguable that this is actually required. There appears to be a couple other conformance issues too: - the move special members are missing - the copy assignment calls the converting assignment operator, but unlike the latter, there's no !valueless_by_exception() precondition on the (implicitly declared) copy assignment.
[Bug c++/100825] function signature constraints are not a part of mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #7 from TC --- I think the code is valid; it's just that the ABI doesn't have a mangling for constraints yet: https://github.com/itanium-cxx-abi/cxx-abi/issues/24
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #21 from TC ---
(In reply to David Friberg from comment #19)
>
> P0398R0 [1] describes the final resolution to CWG 1518, after which the
> following example is arguably well-formed:
>
It's not. Explicitness of a constructor is not considered when forming implicit
conversion sequences from a braced-init-list, and therefore the assignment is
ambiguous because {} can convert to either S or tag_t, even though the latter
is ill-formed if actually used.
[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100940 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #4 from TC --- (In reply to Patrick Palka from comment #3) > Good point, confirmed. Though I'm not sure if perfect forwarding here is > strictly necessary to fix this testcase. Perhaps the > _S_has_simple_extra_args versions of _Partial should be forwarding the bound > arguments as prvalues instead of as const lvalues? It's pretty easy to come up with counterexamples that don't work (for example, the type might be move-only). It may be better to limit the "simple" case for take/drop to when the argument type is integer-like; that's like 99% of uses anyway. Contrived examples gets the perfect forwarding fun but that's fine. Similarly, it might be a good idea to restrict the "simple" case for the other adaptors a bit - perhaps to the case where the predicate is trivially copyable, which should still give good diagnostic for a lot of uses, but avoids a performance hit if the function object at issue is like...std::function.
[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100940 --- Comment #7 from TC --- (In reply to Patrick Palka from comment #6) > > For the other adaptors, we still unconditionally disable perfect forwarding > call wrapper semantics. I'm not sure if the performance/diagnostic tradeoff > is worth it to enable perfect forwarding semantics when the function object > is non-trivial. Personally, I'd happily pay some diagnostic complexity when I get things wrong if that means I get better performance when I get things right. Good diagnostics only matter when my code is broken, while performance matters when my code is working. The former should (hopefully) be a transient condition.
[Bug c++/101113] g++ thinks constructor suppressed by a requires clause is actually a bad copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101113 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #2 from TC --- https://eel.is/c++draft/class.copy.ctor#5 I don't think this code is valid. The constraint (which isn't checked until overload resolution time anyway) can't suppress the outright ill-formedness of the declaration.
[Bug c++/101107] Misleading error message in aggregate initialization in CRTP base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101107 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #1 from TC --- Since `*this` can't initialize an `A`, it's assuming brace elision. Not sure how the diagnostic can be made clearer though...perhaps it can report that assumption?
[Bug libstdc++/108952] Regression in uses_allocator_construction_args for pair of rvalue references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #3 from TC --- https://cplusplus.github.io/LWG/issue3527
[Bug libstdc++/109111] New: Definition of repeat_view::_Iterator has wrong template-head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109111 Bug ID: 109111 Summary: Definition of repeat_view::_Iterator has wrong template-head Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- In : template requires (is_object_v<_Tp> && same_as<_Tp, remove_cv_t<_Tp>> && (__detail::__is_integer_like<_Bound> || same_as<_Bound, unreachable_sentinel_t>)) class repeat_view : /* ... */ template requires __detail::__is_integer_like<_Bound> || same_as<_Bound, unreachable_sentinel_t> class repeat_view<_Tp, _Bound>::_Iterator The requires-clause should match. Clang trunk diagnoses this (but not GCC, so there's probably a compiler bug here too).
[Bug libstdc++/106932] Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #8 from TC --- https://cplusplus.github.io/LWG/issue3057?
[Bug c++/102247] Overload resolution with brace-init is ambiguous when it shouldn't be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102247
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #2 from TC ---
struct X { explicit X() {} };
struct Y { Y() {} };
void f(X);
void f(Y);
void g() {
f({}); // GCC rejects, clang accepts
}
GCC is correct. For copy-list-initialization, explicitness of constructor is
not considered in forming implicit conversion sequences; rather, if a explicit
constructor is chosen, the program is ill-formed. See core issue 1228 and
[over.match.list].
[Bug c++/102247] Overload resolution with brace-init is ambiguous when it shouldn't be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102247 --- Comment #4 from TC --- See also PR 60027 and its duplicates.
[Bug libstdc++/102447] std::regex incorrectly accepts invalid bracket expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #5 from TC --- Hmm, but C++'s normative reference is to a 1999 version of ECMAScript...which might well have the "legacy" behavior? (I haven't looked at it in detail.)
[Bug libstdc++/102447] std::regex incorrectly accepts invalid bracket expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447 --- Comment #7 from TC --- (In reply to Jonathan Wakely from comment #6) > I have looked in detail (I have the 3rd, 4th and 5th editions here) but my > brain started oozing out of my ears. > > 15.10.2.15 NonemptyClassRanges and 15.10.2.16 NonemptyClassRangesNoDash are > the relevant sections of the 1999 3rd edition. The former defines: > > The internal helper function CharacterRange takes two CharSet parameters > A and B and performs the following: > 1. If A does not contain exactly one character or B does not contain > exactly > one character then throw a SyntaxError exception. > > And the latter has this note: > > Informative comments: ClassRanges can expand into single ClassAtoms and/or > ranges of two ClassAtoms separated by dashes. In the latter case the > ClassRanges includes all characters between the first ClassAtom and the > second ClassAtom, inclusive; an error occurs if either ClassAtom does not > represent a single character (for example, if one is \w) or if the first > ClassAtom's code point value is greater than the second ClassAtom's code > point value. > > > > The ClassAtom \w does not contain exactly one character, so I think it's a > syntax error. > > The 3rd edition doesn't mention any legacy features of RegExp, but it does > seem to require the strict behaviour. I've looked at the 1999 spec now, and agree with your reading.
[Bug libstdc++/101263] non-propagating-cache::emplace-deref missing constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101263
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #7 from TC ---
(In reply to Barry Revzin from comment #6)
> The "real" answer is allowing constexpr placement new, but that obviously
> doesn't help you right now.
>
> But I think the helpful answer is that you can add a constructor to your
> storage like storage(init_from_invoke_t, Args&&... args) that initializes
> the underlying value from invoke((Args&&)args...), and then
> construct_at(&storage, init_from_invoke, [&]() -> decltype(auto) { return
> *i; }).
>
> Something like that?
Yes. Something at that level of generality will be needed for the new
optional::transform, so it seems the better approach.
In my proof-of-concept implementation (which didn't have that concern), I used
something tailored to this specific case, along the lines of
struct __deref_tag {};
template
struct __cache_wrapper {
template
constexpr __cache_wrapper(__deref_tag, const _Iter& __i)
: __t(*__i) {}
_Tp __t;
};
and then stored a __non_propagating_cache<__cache_wrapper>>
__cache, so that emplace-deref(i) is __cache.emplace(__deref_tag{}, i);
[Bug libstdc++/102863] New: Optional monadic ops should not be constrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102863
Bug ID: 102863
Summary: Optional monadic ops should not be constrained
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
It's important that these are not constrained with invocable; that constraint
can trigger hard errors during overload resolution. For instance:
void f(int&);
int main() {
std::optional x;
x.transform([](auto& y) { f(y); return 42; });
}
: In instantiation of 'main():: [with auto:3 = const
int]':
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:2565:26:
required by substitution of 'template static
std::__result_of_success()((declval<_Args>)()...)),
std::__invoke_other> std::__result_of_other_impl::_S_test(int) [with _Fn =
main()::; _Args = {const int&}]'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:2576:55:
required from 'struct std::__result_of_impl, const int&>'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:3038:12:
recursively required by substitution of 'template
struct std::__is_invocable_impl<_Result, _Ret, true, std::__void_t > [with _Result = std::__invoke_result,
const int&>; _Ret = void]'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:3038:12:
required from 'struct std::is_invocable, const
int&>'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:3286:71:
required from 'constexpr const bool
std::is_invocable_v, const int&>'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/concepts:336:25:
required by substitution of 'template requires invocable<_Fn,
const _Tp&> constexpr auto std::optional::transform(_Fn&&) const & [with
_Fn = int]'
:7:16: required from here
:7:32: error: binding reference of type 'int&' to 'const int' discards
qualifiers
7 | x.transform([](auto& y) { f(y); return 42; });
| ~^~~
:3:8: note: initializing argument 1 of 'void f(int&)'
3 | void f(int&);
|^~~~
[Bug c++/102802] Selection of inherited operator contrary to `using` clause in C++ when using lambda type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102802 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #3 from TC --- No, this is valid. B's operator() is not visible, but its conversion to function pointer is, and that introduces a surrogate call function during the overload resolution for the function call expression (and it's selected because it is the only viable candidate).
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #4 from TC --- I don't think this needs an extra constraint, just reordering the existing ones to check not-a-span (14.3, "remove_cvref_t is not a specialization of span") first. But this is very much undefined anyway.
[Bug libstdc++/111050] New: [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 Bug ID: 111050 Summary: [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ABI Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d changed _Hash_node_value_base to no longer derive from _Hash_node_base, which means that its member functions expect _M_storage to be at a different offset. So explosions result if an out-of-line definition is emitted for any of the member functions (say, in a non-optimized build) and the resulting object file is then linked with code built using older version of GCC/libstdc++.
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 --- Comment #2 from TC --- The impacted members we observed are `_Hash_node_value_base::_M_valptr` and `_Hash_node_value_base::_M_v`. I think the layout of `_Hash_node` didn't change. And I'm not seeing why fixing this will require breaking ABI again. For example, if the affected functions are marked always_inline (or renamed, or have their mangling otherwise changed), I would expect the resulting code to be linkable with either the GCC10 version or the current version of the code, unless I'm missing something?
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050
--- Comment #5 from TC ---
Minimal example:
$ cat lib1.cpp
#include
#include
static std::unordered_set set;
void del(const std::string& s) {
set.erase(s);
}
$ cat lib2.cpp
#include
#include
static std::unordered_set set;
void add(const std::string& s) {
set.emplace(s);
}
const std::string& get(const std::string& s) {
return *set.find(s);
}
$ cat main.cpp
#include
void add(const std::string&);
void del(const std::string&);
const std::string& get(const std::string&);
int main() {
add("foo");
del("bar");
(void) get("foo").size();
}
$ g++-10 -std=c++17 lib1.cpp -c -o lib1.o
$ g++-13 -std=c++17 lib2.cpp -c -o lib2.o
$ g++-13 -std=c++17 main.cpp lib1.o lib2.o -o test
$ ./test
Segmentation fault (core dumped)
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050
--- Comment #6 from TC ---
The crash is gone if lib2.o is compiled with bits/hashtable_policy.h patched
like so:
--- a/path/to/gcc-13/include/c++/13.2.0/bits/hashtable_policy.h
+++ b/hashtable_policy.h
@@ -327,18 +327,22 @@ namespace __detail
__gnu_cxx::__aligned_buffer<_Value> _M_storage;
+ [[__gnu__::__always_inline__]]
_Value*
_M_valptr() noexcept
{ return _M_storage._M_ptr(); }
+ [[__gnu__::__always_inline__]]
const _Value*
_M_valptr() const noexcept
{ return _M_storage._M_ptr(); }
+ [[__gnu__::__always_inline__]]
_Value&
_M_v() noexcept
{ return *_M_valptr(); }
+ [[__gnu__::__always_inline__]]
const _Value&
_M_v() const noexcept
{ return *_M_valptr(); }
I'm following up with my reporter to see if this also fixes the problem with
their actual code.
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 --- Comment #7 from TC --- Confirmed with my reporter that this fixes their actual code too.
[Bug c++/115801] [modules] segfault instantiating a template with a templated friend declaration referring to an unexported template using a qualified name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115801 --- Comment #3 from TC --- (In reply to Nathaniel Shead from comment #2) > On looking further into it I believe this is ice-on-invalid. > > By https://eel.is/c++draft/temp.friend#2, within main.cpp the name ::Foo is > looked up as if the specialisation had been explicitly declared at its point > of instantiation. Are you saying that this paragraph requires a name lookup of ::Foo at the point of instantiation? I thought this paragraph is about how the instantiation affects future name lookup, as the note describes. The idea that I can't befriend an internal helper class without exporting it seems surprising.
[Bug c++/116298] New: No error when taking address of overloaded member function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116298
Bug ID: 116298
Summary: No error when taking address of overloaded member
function template
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
struct X {
template
E f() const;// #1
template
E f() const;// #2
template
E f(int) const; // #3
};
auto x = &X::f;
GCC accepts and appears to pick #1. If #2 is removed GCC correctly rejects.
[Bug c++/116606] New: unavailable attribute on virtual function causes error on object construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116606
Bug ID: 116606
Summary: unavailable attribute on virtual function causes error
on object construction
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html says that
"Other than emitting an error rather than a warning, the unavailable attribute
behaves in the same manner as deprecated."
But GCC trunk rejects
struct C {
__attribute__((unavailable)) virtual void f() {}
};
C c;
:2:47: error: 'virtual void C::f()' is unavailable
2 | __attribute__((unavailable)) virtual void f() {}
| ^
:2:47: note: declared here
even though the version with deprecated doesn't emit a warning.
[Bug c++/116636] New: Deprecation warning/unavailable error when overriding member of virtual base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116636
Bug ID: 116636
Summary: Deprecation warning/unavailable error when overriding
member of virtual base class
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Repro:
struct B {
virtual void f() = 0;
};
struct C : virtual B {
[[deprecated("meow")]]
void f() override {}
};
:6:24: warning: 'virtual void C::f()' is deprecated: meow
[-Wdeprecated-declarations]
6 | void f() override {}
|^
:6:10: note: declared here
6 | void f() override {}
| ^
Likewise:
struct B {
virtual void f() = 0;
};
struct C : virtual B {
[[gnu::unavailable("meow")]]
void f() override {}
};
:6:24: error: 'virtual void C::f()' is unavailable: meow
6 | void f() override {}
|^
:6:10: note: declared here
6 | void f() override {}
| ^
Making the base class non-virtual makes the warning/error go away.
[Bug libstdc++/109165] New: std::hash>::operator() should be const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109165 Bug ID: 109165 Summary: std::hash>::operator() should be const Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- Cpp17Hash requires const-callability.
[Bug middle-end/109224] New: Wmismatched-new-delete false positive with corotuines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109224
Bug ID: 109224
Summary: Wmismatched-new-delete false positive with corotuines
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
#include
struct Task {
struct promise_type {
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() { throw; }
Task get_return_object() { return {}; }
void return_void() {}
template
void* operator new(std::size_t sz, I);
void operator delete(void* ptr, std::size_t);
};
};
Task f(int) {
co_return;
}
int main() {
f(42);
}
g++ -std=c++20 -Wall produces (https://gcc.godbolt.org/z/vjvrPr6dc):
: In function 'Task f(int)':
:20:1: warning: 'static void Task::promise_type::operator delete(void*,
std::size_t)' called on pointer returned from a mismatched allocation function
[-Wmismatched-new-delete]
20 | }
| ^
:20:1: note: returned from 'static void* Task::promise_type::operator
new(std::size_t, I) [with I = int]'
20 | }
| ^
This is basically how coroutine frame allocation works (the promise type's
operator new can optionally view the coroutine's parameters, while operator
delete doesn't). Notably C++23 std::generator does something like this and the
reference implementation triggers the same warning.
Oddly enough, if operator new is not a template, i.e., operator new(size_t,
int), there's no warning.
[Bug c++/109232] New: Using deduced return type in an unevaluated context leads to codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232
Bug ID: 109232
Summary: Using deduced return type in an unevaluated context
leads to codegen
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
auto begin(auto&& r) {
return r.begin();
}
namespace {
struct R {
int* begin();
};
}
static_assert(__is_same(decltype(begin(R())), int*));
int main() {}
Even though ::begin is only used in an unevaluated context, GCC at -O0
generates code for begin, leading to a warning and a failure to link
(https://gcc.godbolt.org/z/cdajoP7f3):
:10:14: warning: 'int* {anonymous}::R::begin()' used but never defined
10 | int* begin();
| ^
/opt/compiler-explorer/gcc-trunk-20230320/bin/../lib/gcc/x86_64-linux-gnu/13.0.1/../../../../x86_64-linux-gnu/bin/ld:
/tmp/cc7gqEhh.o: in function `auto begin<(anonymous namespace)::R&>((anonymous
namespace)::R&)':
:2: undefined reference to `(anonymous namespace)::R::begin()'
collect2: error: ld returned 1 exit status
Execution build compiler returned: 1
[Bug libstdc++/109242] C++2b std::optional::transform omits required std::remove_cv_t from return optional type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109242 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #1 from TC --- The missing remove_cv_t is real, but this example is invalid. As the linked cppreference page notes, you cannot pass a PMD to transform.
[Bug c++/109655] New: Prior friend declaration causes "confused by earlier errors, bailing out" with missing constraint on out-of-class class template member definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109655
Bug ID: 109655
Summary: Prior friend declaration causes "confused by earlier
errors, bailing out" with missing constraint on
out-of-class class template member definition
Product: gcc
Version: 13.1.0
URL: https://gcc.godbolt.org/z/dvTbz8vcj
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
class C
{
template
requires true
friend class D;
};
template
requires true
class D {
void f();
};
template // missing "requires true"
void D::f()
{
}
With gcc 13.1, g++ -std=c++20 (or c++2b) produces
'
:15: confused by earlier errors, bailing out
Removing the in-class friend declaration produces a proper error message:
:12:14: error: redeclaration of 'template requires true class
D' with different constraints
12 | void D::f()
|
[Bug c++/109688] SPDLOG build fails with C++20 and -DSPDLOG_USE_STD_FORMAT=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109688 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #6 from TC --- https://cplusplus.github.io/LWG/issue3636 clarifies that formatter::format must be const, which is not the case in that example.
[Bug c++/109803] New: [12 Regression] ICE with type defined in lambda inside generic lambda inside function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109803
Bug ID: 109803
Summary: [12 Regression] ICE with type defined in lambda inside
generic lambda inside function template
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Repro:
template
void foo(T) {
[](auto){
[] {
struct X {};
};
};
}
template void foo(int);
: In instantiation of 'void foo(T) [with T = int]':
:10:22: required from here
:4:9: internal compiler error: Segmentation fault
4 | [] {
| ^
0x1bbabfe internal_error(char const*, ...)
???:0
0x10b0223 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10b0516 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10b0223 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x870a79 check_for_bare_parameter_packs(tree_node*, unsigned int)
???:0
0x8a7dfb finish_expr_stmt(tree_node*)
???:0
0x891a08 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x87e337 instantiate_decl(tree_node*, bool, bool)
???:0
0x899e8b instantiate_pending_templates(int)
???:0
0x7a5298 c_parse_final_cleanups()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/111854] new (align_val_t) should be ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111854 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #7 from TC --- Per https://eel.is/c++draft/basic.stc.dynamic.deallocation#3.sentence-4, `void operator delete(void*, std::size_t, std::align_val_t);` is a usual deallocation function just like `void operator delete(void*, std::size_t);` and therefore this should be rejected for the same reason that the example in comment #3 is rejected.
[Bug libstdc++/112569] libstdc++-v3/include/ranges:1456: missing check for self-assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112569 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #1 from TC --- This is exactly as it should be. There's no guarantee that self-move-assignment on the associated range is a no-op, so the cache must be invalidated.
[Bug c++/110164] New: Improve diagnostic for incomplete standard library types due to missing include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110164 Bug ID: 110164 Summary: Improve diagnostic for incomplete standard library types due to missing include Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- If I forget to include a header before using a sufficiently well-known standard library type, GCC helpfully reminds me of the header: $ echo 'std::array x;' | g++ -x c++ - :1:6: error: ‘array’ in namespace ‘std’ does not name a template type :1:1: note: ‘std::array’ is defined in header ‘’; did you forget to ‘#include ’? But if I happen to have a different standard library header included that happens to bring in a forward declaration of the type, the error message is less helpful: $ echo -e '#include \nstd::array x;' | g++ -x c++ - :2:21: error: aggregate ‘std::array x’ has incomplete type and cannot be defined It would be nice if the latter case also has a hint about the potential missing include.
[Bug c++/115561] New: [14/15 Regression] ICE checking constraints when a local class is involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115561
Bug ID: 115561
Summary: [14/15 Regression] ICE checking constraints when a
local class is involved
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Reduced test case:
template
auto declval() noexcept -> _Tp&&;
template
struct enable_if
{ };
template
struct enable_if
{ using type = _Tp; };
template
using enable_if_t = typename enable_if<_Cond, _Tp>::type;
template
struct is_void
{ static constexpr bool value = false; };
template
using invoke_result_t =
decltype(declval()(declval()...));
template
using iter_reference_t = decltype(*declval());
struct iter_move_fn
{
template
constexpr
auto operator() (I &&i) -> void;
} iter_move;
template
using iter_rvalue_reference_t = decltype(iter_move(declval()));
template
concept same_as = true;
template
concept readable_concept_ =
same_as, iter_rvalue_reference_t>;
template
concept indirectly_readable =
readable_concept_>;
template
using indirect_result_t =
enable_if_t,
invoke_result_t>>;
template
concept transformable =
(!is_void>::value);
template
requires transformable
constexpr void transform(I, Fun)
{
}
void foo()
{
struct B {};
(void) transform((B*)nullptr, [](B) {return 0; });
}
With GCC 14.1, g++ -std=c++20 crashes:
test2.cpp: In substitution of ‘template requires
transformable constexpr void transform(I, Fun) [with I = foo()::B*; Fun
= foo()::]’:
test2.cpp:65:21: required from here
65 | (void) transform((B*)nullptr, [](B) {return 0; });
|~^
test2.cpp:34:51: internal compiler error: Segmentation fault
34 | using iter_rvalue_reference_t = decltype(iter_move(declval()));
| ~^~~~
0xe9ea2f crash_signal
../../gcc/toplev.cc:319
0x8fc014 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.cc:2971
0x8c9cd7 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:21081
0x8ce166 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:16929
0x8cf7a4 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:13923
0x77dfbf normalize_concept_check
../../gcc/cp/constraint.cc:761
0x77dfbf normalize_atom
../../gcc/cp/constraint.cc:816
0x77dfbf normalize_expression
../../gcc/cp/constraint.cc:886
0x77e5f1 normalize_concept_check
../../gcc/cp/constraint.cc:795
0x77e5f1 normalize_atom
../../gcc/cp/constraint.cc:816
0x77e5f1 normalize_expression
../../gcc/cp/constraint.cc:886
0x780070 get_normalized_constraints
../../gcc/cp/constraint.cc:898
0x780070 normalize_concept_definition
../../gcc/cp/constraint.cc:1016
0x780070 satisfy_nondeclaration_constraints
../../gcc/cp/constraint.cc:3225
0x780070 constraint_satisfaction_value
../../gcc/cp/constraint.cc:3411
0x78275e evaluate_concept_check(tree_node*)
../../gcc/cp/constraint.cc:3459
0x76d7e3 cxx_eval_constant_expression
../../gcc/cp/constexpr.cc:8519
0x7740b7 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.cc:8857
0x777bd5 maybe_constant_value(tree_node*, tree_node*, mce_value)
../../gcc/cp/constexpr.cc:9145
0x8cada4 convert_nontype_argument
../../gcc/cp/pt.cc:7521
Also crashes on godbolt GCC trunk. GCC 13.2 compiles this OK. Moving the
definition of struct B to global scope makes the crash go away.
[Bug c++/115757] New: [modules] [[maybe_unused]] not honored in member function of imported class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115757
Bug ID: 115757
Summary: [modules] [[maybe_unused]] not honored in member
function of imported class template
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
// test.cpp
module;
export module test;
export template
class Foo {
public:
void foo(int n [[maybe_unused]]) { }
};
// main.cpp
import test;
int main() {
Foo f;
f.foo(1);
}
Produces the following warning with -Wall -Wextra
(https://godbolt.org/z/4vv15G9Yd):
In module test, imported at /app/main.cpp:2:
test.cpp: In instantiation of 'void Foo@test<
>::foo(int) [with = void]':
main.cpp:6:8: required from here
6 | f.foo(1);
| ~^~~
test.cpp:8:18: warning: unused parameter 'n' [-Wunused-parameter]
8 | void foo(int n [[maybe_unused]]) { }
| ^~
I would expect the attribute to suppress the warning. If Foo isn't a template
this works as expected.
[Bug middle-end/109224] Wmismatched-new-delete false positive with coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109224 --- Comment #2 from TC --- (In reply to Brian Bi from comment #1) > I'm also encountering this issue, and I can't find any way to write the code > that avoids triggering the warning, so I will simply have to disable the > warning until this issue is fixed. I think I had some luck with marking them as always_inline.
[Bug c++/115801] New: [modules] segfault instantiating a template with a templated friend declaration referring to an unexported template using a qualified name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115801
Bug ID: 115801
Summary: [modules] segfault instantiating a template with a
templated friend declaration referring to an
unexported template using a qualified name
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
// test.cpp
module;
export module test;
template
struct Foo {};
export
template
class Bar
{
private:
template
friend struct ::Foo; // #1
};
// main.cpp
import test;
int main() {
Bar x;
}
On compiler explorer: https://godbolt.org/z/4MT58K3nj
/opt/compiler-explorer/gcc-snapshot/bin/g++ -fdiagnostics-color=always -Wall
-Wextra -g -std=gnu++20 -MD -MT CMakeFiles/demo.dir/main.cpp.o -MF
CMakeFiles/demo.dir/main.cpp.o.d -fmodules-ts
-fmodule-mapper=CMakeFiles/demo.dir/main.cpp.o.modmap -MD -fdeps-format=p1689r5
-x c++ -o CMakeFiles/demo.dir/main.cpp.o -c /app/main.cpp
In module test, imported at /app/main.cpp:2:
test.cpp: In instantiation of 'class Bar@test':
main.cpp:5:12: required from here
5 | Bar x;
|^
test.cpp:5:8: internal compiler error: Segmentation fault
5 | struct Foo {};
|^~~
0x26df0a5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1],
diagnostic_t)
???:0
0x26ecc52 internal_error(char const*, ...)
???:0
0xcd19e8 instantiate_class_template(tree_node*)
???:0
0xb2a559 start_decl_1(tree_node*, bool)
???:0
0xb4d25f start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
???:0
0xc708aa c_parse_file()
???:0
0xdc7489 c_common_parse_file()
???:0
Removing the :: qualification at #1 or exporting Foo makes this work.
[Bug sanitizer/117976] New: ubsan false positive invoking pointer to derived member with base class type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117976
Bug ID: 117976
Summary: ubsan false positive invoking pointer to derived
member with base class type
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
struct B1 {
virtual ~B1() = default;
int x;
};
struct B2 {
virtual ~B2() = default;
int y;
};
struct D : B1, B2 {
int x;
void f() {}
};
int main() {
D d;
B2* b = &d;
auto mptr = static_cast(&D::f);
(b->*mptr)();
}
This example should be valid. [expr.static.cast]/12:
> A prvalue of type “pointer to member of D of type cv1 T” can be converted to a
> prvalue of type “pointer to member of B of type cv2 T”, where D is a complete
> class type and B is a base class of D, if cv2 is the same cv-qualification
> as,
> or greater cv-qualification than, cv1. [...] If class B contains the original
> member, or is a base class of the class containing the original member, the
> resulting pointer to member points to the original member. Otherwise, the
> behavior is undefined.
> [Note 6: Although class B need not contain the original member, the dynamic
> type of the object with which indirection through the pointer to member is
> performed must contain the original member; see [expr.mptr.oper]. — end note]
The "original member" is D::f; B2 is a base class of D, so the resulting
pointer to member points to the original member. The dynamic type of the object
is D, which does contain the original member.
However, g++ -fsanitize=undefined && ./a.out complains:
test.cpp:20:15: runtime error: member call on address 0x7fff8d80 which does
not point to an object of type 'B2'
0x7fff8d80: note: object is of type 'D'
ff ff ff ff 68 14 40 00 00 00 00 00 0d 14 40 00 00 00 00 00 88 14 40 00 00
00 00 00 00 00 00 00
^~~
vptr for 'D'
Using clang++ reports no errors.
PR92678 looks similar, though that one is calling through the derived type
instead of the base type.
[Bug libstdc++/118408] New: regex does not work under dual ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118408 Bug ID: 118408 Summary: regex does not work under dual ABI Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- Despite regex itself (and regex_traits) being ABI-tagged, std::__detail::_Scanner is not, and that class contains a data member _StringT _M_value; aka basic_string<_CharT>. Even though _Scanner is only used as a member of _Compiler which _is_ ABI-tagged by virtual of its regex_traits template argument, the member functions of _Scanner still need to be mangled differently if both ABIs are to co-exist in the same program. It may be too late to fix this though, but it's nice to at least have an issue to track it. This was raised in https://stackoverflow.com/questions/51382355/stdregex-and-dual-abi a long time ago, but unfortunately not reported then.
[Bug c++/120243] [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
--- Comment #1 from TC ---
A similar example but with an initially suspended coroutine terminates at -O2
or highter.
#include
struct coro {
struct promise_type {
promise_type() = default;
std::suspend_always initial_suspend() const noexcept { return {}; }
std::suspend_always final_suspend() const noexcept { return {}; }
void unhandled_exception() { throw; }
coro get_return_object() { return
{std::coroutine_handle::from_promise(*this)}; }
void return_void() {}
};
std::coroutine_handle h;
};
int main() {
auto c = []() -> coro {
throw "hello";
__builtin_abort();
co_return;
};
try {
c().h.resume();
}
catch(...) {
__builtin_printf("Caught!\n");
}
}
[Bug c++/120243] New: [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
Bug ID: 120243
Summary: [15/16 Regression] Exception rethrown from coroutine
promise type unhandled_exception not caught under -O1
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
#include
struct coro {
struct promise_type {
promise_type() = default;
std::suspend_never initial_suspend() const noexcept { return {}; }
std::suspend_never final_suspend() const noexcept { return {}; }
void unhandled_exception() { throw; }
coro get_return_object() { return {}; }
void return_void() {}
};
};
int main() {
auto c = []() -> coro {
throw "hello";
__builtin_abort();
co_return;
};
try {
c();
}
catch(...) {
__builtin_printf("Caught!\n");
}
}
This prints "Caught!" with -O0 but terminates with
> terminate called after throwing an instance of 'char const*'
with -O1 or higher.
[Bug c++/120370] New: GCC fails to parse a trailing requires-clause that ends with an identifier when followed by a ctor-initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120370
Bug ID: 120370
Summary: GCC fails to parse a trailing requires-clause that
ends with an identifier when followed by a
ctor-initializer
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
struct C {
int j;
static constexpr bool i = true;
template
C(T&&) requires i : j() {}
};
:5:23: error: found ':' in nested-name-specifier, expected '::'
5 | C(T&&) requires i : j() {}
| ^
| ::
:5:21: error: 'i' is not a class, namespace, or enumeration
5 | C(T&&) requires i : j() {}
| ^
:5:27: error: 'C' declared as function returning a function
5 | C(T&&) requires i : j() {}
| ^
Clang accepts.
