[Bug libstdc++/94562] New: C++20: std::shared_ptr{} <=> nullptr ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94562
Bug ID: 94562
Summary: C++20: std::shared_ptr{} <=> nullptr ill-formed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Target Milestone: ---
The following program (using -Wall -Wextra -std=c++2a -pedantic) is rejected:
#include
bool ok = std::shared_ptr{} <=> nullptr;
int main()
{
}
with the following diagnostics:
>>>>>>>>>>>>>>>>>>>>>>
prog.cc:3:34: error: no match for 'operator<=>' (operand types are
'std::shared_ptr' and 'std::nullptr_t')
3 | bool ok = std::shared_ptr{} <=> nullptr;
|~~^~~
In file included from
/opt/wandbox/gcc-head/include/c++/10.0.1/bits/stl_algobase.h:67,
from /opt/wandbox/gcc-head/include/c++/10.0.1/memory:63,
from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/10.0.1/bits/stl_iterator.h:474:5: note:
candidate: 'template requires
three_way_comparable_with<_IteratorR, _IteratorL, std::partial_ordering>
constexpr std::compare_three_way_result_t<_IteratorL, _IteratorR>
std::operator<=>(const std::reverse_iterator<_IteratorL>&, const
std::reverse_iterator<_IteratorR>&)' (reversed)
474 | operator<=>(const reverse_iterator<_IteratorL>& __x,
| ^~~~
/opt/wandbox/gcc-head/include/c++/10.0.1/bits/stl_iterator.h:474:5: note:
template argument deduction/substitution failed:
prog.cc:3:38: note: mismatched types 'const
std::reverse_iterator<_IteratorL>' and 'std::nullptr_t'
3 | bool ok = std::shared_ptr{} <=> nullptr;
| ^~~
In file included from
/opt/wandbox/gcc-head/include/c++/10.0.1/bits/stl_algobase.h:67,
from /opt/wandbox/gcc-head/include/c++/10.0.1/memory:63,
from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/10.0.1/bits/stl_iterator.h:1433:5: note:
candidate: 'template requires
three_way_comparable_with<_IteratorR, _IteratorL, std::partial_ordering>
constexpr std::compare_three_way_result_t<_IteratorL, _IteratorR>
std::operator<=>(const std::move_iterator<_IteratorL>&, const
std::move_iterator<_IteratorR>&)' (reversed)
1433 | operator<=>(const move_iterator<_IteratorL>& __x,
| ^~~~
/opt/wandbox/gcc-head/include/c++/10.0.1/bits/stl_iterator.h:1433:5: note:
template argument deduction/substitution failed:
prog.cc:3:38: note: mismatched types 'const std::move_iterator<_IteratorL>'
and 'std::nullptr_t'
3 | bool ok = std::shared_ptr{} <=> nullptr;
| ^~~
In file included from /opt/wandbox/gcc-head/include/c++/10.0.1/ranges:45,
from
/opt/wandbox/gcc-head/include/c++/10.0.1/bits/ranges_algobase.h:38,
from
/opt/wandbox/gcc-head/include/c++/10.0.1/bits/ranges_uninitialized.h:36,
from /opt/wandbox/gcc-head/include/c++/10.0.1/memory:69,
from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/10.0.1/optional:1036:5: note: candidate:
'template requires three_way_comparable_with<_Up, _Tp,
std::partial_ordering> constexpr std::compare_three_way_result_t<_IteratorL,
_IteratorR> std::operator<=>(const std::optional<_Tp>&, const
std::optional<_Up>&)' (reversed)
1036 | operator<=>(const optional<_Tp>& __x, const optional<_Up>& __y)
| ^~~~
/opt/wandbox/gcc-head/include/c++/10.0.1/optional:1036:5: note: template
argument deduction/substitution failed:
prog.cc:3:38: note: mismatched types 'const std::optional<_Tp>' and
'std::nullptr_t'
3 | bool ok = std::shared_ptr{} <=> nullptr;
| ^~~
In file included from /opt/wandbox/gcc-head/include/c++/10.0.1/ranges:45,
from
/opt/wandbox/gcc-head/include/c++/10.0.1/bits/ranges_algobase.h:38,
from
/opt/wandbox/gcc-head/include/c++/10.0.1/bits/ranges_uninitialized.h:36,
from /opt/wandbox/gcc-head/include/c++/10.0.1/memory:69,
from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/10.0.1/optional:1051:5: note: candidate:
'template constexpr std::strong_ordering std::operator<=>(const
std::optional<_Tp>&, std::nullopt_t)' (reversed)
1051 | operator<=>(const optional<_Tp>& __x, nullopt_t) noexcept
| ^~~~
/opt/wandbox/gcc-head/include/c++/10.0.1/o
[Bug c++/94563] New: Relational operations between pointer and nullptr accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94563
Bug ID: 94563
Summary: Relational operations between pointer and nullptr
accepted
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Target Milestone: ---
The following code is accepted for language versions c++14, c++17, as well as
c++20 using the following additional compiler flags:
-Wall -Wextra -pedantic
bool test(int* p)
{
return p < nullptr;
}
int main()
{
}
It should be noted, that a warning is emitted, satisfying the requirement for a
diagnostic in a strict sense:
>>>>>>>>>>>>>>
prog.cc: In function 'bool test(int*)':
prog.cc:3:12: warning: ordered comparison of pointer with integer zero
[-Wextra]
3 | return p < nullptr;
| ~~^
0
>>>>>>>>>>>>>>
This code should be ill-formed since the acceptance of
http://wg21.link/n3624
[Bug c++/94563] Relational operations between pointer and nullptr accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94563
--- Comment #1 from Daniel Krügler ---
To clarify the actual bug character of this issue, the following example shows
it more clearly:
template
bool test(T*)
{
return true;
}
int main()
{
test((int*)(nullptr));
}
This program should be ill-formed because the invalid expression
((T*) 0) < nullptr
should not make test available, but the code is accepted without any
diagnostics.
[Bug c++/94564] New: C++20: Three-way comparison between pointer and nullptr accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94564
Bug ID: 94564
Summary: C++20: Three-way comparison between pointer and
nullptr accepted
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Target Milestone: ---
The following program is accepted when compiling against C++20, but should be
rejected, because the C++20 working draft does not support three-way comparison
between pointer and std::nullptr_t (See [expr.spaceship] p6):
Compiler options:
-Wall -Wextra -pedantic -std=c++20
//---
#include
template nullptr), true) = false>
void test(T*)
{
}
int main()
{
test((int*)(nullptr));
}
//---
[Bug libstdc++/94565] New: C++20: Comparing comparison category types against 0/nullptr is not noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94565
Bug ID: 94565
Summary: C++20: Comparing comparison category types against
0/nullptr is not noexcept
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Target Milestone: ---
The following program should be accepted, but is rejected due to a violation of
the static_assertion:
Compiler options:
-Wall -Wextra -pedantic "-std=c++20"
//-
#include
int main()
{
static_assert(noexcept(std::partial_ordering::less == 0));
}
//-
prog.cc: In function 'int main()':
prog.cc:5:17: error: static assertion failed
5 | static_assert(noexcept(std::partial_ordering::less == 0));
| ^~
The corresponding comparison functions for are all declared as noexcept
([cmp.partialord], [cmp.weakord], [cmp.strongord]), so the clear intention is
that such an comparison should be observable as non-throwing operations. The
reason why above test fails for all of the existing mixed comparison functions
of all the three comparison category types against 0/nullptr is caused by the
fact that the implementation-internal type std::__cmp_cat::__unspec in header
misses to declare its converting constructor as noexcept:
struct __unspec
{
constexpr __unspec(__unspec*) { }
};
[Bug c++/94025] Expected-to-fail compilation goes through by not detecting mutable-specifier on lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94025
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
In my opinion, this issue does not demonstrate a bug, but is based on an
incomplete analysis of what is going on here.
1) It is correct, that the lambda function call operator is non-const in this
case. The result is that the function call operator of the lambda expression
will *not* be called in the shown example.
2) We have here a lambda expression without any capture. This means that the
standard requires the existence of an *additional* conversion function to a
pointer to function ([expr.prim.lambda.closure] p7 quoted from N4849). And
[expr.prim.lambda.closure] p11 says:
"The conversion function [..] is public, constexpr, non-virtual, non-explicit,
const, and has a non-throwing exception specification (14.5)."
So effectively a second function call resolution is in affect here, selecting
the conversion function (which is a const member function as specified above)
to function pointer as the only viable candidate (If both were viable, the
conversion function would be less preferred) via the surrogate call function
([over.call.object]). That explains IMO why the code is well-formed.
If you would try to mimic that with a user-defined class type, it would look
similar to the following one:
struct Lambda
{
using f_t = void();
f_t operator(); // "mutable"
using fptr_t = f_t*;
operator fptr_t() const;
};
Note that I use here the very rarely used syntax to declare (but not define) a
member function using a typedef for a function type to show the involved
function types more precisely.
The example would become invalid once you introduce a capture, because in this
case there would be no conversion function anymore.
I'm surprised that the Visual Studio compiler (I tested 2019) rejects the
original example, this looks like a bug to me, especially since that compiler
also handles the call resolution for the above defined Lambda type correctly. I
plan to report an issue for that compiler.
[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94554
--- Comment #3 from Daniel Krügler ---
(In reply to Melissa from comment #0)
> Clang errors on this case, so it's possible that my code is invalid: Is it
> legal to compare a function pointer against null in a constant-expression?
The example is ill-formed because the condition of 'if constexpr' is more
restricted than that of normal 'if': It expects "a contextually converted
constant expression of type bool" and [expr.const] p10 lists the allowed
conversions in this case. This list omits the boolean conversions
([conv.bool]).
But the example would become valid when rewritten as follows:
int meow() { return 1; }
void kitty(int);
template
void test() {
if constexpr (bool(F)) {
kitty(F());
} else {
kitty(2);
}
}
template void test();
template void test();
[Bug libstdc++/94049] For better diagnostics CPOs should not use concepts for operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94049
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
(In reply to Antony Polukhin from comment #0)
> Consider the following code:
>
> #include
> void foo0() {
> int t = 0;
> std::ranges::begin(t);
> }
>
>
> Diagnostics for it is mostly unreadable and points to the internals of
> libstdc++ https://godbolt.org/z/c-RwuY .
>
> This could be significantly improved. Right now the `requires` clause on
> `std::ranges::__cust_access::_Begin::operator()` duplicates the body of the
> function. So instead of such duplication all the requirements could be just
> asserted in the body:
>
>
> template
> constexpr auto
> operator()(_Tp&& __t) const noexcept(_S_noexcept<_Tp>()) {
> static_assert(__maybe_borrowed_range<_Tp>, "Not a borrowed range or
> lvalue");
> if constexpr (is_array_v>) {
> ...
> } else if constexpr (__member_begin<_Tp>)
> return __t.begin();
> else if constexpr (__adl_begin<_Tp>)
> return begin(__t);
> else
> static_assert(!sizeof(_Tp), "_Tp should have either a member begin() or
> an begin(_Tp&) should be in the namespace of _Tp");
> }
>
>
> This gives a much better diagnostics: https://godbolt.org/z/kmLGb7
> All the CPOs could be improved in that manner
Maybe, but that would make them non-conforming and they would not the advantage
of being usable in SFINAE conditions:
#include
#include
#include
template()))>
void test(T) {} // #1
void test(...){} // #2
int main() {
std::vector v;
test(v); // OK, calls #1
int i = 0;
test(i); // OK, but calls #2
}
Note that [customization.point.object] p4 says:
"The type T of a customization point object shall model invocable (18.7.2) when the types in Args... meet the requirements specified in
that customization point object’s definition. When the types of Args... do not
meet the customization point object’s requirements, T shall not have a function
call operator that participates in overload resolution."
[Bug c++/94619] String literals as non-type template parameter fails to compile with partial specialization of calling function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94619
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
The non-void return expression in the void bar function makes the example
ill-formed regardless of the other problem, so let's fix that first:
>>
template struct A {
char str [length];
constexpr A(char const (&s) [length]) {
for (unsigned i = 0; i < length; ++i)
str[i] = s[i];
}
};
template struct B {
auto bar() const {
return a.str;
}
};
//template void fu (Tconst& t) // Compiles successfully
template void fu (B const& t) // Does not compile
//template void fu (B> const& t) // Does not compile either
{
t.bar();
}
void test() {
B<":/"> m;
fu(m);
}
>>
[Bug libstdc++/91630] std::any SFINAE breaks valid code since 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91630 --- Comment #1 from Daniel Krügler --- This looks like a variant fo bug 90415 to me.
[Bug c++/94550] False positive with -Wparentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94550
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #2 from Daniel Krügler ---
(In reply to Andrew Pinski from comment #1)
> Do you have a full example? Where the problem occurs since your example
> does not compile at all.
A full working example would be (reduced by eliminating a huge number of
additional pointer indirections and simplifying the function declaration):
<<
struct failed {};
template
failed* (Pred::* * assert_arg(void (*)(Pred), typename Pred::type));
struct predicate { using type = int; };
using type = decltype(assert_arg(nullptr, 0));
<<
But honestly, to me these parentheses look *indeed* redundant to me, so I don't
really understand the issue here.
[Bug c++/94644] Wrong is_nothrow_move_constructible result if used in a template first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94644 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- First: The issue is unrelated to the "nothrow" part of the trait. The whole discussion can be reduced by considering the std::is_move_constructible trait alone, because it is the one that is causing the violations of your expectations. Now, is_move_constructible is just a special case of is_constructible: "For a referenceable type T, the same result as is_constructible_v, otherwise false." Let's now look at is_constructible (I'm omitting the part of the definition that is unrelated to object types): << The predicate condition for a template specialization is_constructible shall be satisfied if and only if the following variable definition would be well-formed for some invented variable t: T t(declval()...); [Note: These tokens are never interpreted as a function declaration. —end note] >> Now consider that your would try to write this variable definition with your type future_state_base (which has a protected destructor): It would be ill-formed, because for the variable definition you need a publicly accessible destructor. Therefore std::is_move_constructible::value should be false as well as std::is_nothrow_move_constructible::value. That's the reason why the first static_assert(std::is_nothrow_move_constructible::value, "future_state_base's move constructor must not throw"); is required to fail (That is when foo is defined), because static_assert(std::is_move_constructible::value, "future_state_base doesn't meet is_move_constructible"); is required to fail. The actual error in gcc seems to me the behaviour, when foo is not defined and when your second assertion (which is wrong) holds. This looks like a gcc error indeed and I think that clang is just right.
[Bug c++/94644] Wrong is_nothrow_move_constructible result if used in a template first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94644 --- Comment #3 from Daniel Krügler --- (In reply to Avi Kivity from comment #2) > PR 94033 is also related to constructibity trait testing with an > inaccessible constructor. Looks like the intrinsic depends on where it was > evaluated. Indeed this would be non-conforming, because we require ([meta.unary.prop] p8): "Access checking is performed as if in a context unrelated to T and any of the Args. Only the validity of the immediate context of the variable initialization is considered."
[Bug c++/94025] Expected-to-fail compilation goes through by not detecting mutable-specifier on lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94025 --- Comment #2 from Daniel Krügler --- (In reply to Daniel Krügler from comment #1) [..] > I'm surprised that the Visual Studio compiler (I tested 2019) rejects the > original example, this looks like a bug to me, especially since that > compiler also handles the call resolution for the above defined Lambda type > correctly. I plan to report an issue for that compiler. I have opened a corresponding bug report against the VS 2019 compiler: https://developercommunity.visualstudio.com/content/problem/990374/conversion-function-to-function-pointer-for-mutabl-1.html
[Bug c++/94721] New: C++2a: Three-way comparison operator for function pointers rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94721
Bug ID: 94721
Summary: C++2a: Three-way comparison operator for function
pointers rejected
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Target Milestone: ---
Using the compiler flags
-Wall -Wextra -std=c++2a -pedantic
the following code example
//--
#include
void foo() {}
void bar() {}
int main()
{
auto p1 = &foo;
auto p2 = &bar;
return (p1 <=> p2) != 0 ? 0 : 1;
}
//--
is rejected:
>>>>>>>>>>>>>>>
prog.cc: In function 'int main()':
prog.cc:10:14: error: invalid operands of types 'void (*)()' and 'void (*)()'
to binary 'operator<=>'
10 | return (p1 <=> p2) != 0 ? 0 : 1;
| ~~ ^~~ ~~
| | |
| | void (*)()
| void (*)()
<<<<<<<<<<<<<<<
This code should be accepted, because according to [over.built] p18:
"For every T, where T is [..] a pointer type, there exist candidate operator
functions of the form
[..]
R operator<=>(T, T);
where R is the result type specified in 7.6.8."
And 7.6.8 [expr.spaceship] p7 says:
"[..] If two pointer operands p and q compare equal (7.6.10), p <=> q yields
std::strong_ordering::equal; if p and q compare unequal, p <=> q yields
std::strong_ordering::less if q compares greater than p and
std::strong_ordering::greater if p compares greater than q (7.6.9). Otherwise,
the result is unspecified."
[Bug c++/94721] C++2a: Three-way comparison operator for function pointers rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94721 --- Comment #2 from Daniel Krügler --- (In reply to Marek Polacek from comment #1) > Confirmed, thanks for the report. Sigh, thanks. I'm starting to realize now, that it seems that the *intention* of https://wg21.link/p1959r0 adopted in November was to remove support of <=> on function pointers, but the current post-Prague wording paper seems to still have wording leftovers that mislead me to the interpretation expressed in this issue. I would like to withdraw this issue now and I'm starting a CWG discussion instead. My apologize for the false alarm.
[Bug c++/94819] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't Pt. 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94819
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #2 from Daniel Krügler ---
After removal of any library dependencies:
```c++
template
inline constexpr bool is_same_v = false;
template
inline constexpr bool is_same_v = true;
template
struct alphabet_tuple_base
{
template
requires is_same_v
constexpr alphabet_tuple_base(component_type) {} // commenting out
constexpr works?!
template
requires (!is_same_v)
alphabet_tuple_base(indirect_component_type) {}
};
template
struct structured_rna : alphabet_tuple_base {
using base_type = alphabet_tuple_base;
using base_type::base_type;
};
struct dna4 {};
struct rna4 {};
structured_rna t1{rna4{}}; // commenting out any of these works?!
structured_rna t2{dna4{}}; // commenting out any of these works?!
structured_rna t3{rna4{}}; // commenting out any of these works?!
int main() {}
```
[Bug c++/94923] False positive -Wclass-memaccess with trivially copyable std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94923
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
Corrected code without typos and including the necessary header files:
```
#include
#include
#include
#include
static_assert(std::is_trivially_copyable_v>);
void not_ok() {
std::optional value;
std::byte buf[128];
std::memcpy(&buf[0], &value, sizeof value);
std::memcpy(&value, &buf[0], sizeof value);
}
int main() {}
```
[Bug c++/95307] Compiler accepts reinterpret_cast in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
(In reply to Vincent Hamp from comment #0)
> The following snippet allows using reinterpret_casts inside a constexpr.
>
> #include
> uint64_t v;
> constexpr auto p{reinterpret_cast(&v) - 1u};
>
> Compiled with GCC 10.1 and 9.3 with -std=c++2a
>
>
> Interestingly subtracting 0u results in an error.
Here a library-free variant of the code including the compiler flags used:
-Wall -Wextra -std=gnu++2a -pedantic
tested using gcc 11.0.0 20200522 (experimental):
//<
using uint64_t = unsigned long;
static_assert(sizeof(uint64_t) * 8 == 64);
uint64_t v;
constexpr auto p{reinterpret_cast(&v) - 1u};
int main()
{
}
//>>>
The essential part of the reproducer is the fact that we have a variable of
static storage duration involved. Using a local variable in main() does make
the compiler reject the code.
[Bug c++/95242] [10/11 Regression] spurious "warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]" on comparisons with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242
--- Comment #3 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #2)
> Another way to implement the __unspec constructor would be:
>
> consteval __unspec(int __n) { if (__n != 0) throw __n; }
>
> But I think I discussed this with Richard Smith in Prague and we realised
> there was a problem with it, but I might be misremembering.
Remember that we need to ensure that this __unspec constructor needs to be
noexcept (See bug 94565), so this function could only do a terminate-like
action.
[Bug c++/95242] [10/11 Regression] spurious "warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]" on comparisons with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242
--- Comment #5 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #4)
> It's consteval, the throw is there to make it not a constant expression and
> give an error if anything except 0 is used. i.e. it can never throw, it
> either compiles or it doesn't.
Sure, I understand that, but that should still result in a failure of a static
assertion testing for noexcept, e.g. consider:
struct __unspec
{
consteval __unspec(int __n) { if (__n != 0) throw __n; }
};
static_assert(noexcept(__unspec(0)));
int main()
{
}
[Bug c++/95368] gcc things that a lambda capture is both const and mutable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95368
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
(In reply to Rafael Avila de Espindola from comment #0)
> gcc accepts
>
[..]
I found your code confusing, because the actual problem becomes visible only
under certain conditions. So lets make it a proper example, that shows the
problem immediately and lets ensure that we make it free from library
dependencies and provide all required information:
When using
gcc HEAD 11.0.0 20200525 (experimental)
and the following compiler flags
-Wall -Wextra -std=gnu++2a -pedantic
to compile this code:
//-
template
constexpr bool is_same_v = false;
template
constexpr bool is_same_v = true;
struct foo
{
void func() {}
};
void bar(foo& v) {
[v]() {
static_assert(is_same_v);
[v]() mutable {
static_assert(is_same_v);
v.func();
}();
}();
}
int main() {}
//-
the program is rejected (but should be accepted) with the following
diagnostics:
```
prog.cc: In lambda function:
prog.cc:17:16: error: passing 'const foo' as 'this' argument discards
qualifiers [-fpermissive]
17 | v.func();
|^
prog.cc:9:8: note: in call to 'void foo::func()'
9 | void func() {}
|^~~~
```
[Bug libstdc++/95322] std::list | take | transform, expression does not work cbegin() == end()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322 --- Comment #7 from Daniel Krügler --- (In reply to Jonathan Wakely from comment #6) > A new LWG issue has been submitted, and there is a suggested resolution. Will take care and inform in this issue here.
[Bug libstdc++/95322] std::list | take | transform, expression does not work cbegin() == end()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322 --- Comment #12 from Daniel Krügler --- (In reply to Daniel Krügler from comment #7) > (In reply to Jonathan Wakely from comment #6) > > A new LWG issue has been submitted, and there is a suggested resolution. > > Will take care and inform in this issue here. The new LWG issue exists now: https://cplusplus.github.io/LWG/issue3448
[Bug c++/95686] undefined reference to static local variable within inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95686
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #3 from Daniel Krügler ---
(In reply to Lénárd Szolnoki from comment #2)
> I failed to mention that I compiled the example in -std=c++17. With this
> compiler option it compiles but fails to link in gcc. It compiles, links and
> runs as expected in clang.
>
> The linkage requirement for reference/pointer non-type template arguments
> were lifted in C++17.
According to https://gcc.gnu.org/bugs/ the compile options have to be provided
for every bug report. Here is a slightly simplified reproducer free of any
library dependencies:
Compiler options:
-Wall -Wextra -std=c++2a -pedantic
//---
template
struct S {
static constexpr const int* value = ptr;
};
inline
auto foo() {
static const int i = 0;
return S<&i>{};
}
void bar(const int*){}
int main() {
bar(decltype(foo())::value);
}
//---
Diagnostic output:
//
/tmp/cci6dPre.o: In function `main':
prog.cc:(.text+0x10): undefined reference to `foo()::i'
collect2: error: ld returned 1 exit status
//
[Bug c++/56208] New: sizeof sfinae fails to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208
Bug #: 56208
Summary: sizeof sfinae fails to work
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
The following program becomes rejected when compiled with gcc 4.8.0 trunk using
the flags:
-Wall -pedantic
(with or without -std=c++11)
//
struct ostream {
ostream& operator<<(int);
};
struct sfinae_base {
typedef char one;
typedef char (&two)[2];
template
static T make();
template struct ok { typedef int type; };
template
static one test(typename ok() << make()
)>::type);
template
static two test(...);
};
template
struct is_printable : private sfinae_base
{
enum { value = sizeof(test(0)) == sizeof(one) };
};
typedef int ok[is_printable::value ? 1 : -1];
int main() {}
//
"Compilation finished with errors:
source.cpp:31:49: error: size of array 'ok' is negative
typedef int ok[is_printable::value ? 1 : -1];
^"
It worked with gcc 4.7.2 (also with Clang 3.2 or Intel-13), so this looks like
a regression to me. Operator<< is not the only one, I also noted problems with
other operators (such as binary plus).
[Bug c++/56208] sizeof sfinae fails to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208 --- Comment #1 from Daniel Krügler 2013-02-04 19:54:47 UTC --- I just notice that the problem is not restricted to sizeof sfinae. In fact if we define the first test overload as follows: template static one test(decltype( (make() << make()), 0 )); the same regression problem occurs. I'm confused.
[Bug c++/56208] sizeof sfinae fails to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208 --- Comment #2 from Daniel Krügler 2013-02-04 19:57:18 UTC --- The actually tested gcc version was 4.8.0 20130127 (experimental)
[Bug c++/56208] [4.8 Regression] Some classic sfinae cases fail to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208
Daniel Krügler changed:
What|Removed |Added
Summary|[4.8 Regression] sizeof |[4.8 Regression] Some
|sfinae fails to work|classic sfinae cases fail
||to work
--- Comment #4 from Daniel Krügler
2013-02-04 21:10:19 UTC ---
Here are two further variants of the first overload that fail to work since
4.8.0 trunk:
(a)
template struct res { typedef one type; };
template
static typename res() << make())>::type
test(int);
(b)
template struct res { typedef one type; };
template
static one
test(typename res() << make())>::type*);
Obviously the actual problem is not related to sizeof, so I changed the issue
title accordingly.
[Bug c++/56208] [4.8 Regression] Some classic sfinae cases fail to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208 --- Comment #5 from Daniel Krügler 2013-02-05 06:37:06 UTC --- I think I found the problem, the root is actually not related to sfinae (fortunately), but to the way how name-lookup in classes work in gcc. The problem can be fixed (as a workaround), if we move the static member function template static T make(); into namespace scope (as non-member function). I apologize for the lengthy thread within this issue. But it nonetheless is a regression, because that name-lookup worked correctly in previous versions of gcc.
[Bug c++/56208] [4.8 Regression] Some classic sfinae cases fail to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208
--- Comment #9 from Daniel Krügler
2013-02-05 19:09:15 UTC ---
Further data about the root of the problem: It seems actually to be an access
problem, the requirements for reproducing seem to be:
1) Some class B derives *privately* from a base class A
2) B refers to some function template f2 that refers to another dependent
function template f1 both in class scope of A (It doesn't matter whether these
function are actually public in A)
A reduced example is as follows:
//---
struct A {
template
static int f1();
template
static int f2(char(*)[sizeof(f1())]);
};
struct B : private A {
enum { value = sizeof(f2(0)) };
};
//---
"Compilation finished with errors:
source.cpp:10:35: error: no matching function for call to 'B::f2(int)'
enum { value = sizeof(f2(0)) };
^
source.cpp:10:35: note: candidate is:
source.cpp:6:15: note: template static int A::f2(char (*)[sizeof
(f1())])
static int f2(char(*)[sizeof(f1())]);
^
source.cpp:6:15: note: template argument deduction/substitution failed:
source.cpp: In substitution of 'template static int A::f2(char
(*)[sizeof (f1())]) [with T = int]':
source.cpp:10:35: required from here
source.cpp:3:15: error: 'static int A::f1() [with T = int]' is inaccessible
static int f1();
^
source.cpp:6:39: error: within this context
static int f2(char(*)[sizeof(f1())]);
^"
[Bug c++/56222] Pointer to member in lambda should not require this to be captured
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56222 --- Comment #2 from Daniel Krügler 2013-02-06 11:42:21 UTC --- The code looks valid to me, I don't see any reason for capturing something here. The expression "&Test::y" should be valid in that scope and returns an rvalue.
[Bug c++/56230] gcc aborts with "uninitialized const member" error even though an initializer is present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56230 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2013-02-06 19:35:15 UTC --- The problem seems to be fixed in 4.7.2 and in 4.8.0 trunk.
[Bug c++/56251] no DW_AT_const_value for static const member of a template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56251 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #7 from Daniel Krügler 2013-02-10 16:00:42 UTC --- (In reply to comment #6) I agree with Paolo and Andrew when considered as a potentially C++03 code, but I would like to add that the example code is indeed valid in C++11, because ellipsis functions such as printf have an lvalue-to-rvalue semantics for the function arguments and the ODR rule has been revised to say "A variable x whose name appears as a potentially-evaluated expression ex is odr-used unless x is an object that satisfies the requirements for appearing in a constant expression (5.19) and ex is an element of the set of potential results of an expression e, where either the lvalue-to-rvalue conversion (4.1) is applied to e, or e is a discarded-value expression (Clause 5)." Of-course this allowance doesn't require that an implementation needs to add "DW_AT_const_value" for such static const members: The rule only reflects existing practice that this use-case is no ODR-usage of CC::value or of TCC::tvalue, respectively.
[Bug c++/56319] [DR 1051] implicit copy constructor is not deleted for type with rvalue reference member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56319 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #4 from Daniel Krügler 2013-02-14 20:36:52 UTC --- Seems to be a dup of bug 55017
[Bug c++/54835] [C++11] Explicit default constructors not respected during copy-list-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 --- Comment #3 from Daniel Krügler 2013-02-16 11:57:21 UTC --- (In reply to comment #2) > I'm not opposed to this behavior, but I think it would be a language change. Thanks Jason. I just see now http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1518 Unless I'm mistaken, this is actually the relevant issue. I suggest to defer this issue and mark it with CWG 1518. I'm not sure how this would be best done, so leave it to the administrators of this list.
[Bug c++/56358] New: [C++11] Erroneous interaction of typedef and inherited constructor declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56358
Bug #: 56358
Summary: [C++11] Erroneous interaction of typedef and inherited
constructor declarations
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
The following code - compiled with the flags
-pedantic-errors -std=c++11 -Wall
is rejected by gcc 4.8.0 20130210 (experimental):
//--
template
struct A {};
template
struct B1 : A {
typedef A super_t;
using A::A; // #7
};
template
struct B2 : A {
using A::A;
typedef A super_t; // #13
};
//--
"7|error: declaration of 'using A::A' [-fpermissive]|
2|error: changes meaning of 'A' from 'struct A' [-fpermissive]|
13|error: 'A' does not name a type|
13|note: (perhaps 'typename A::A' was intended)"
It could be related to bug 56323, but I have currently no way to verify this
hypotheses.
My understanding is that both definitions of B1 and B2 should be valid. Note
that even though the typedefs referring to A are needed to produce the
error, even though at least in B1 its effects are completely unexpected.
[Bug c++/56387] Alias of class template wrongly seen as different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56387 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2013-02-19 09:16:50 UTC --- The problem also exists on 4.8.0 trunk
[Bug c++/56388] catch(...) in lambda rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56388
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-02-19 09:23:34 UTC ---
The problem also exists for 4.7.2, so no regression. The diagnostics is
interesting:
"7:9: error: '...' handler must be the last handler for its try block
[-fpermissive]
catch(...){
^"
[Bug c++/56358] [C++11] Erroneous interaction of typedef and inherited constructor declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56358
--- Comment #1 from Daniel Krügler
2013-02-20 12:09:13 UTC ---
As of the more recent trunk gcc 4.8.0 20130217 (experimental) these problems
have been partially reolved. Template B1 is now accepted, but template B2 still
causes problems. The reduced test case is:
//--
template
struct A {};
template
struct B : A {
using A::A;
typedef A super_t; // #7
};
//--
"7|error: 'A' does not name a type|
7|note: (perhaps 'typename A::A' was intended)"
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #3 from Daniel Krügler 2013-02-22 10:59:28 UTC --- (In reply to comment #2) > Isn't G++ correct? Foo::type exists unconditionally, so SFINAE doesn't apply. > The invalid type is not in the immediate context of the substitution. This was my initial reaction, too, but there is one point in this example where I need to find clarification: Both foo() templates have a *different* function parameter lists (one void, one with int). I'm yet unsure (due to lack of time studying whether 14.8.2 requires to check first parameter compatibility in the call context or not).
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #7 from Daniel Krügler 2013-02-22 22:01:18 UTC --- (In reply to comment #4) > I think 13.3 [over.match] ¶2 and 13.3.1 [over.match.funcs] ¶7 say the > function > template specialization must be generated before the number of arguments is > checked to see if the candidate function is viable. After a cross-check with the core language group I completely agree with Jonathan and exactly because of the paragraphs he quoted. Further-on, the example is ill-formed, but no diagnostics required, as of [temp.inst]p6: "If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place." This sentence explains the implementation divergence (Thanks to Richard Smith for reminding me to this part).
[Bug c++/56429] [C++11] Explicitly defaulted private constructor is not private
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56429 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2013-02-23 22:30:35 UTC --- This issue may have similar reasons as bug 54812.
[Bug c++/56506] variadic class template specialization not selected as best match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56506
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #2 from Daniel Krügler
2013-03-03 19:46:42 UTC ---
I don't think that either example should be accepted. My understanding is, that
the second T is still considered as a parameter pack but not as an expansion
(because it is not followed by ...) at the time of pattern match checking,
therefore the compiler would try to match a sequence of expansions from the
first T... with a corresponding parameter pack. But this pack is always
considered as a different type, even if it would contain the same single type
(e.g. consider an argument type Y, int> where we would try to match
'int' with '[int]' where I use square brackets to denote the still existing
pack). So both cannot be the same type, and this specialization can never be
found. It would work, if you would declare the partial specialization as:
template
struct X, U>...>
{
typedef int type;
};
because now the compiler don't needs to cross-match corresponding T expansions
with the U pack.
I understand that this is a somewhat more generous specialization as you would
like to have, though.
[Bug libstdc++/54043] [C++11] cout << nullptr does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54043 --- Comment #13 from Daniel Krügler 2013-03-04 10:46:27 UTC --- (In reply to comment #12) > Then I suppose that if anything this is library, not core, even if there are > interactions. Is there an open LWG DR? You may want to refer to: http://cplusplus.github.com/LWG/lwg-active.html#2221
[Bug c++/56506] variadic class template specialization not selected as best match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56506 --- Comment #4 from Daniel Krügler 2013-03-05 20:18:00 UTC --- (In reply to comment #3) Presumably my judgment was a bit premature and I think there is a logical flaw in my original argumentation: I think I misinterpreted 14.5.3 p5. I'm switching to observer-mode, but your examples are quite interesting because every compiler with variadic template support that I have access to rejects them. This seems to indicate some possible unforeseen case in existing models. I have forwarded this to the core language group.
[Bug libstdc++/56609] New: [C++11] Several type traits give incorrect results for std::nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56609 Bug #: 56609 Summary: [C++11] Several type traits give incorrect results for std::nullptr_t Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: daniel.krueg...@googlemail.com The following code is rejected when compiled with gcc 4.8.0 20130310 (experimental) or with gcc 4.7.2 using the flags -Wall -std=c++11 -pedantic //-- #include typedef decltype(nullptr) np_t; static_assert(std::is_scalar::value, ""); static_assert(!std::is_class::value, ""); static_assert(std::is_fundamental::value, ""); // #7 static_assert(!std::is_compound::value, ""); // #8 //-- "7|error: static assertion failed: | 8|error: static assertion failed: |" According to 3.9 p9 std::nullptr_t is a scalar type, I also read 3.9.1 p10 that it is a fundamental type. This is confirmed by 3.9.2 not listing anything that can be applied to std::nullptr_t. I think the code should be accepted.
[Bug libstdc++/56609] [C++11] Several type traits give incorrect results for std::nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56609 --- Comment #2 from Daniel Krügler 2013-03-13 09:55:33 UTC --- (In reply to comment #1) > Seems straightforward enough to be fixable in 4.8.0 too. Does this patchlet > cover all the issues you can see? Thanks Paolo! I cannot test this from here, but this fix is what I would have thought of as well.
[Bug c++/56636] strange interaction of dynamic_cast and unique_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #2 from Daniel Krügler 2013-03-20 08:38:22 UTC --- It also works for gcc 4.8.0 trunk using mingw 64.
[Bug c++/56636] strange interaction of dynamic_cast and unique_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636 --- Comment #4 from Daniel Krügler 2013-03-20 10:19:47 UTC --- (In reply to comment #3) I tested gcc 4.8.0 20130310 (experimental)
[Bug c++/56693] Fail to ignore const qualification on top of a function type.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56693 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2013-03-23 12:20:30 UTC --- This looks like http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1584 to me
[Bug c++/56762] too aggressive optimization or missing warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56762 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2013-03-28 12:15:30 UTC --- This line does not what you expect it would do (Search for "most vexing parse"): CLockGuard sGuard(CIntLock()); It does *not* construct an CIntLock object nor does it declare an sGuard object, instead it does declare a function and has no further effects.
[Bug c++/56782] New: [C++11] Regression with empty pack expansions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782
Bug #: 56782
Summary: [C++11] Regression with empty pack expansions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
As of gcc 4.8.0 the following code is now rejected when compiled with flags
-std=c++11 -Wall -W -pedantic
//---
template
T&& declval();
struct is_convertible_impl {
template
static void sink(T);
template(declval()))>
static auto test(int) -> char;
template
static auto test(...) -> char(&)[2];
};
template
struct is_convertible : is_convertible_impl
{
static const bool value = sizeof(test(0)) == 1;
};
template
struct enable_if {};
template
struct enable_if { typedef T type; };
template
struct conditional { typedef If type; };
template
struct conditional { typedef Else type; };
template
struct and_;
template<>
struct and_<>
{
static const bool value = true;
};
template
struct and_ : P
{
};
template
struct and_ : conditional::type
{
};
template
struct Tuple {
template...
>::value, int>::type
>
Tuple(U&&...){}
};
static_assert(is_convertible, Tuple>::value, "Ouch"); // OK
static_assert(is_convertible, Tuple<>>::value, "Ouch"); // Error
//---
The diagnostics being:
"
Compilation finished with errors:
source.cpp:18:48: error: template instantiation depth exceeds maximum of 900
(use -ftemplate-depth= to increase the maximum) substituting 'template static char (& is_convertible_impl::test(...))[2] [with
= Tuple<>; = Tuple<>]'
static const bool value = sizeof(test(0)) == 1;
^
source.cpp:55:5: recursively required from 'const bool is_convertible,
Tuple<> >::value'
source.cpp:55:5: required from 'const bool is_convertible, Tuple<>
>::value'
source.cpp:64:49: required from here
source.cpp:18:48: error: no matching function for call to
'is_convertible, Tuple<> >::test(int)'
source.cpp:18:48: note: candidates are:
source.cpp:9:15: note: template static char
is_convertible_impl::test(int)
static auto test(int) -> char;
^
source.cpp:9:15: note: template argument deduction/substitution failed:
source.cpp:12:15: note: template static char (&
is_convertible_impl::test(...))[2]
static auto test(...) -> char(&)[2];
^
source.cpp:12:15: note: substitution of deduced template arguments resulted in
errors seen above
source.cpp:64:1: error: non-constant condition for static assertion
static_assert(is_convertible, Tuple<>>::value, "Ouch"); // Error
^
source.cpp:64:1: error: the value of 'is_convertible, Tuple<> >::value'
is not usable in a constant expression
source.cpp:18:21: note: 'is_convertible, Tuple<> >::value' was not
initialized with a constant expression
static const bool value = sizeof(test(0)) == 1;
^
"
The code is accepted with gcc 4.7.2 and with Clang 3.2.
It seems that for empty expansions the compiler erroneously does enter into the
actually empty expansion:
is_convertible...
[Bug c++/56836] Template delegating constructor not calling target constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56836 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #4 from Daniel Krügler 2013-04-03 22:15:49 UTC --- I agree with Andrew: In this case the copy-constructor will be called, because the template constructor is not a better match (In C++11 template constructors can be selected for copying objects, but only if they have a better match as selected by overload resolution).
[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56868 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #6 from Daniel Krügler 2013-04-07 21:32:46 UTC --- IMO this behaviour should be considered in the light of http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#903 Assuming the P/R of this issue becomes accepted, both static_assert(g2(0) == 1, "g2 failed"); static_assert(g3(0) == 1, "g3 failed"); should fail.
[Bug c++/56874] Argument deduction failure due to non-deduced context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56874 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #3 from Daniel Krügler 2013-04-08 14:55:54 UTC --- I agree, it looks like bug 52072 to me.
[Bug c++/56889] =delete(ing) default copy and move operations for a polymorphic type gives compilation error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56889 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2013-04-09 09:10:52 UTC --- There are several problems in your example: 1) You have not declared a default constructor in template Stack, but you have provided user-declared constructors (The deleted ones). This has the effect that the Stack template has a no implicitly declared default constructor, which again has the effect that the initializer-list constructor generated by the compiler in vector_stack is deleted, because it would implicitly call the missing default constructor of Stack. Solution: Add a (defaulted) default constructor to the Stack template. 2) The clone function in vector_stack would call the copy constructor of that type. But this one is deleted, because the Stack template has an explicitly deleted copy constructor. This is a design error.
[Bug c++/56889] =delete(ing) default copy and move operations for a polymorphic type gives compilation error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56889 --- Comment #2 from Daniel Krügler 2013-04-09 09:36:29 UTC --- (In reply to comment #1) In addition I would like to remark that the precise declaration state of the inherited initializer-list constructor in vector_stack is unclear, because of http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1573 But the existing wording implies that any usage of this constructor would be ill-formed because of the unavailable default constructor of its base class.
[Bug c++/56889] =delete(ing) default copy and move operations for a polymorphic type gives compilation error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56889 --- Comment #5 from Daniel Krügler 2013-04-09 19:13:55 UTC --- This issue is not the right place for discussing programming idioms, but as a last comment to the code: Your reference to PL alone does not solve your programing error: You need to define a copy constructor in vector_stack, because the compiler-defined one is also deleted (because of the deleted one in the base class), or define the clone function without a copy constructor.
[Bug libstdc++/56905] New: [C++11][DR 1130] std::copy_exception should be removed or no longer be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56905 Bug #: 56905 Summary: [C++11][DR 1130] std::copy_exception should be removed or no longer be used Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: daniel.krueg...@googlemail.com According to http://cplusplus.github.io/LWG/lwg-defects.html#1130 std::copy_exception has been replaced by std::make_exception_ptr. While I understand that this function still exists for backward compatibility reasons in libstdc++, I noticed that other places of the library (such as ) still refer to std::copy_exception, which complicates a possible transition in the future. I would recommend to replace all usages of std::copy_exception by the library by std::make_exception_ptr. std::make_exception_ptr should be defined independent of std::copy_exception. Personally I would recommend to remove std::copy_exception, alternatively to define it in terms of std::make_exception_ptr.
[Bug libstdc++/56905] [C++11][DR 1130] std::copy_exception should be removed or no longer be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56905 --- Comment #2 from Daniel Krügler 2013-04-11 18:05:18 UTC --- Here is my suggestion for a possible test, to be compiled with flags -std=c++11 -Wall -W -pedantic //- #define copy_exception k42; #include #include //- This code should be accepted, but chokes currently (as expected).
[Bug c++/51577] dependent name lookup finds operator in global namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 --- Comment #4 from Daniel Krügler 2013-04-13 11:26:25 UTC --- (In reply to comment #3) > The example in PR 56943 gives a wrong-code example Could you explain why? It looks valid to me. According to my understanding, the free operator+ overload in global namespace is no valid candidate, but the member operator+ of N::A is one.
[Bug c++/51577] dependent name lookup finds operator in global namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 --- Comment #6 from Daniel Krügler 2013-04-13 11:55:36 UTC --- (In reply to comment #5) > and G++ calls the global one, returning the wrong result, so it's wrong-code OK, I misunderstood the meaning of "wrong-code": I thought that was intended to mean a code that should not compile. I see now that wrong-code is a specific keyword here (never used it before).
[Bug libstdc++/57049] std::swap does self move assignment, which is illegal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57049 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #2 from Daniel Krügler 2013-04-25 09:55:47 UTC --- Here are two different things to consider: 1) The standard library specification of basic_string's move-assignment operator currently requires that it works for self-assignment: 21 Effects: If *this and str are not the same object, modifies *this as shown in Table 71. [...] 22 If *this and str are the same object, the member has no effect. This might or might not change, depending on the outcome of LWG issue http://cplusplus.github.io/LWG/lwg-active.html#2063 2) The generic swap template from imposes requirements on the argument types and describes what it does (which can only rely on the requirements). So if you call swap with the same argument value and if for these argument values the move-assignment is undefined behaviour, you get what you are asking for. There is no single evidence that swap would be even allowed to prevent swapping for identical arguments, because the semantics are specified clearly to exchange the two values.
[Bug c++/56971] GCC claims a friend function to be overloaded, but it isn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56971 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #2 from Daniel Krügler 2013-04-25 10:55:08 UTC --- For gcc 4.9.0 20130421 (experimental) this gives me an ICE: "main.cpp|8|internal compiler error: canonical types differ for identical types b and b|"
[Bug c++/56976] using braces to initialize a reference forces copy construction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56976 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2013-04-25 11:04:31 UTC --- It seems to me as if you are observing the core language issue http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1604
[Bug c++/55708] g++ crashes: constexpr function with reference parameters.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55708 --- Comment #1 from Daniel Krügler 2013-04-26 10:37:55 UTC --- gcc 4.9.0 20130421 (experimental) accepts the code on my system (64-bit mingw).
[Bug c++/56953] Inheriting constructors triggers instantiation of parameters at point of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56953 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2013-04-26 19:09:43 UTC --- gcc 4.9.0 20130421 (experimental), compiled with flags -std=c++11 -Wall -pedantic-errors accepts the code as written on my system (mingw 64-bit).
[Bug c++/57092] [4.8/4.9 Regression] Using decltype of function pointer type to define a data member causes compiler crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57092 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #2 from Daniel Krügler 2013-04-27 22:40:20 UTC --- A similar ICE occurs for gcc 4.9.0 20130421 (experimental): main.cpp|3|internal compiler error: in finish_decltype_type, at cp/semantics.c:5406|"
gcc-bugs@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172
Bug #: 57172
Summary: [C++11][DR 1164] Template overload resolution
ambiguous for T&& versus T&
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
The following code is rejected by gcc 4.9.0 20130428 (experimental) using the
compiler flags
-std=c++11 -Wall -pedantic-errors
//-
template int f(T&){}
template int f(T&&);
int i;
int j = f(i);
//-
"main.cpp|4|error: call of overloaded 'f(int&)' is ambiguous|
main.cpp|4|note: candidates are:|
main.cpp|1|note: int f(T&) [with T = int]|
main.cpp|2|note: int f(T&&) [with T = int&]|"
This example was relevant for
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1164
and the core language has been adapted to make it well-formed as described by
[temp.deduct.partial] p9 b1. The compiler should select the first overload
here.
[Bug libstdc++/57139] std::tuple conversion constructor does the wrong checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57139 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #3 from Daniel Krügler 2013-05-06 11:35:05 UTC --- (In reply to comment #2) > Good point. Sadly, is_convertible is not equivalent to implicit convertibility > exactly due to that additional requirement (not sure if the latter is > intentional, or an StdLib defect). If at all this would be a core-language defect. > Does the paper you mention address std::tuple or std::is_convertible? The paper addresses std::tuple and std::pair. I don't see how the Library could change std::is_convertible, because it does exactly what the core language semantics require. The document number will be N3680 in the post-meeting mailing.
[Bug c++/57153] [C++11] tries to use copy constructor for in-class initialized member in default constructor of template struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57153 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2013-05-06 12:09:34 UTC --- I agree that the code should be accepted, because the member initializer performs direct-initialization. The very same problem also exists for gcc 4.9.0 20130428 (experimental).
[Bug c++/57176] copy elision with function arguments passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2013-05-06 12:23:02 UTC --- Unless I'm misunderstanding your suggestion I think that a compiler is not allowed to apply copy-elision here, because that case was explicitly excluded from 12.8 p31 by http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1148
[Bug c++/57176] copy elision with function arguments passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176 --- Comment #3 from Daniel Krügler 2013-05-06 13:11:15 UTC --- (In reply to comment #2) > Do you have a link to the discussion, or happen to remember the arguments? > I can see that there are more possible issues with the parameter (it lives > a little longer in the caller, which gives more chances to reuse it), but > the permission to move probably already breaks most such examples. I couldn't find any discussion in regard to this specific issue, but looking at http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#6 it seems that they would prefer to see a paper before the committee would perform any further action. It seems that inline functions are possibly less controversial and http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1049 addresses a similar problem in regard to inline functions with reference parameters.
[Bug c++/57196] [4.8 regression] Bogus "aggregate ... has incomplete type and cannot be defined"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57196
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-05-07 20:52:28 UTC ---
Here a more simplified version that reproduces the problem:
//---
#include
template
struct set {
set() = default;
set(std::initializer_list){}
};
struct string {
string(const char*){}
~string(){}
};
typedef decltype(sizeof(0)) size_t;
template struct EqHelper { };
int IsNullLiteralHelper(...);
void Fn() {
EqHelper{1})>eq1; // ok
EqHelper())> eq2; // ok
EqHelper{"foo"})> eq3; // error
}
//---
It seems to be relevant that string has a non-trivial destructor and that set
has an initializer-list constructor (When e.g. replacing
set(std::initializer_list){} by set(T){} causes the code to be accepted)
[Bug libstdc++/57220] New: [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220
Bug #: 57220
Summary: [mingw] Undefined reference to __mingw_strtod
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
Created attachment 30063
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30063
Output of -v -save-temps invokation
The following code when compiled with gcc 4.9.0 20130505 (experimental) using
mingw 64 bit using the compiler flags
-Wall
(with or without -std=c++11 or -pedantic-errors) causes a linker error:
//--
#include
int main() {}
//--
"c:\program
files\develop\gcc\bin\..\lib\gcc\x86_64-w64-mingw32\4.9.0\..\..\..\..\lib\libstdc++.a(c++locale.o)||In
function `strtod':|
\home\gfortran\gcc-home\binary\mingw32\native\x86_64\gcc\4.9-20130505\x86_64-w64-mingw32\include\stdlib.h|392|undefined
reference to `__mingw_strtod'"
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 Daniel Krügler changed: What|Removed |Added Keywords||link-failure --- Comment #1 from Daniel Krügler 2013-05-08 19:33:25 UTC --- I should add that the link error occurs whether or whether not the -m32 flag is provided to the compiler and linker
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 Daniel Krügler changed: What|Removed |Added CC||ktietz70 at googlemail dot ||com --- Comment #2 from Daniel Krügler 2013-05-08 19:35:13 UTC --- Kai, do you have any idea what may go wrong here?
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 --- Comment #5 from Daniel Krügler 2013-05-08 19:56:06 UTC --- (In reply to comment #3) Thanks for the litmus test, Kay. The result output I'm getting is: MinGW-W64 Runtime 3.0 (alpha - rev. 0) -00-00 so it seems this is indeed the version 3.0.
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 --- Comment #7 from Daniel Krügler 2013-05-08 20:25:44 UTC --- (In reply to comment #6) The attached '-v' '-save-temps' output indicates version 4.9.0 20130505 (experimental) (x86_64-w64-mingw32), but I'm not sure whether this is reliable in this context. The libmingwex.a file contains the string pattern __mingw_strtod twice, here the contexts of the findings: __tinytens_D2A __strtod __mingw_strtod __strtof __mingw_strtof 3 .rdata$zzz __mingw_strtod .rdata$zzz __strtodg /1900 The spaces shown here are actually NUL values. Is this information sufficiently precise?
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 --- Comment #9 from Daniel Krügler 2013-05-08 21:41:40 UTC --- (In reply to comment #8) > Well, you should us the nm tool to check for existance of a symbol. Grepping > for strings might lead you to wrong direction. My apologies, I had seen the "grep" and misinterpreted what you are asking for. I can't find the exact tool named x86_64-w64-mingw32-nm.exe, but nm.exe instead and it gave me also T __mingw_strtod > I don't see anything obviously wrong on you temp-file. The only thing I am a > bit confused about is that there seems to be a 4.7.2 directory used for crtend > object ... so it looks to me that you might be still using two different > runtimes and mixing stuff here happily. Ouch - I didn't notice that! This indeed looks like a potential candidate for the actual root of problem! > I just did a rebuild of all required stuff and I can't reproduce this issue. > The options you've shown initially have for sure nothing to do with > link-order, > or about use of libraries. Thanks very much for all your help. I will proceed tomorrow following the potential "gcc-4.7.2" path problem.
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 Daniel Krügler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #10 from Daniel Krügler 2013-05-08 22:09:14 UTC --- I couldn't resist and removed all gcc entries from the env PATH, which solved the problem. I apologize for the unnecessary trouble I have caused - at least I learned several new things about mingw.
[Bug c++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 --- Comment #13 from Daniel Krügler --- (In reply to Paolo Carlini from comment #10) FWIW, I fully agree with Jason: VLAs are very restricted and don't even allow for forming references to them, so that the standard library won't even try to provide begin()/end() overloads for them. You should use the new std::dynarray type instead for such support.
[Bug libstdc++/57250] New: [C++11] std::shared_ptr misses atomic_* support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57250
Bug ID: 57250
Summary: [C++11] std::shared_ptr misses atomic_* support
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Consider this as a reminder bug entry to provide the atomic_* overloads for
std::shared_ptr. A minimal test case could be:
#include
int main() {
const std::shared_ptr p;
bool is_lock_free = std::atomic_is_lock_free(&p);
std::shared_ptr p2 = std::atomic_load(&p);
std::shared_ptr p3 = std::atomic_load_explicit(&p,
std::memory_order_seq_cst);
std::atomic_store(&p2, p);
std::atomic_store_explicit(&p2, p, std::memory_order_seq_cst);
std::shared_ptr p4 = std::atomic_exchange(&p2, p);
p4 = std::atomic_exchange_explicit(&p2, p, std::memory_order_seq_cst);
bool chk = std::atomic_compare_exchange_weak(&p2, &p3, p);
chk = std::atomic_compare_exchange_strong(&p2, &p3, p);
chk = std::atomic_compare_exchange_weak_explicit(&p2, &p3, p,
std::memory_order_seq_cst, std::memory_order_seq_cst);
chk = std::atomic_compare_exchange_strong_explicit(&p2, &p3, p,
std::memory_order_seq_cst, std::memory_order_seq_cst);
}
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
The report misses a complete example. The following is a reduced form and free
of library stuff:
//---
struct true_type { enum { value = true }; };
struct false_type { enum { value = false }; };
template
struct Foo {};
template
struct is_instantiation_of_nontypes
{
template class TT, typename T>
struct check : false_type {};
template class TT, Ts... Args>
struct check> : true_type {};
};
static_assert(is_instantiation_of_nontypes::check >::value, "Ouch");
//---
compiled with gcc 4.9.0 20130505 (experimental) gives the error
"main.cpp|14|error: 'Ts ...' is not a valid type for a template non-type
parameter|
main.cpp|14|error: template argument 2 is invalid|
main.cpp|17|error: type/value mismatch at argument 1 in template parameter list
for 'template template >
class TT, class T> template template > class
TT, class T> struct is_instantiation_of_nontypes::check'|
\main.cpp|17|error: expected a template of type 'template
template > class TT', got 'template struct Foo'"
[Bug libstdc++/57250] [C++11] std::shared_ptr misses atomic_* support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57250 --- Comment #2 from Daniel Krügler --- (In reply to Jonathan Wakely from comment #1) Thanks for the pointer to the status page - sorry, I didn't check it before. For the future: Does it make sense to open such reminder bugs for "not yet complete C++11 support" or is it not really helpful for the process?
[Bug c++/57253] GCC ignores ref-qualifiers of pseudo-function types in explicit specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57253 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- They should be different specializations, yes.
[Bug libstdc++/57270] std::is_function ignores function ref-qualifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57270 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- I agree with that. And shortly after that we will hit the problem mentioned in http://cplusplus.github.io/LWG/lwg-active.html#2101
[Bug c++/57279] New: [C++11] alias declaration fails to declare function types with cv-qualifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57279 Bug ID: 57279 Summary: [C++11] alias declaration fails to declare function types with cv-qualifiers Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: daniel.kruegler at googlemail dot com The following code is rejected if compiled with gcc 4.9.0 20130505 (experimental) using the flags -std=c++11 -Wall -pedantic-errors // typedef void fc1() const; // OK typedef void frr1() &&; // OK typedef void fcr1() const &; using fc2 = void() const; // #4 using frr2 = void() &&; // OK using fcr2 = void() const &; // #6 // "main.cpp|4|error: invalid qualifiers on non-member function type| main.cpp|6|error: invalid qualifiers on non-member function type|" According to 8.3.5 [dcl.fct] p6 function type declarations with cv-qualifiers are valid via alias-declarations (b3).
[Bug c++/54198] [4.8 Regression] "error: invalid use of incomplete type" when building Chromium
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54198 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #3 from Daniel Krügler 2012-08-12 22:58:09 UTC --- (In reply to comment #2) > I actually think GCC is correct, A causes all member functions to be > instantiated. I disagree, the instantiation of A shall only instantiate all member *declarations*, but not the *definitions* of unused members.
[Bug c++/54235] Templates compile but don't link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54235 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-08-12 23:25:51 UTC --- The problem still exists in gcc 4.8 trunk
[Bug libstdc++/54249] New: [C++11] No ::nullptr_t in header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
Bug #: 54249
Summary: [C++11] No ::nullptr_t in header
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
gcc 4.8.0 20120729 (experimental) rejects the following code:
#include
::nullptr_t n;
"3|error: 'nullptr_t' in namespace '::' does not name a type"
This code is supposed to be accepted, because [depr.c.headers] p2 says:
"Every C header, each of which has a name of the form name.h, behaves as if
each name placed in the standard library namespace by the corresponding cname
header is placed within the global namespace scope."
Paolo Carlini has suggested to perform this change near to existing C++11-aware
code in stddef.h:
#if (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) \
|| (defined(__cplusplus) && __cplusplus >= 201103L)
#ifndef _GCC_MAX_ALIGN_T
#define _GCC_MAX_ALIGN_T
/* Type whose alignment is supported in every context and is at least
as great as that of any standard type not using alignment
specifiers. */
typedef struct {
long long __max_align_ll __attribute__((__aligned__(__alignof__(long
long;
long double __max_align_ld __attribute__((__aligned__(__alignof__(long
double;
} max_align_t;
#endif
#endif /* C11 or C++11. */
[I guess I have selected the wrong component. Please correct, if necessary]
[Bug libstdc++/54249] [C++11] No ::nullptr_t in header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249 Daniel Krügler changed: What|Removed |Added Keywords||rejects-valid --- Comment #1 from Daniel Krügler 2012-08-14 08:05:05 UTC --- I should add that the code example was compiled in C++11 mode
[Bug libstdc++/54249] [C++11] No ::nullptr_t in header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249 --- Comment #3 from Daniel Krügler 2012-08-14 09:52:30 UTC --- (In reply to comment #2) > (In reply to comment #0) > > "Every C header, each of which has a name of the form name.h, behaves as if > > each name placed in the standard library namespace by the corresponding > > cname > > header is placed within the global namespace scope." [..] > I believe someone (Howard maybe?) wanted to file a DR asking to remove this > paragraph. I don't want to start a lengthy discussion here about the C++ Standard Library specification, but it must be clear that removing above paragraph would have the effect of making the effects of including any <*.h> header in a C++ program undefined, because [depr.c.headers] is the only place in the Library specification that defines the semantics.
[Bug libstdc++/54249] [C++11] No ::nullptr_t in header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249 --- Comment #11 from Daniel Krügler 2012-08-14 11:01:47 UTC --- (In reply to comment #9) > I must also add that frankly personally I don't consider these issues so > serious: IMHO a new C++ project should immediately use the c* headers. I see > these issues mostly about legacy code. Completely agreed and therefore reducing the priority. The main reason for this bugzilla entry was not, because I need above code to be well-formed, but because there often exists uncertainty in the wild about the interpretation of the semantics of including the <*.h> headers. The issue came out of a lengthy discussion that I had about this semantics on the std-discussion group.
[Bug libstdc++/54249] [C++11] No ::nullptr_t in header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249 Daniel Krügler changed: What|Removed |Added Severity|normal |minor
[Bug c++/54250] Segmentation fault when decltype of a struct field is used in nested lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54250 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-08-15 21:15:16 UTC --- The problem still exists in gcc 4.8.trunk. Version 4.8.0 20120729 (experimental) delivers: 7|internal compiler error: vector VEC(tree,base) index domain error, in insert_capture_proxy at cp/semantics.c:8974
[Bug c++/54276] Lambda in a Template Function Undefined Reference to local static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54276 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-08-16 06:20:47 UTC --- The problem seems to be fixed in gcc 4.8.0 20120729 (experimental)
[Bug c++/54277] Template class member referred to with implicit this inside lambda is incorrectly const-qualified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54277 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-08-16 06:24:26 UTC --- The problem still exists in gcc 4.8.0 20120729 (experimental)
[Bug libstdc++/54289] setjmp isn't included into std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289
--- Comment #2 from Daniel Krügler
2012-08-16 19:38:16 UTC ---
The problem seems still to exist in gcc 4.8.0 20120729 (experimental).
Just to be sure that this is not due to a badly formed error description I
tested to compile the folowing code (C++03 or C++11 mode)
#include
std::jmp_buf b;
int main()
{
std::setjmp(b); // Error
}
"In function 'int main()':|
7|error: '_setjmp' is not a member of 'std'|
7|note: suggested alternative:|
c:\program files\develop\gcc\x86_64-w64-mingw32\include\setjmp.h|164|note:
'_setjmp'|"
