[Bug libstdc++/113470] Should std::tuple_size be a complete type?

[daniel.kruegler at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113470

--- Comment #1 from Daniel Krügler  ---
I think the essence is how [tuple.helper] p4 is specified. Combining with
[tuple.syn],

template struct tuple_size; // not defined
template struct tuple_size;

I tend to read that a definition is required for tuple_size. I would
understand if that interpretation is not universally accepted.

[Bug libstdc++/108760] ranges::iota is not included in

[daniel.kruegler at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760

--- Comment #3 from Daniel Krügler  ---
(In reply to Michael Levine from comment #2)
> (In reply to Daniel Krügler from comment #1)
> > (In reply to 康桓瑋 from comment #0)
> > > It seems wrong that libstdc++ needs to include  for 
> > > ranges::iota.
> > 
> > I agree, this looks like a defect, both std::iota and std::ranges:iota are
> > specified to be part of header 
> 
> Should it not require including  even though it seems to be a use
> of a constrained algorithm through C++20 that is in the namespace
> std::ranges?  https://en.cppreference.com/w/cpp/algorithm

Following https://cplusplus.github.io/LWG/lwg-defects.html#1178 we have
according to [res.on.headers] p1

"A C++ header shall provide the declarations and definitions that appear in its
synopsis."

and I'm interpreting this that an implementation needs to make it work without
requiring the user to include .

But we have https://cplusplus.github.io/LWG/issue3679 which raises a similar
question for a different issue. If the libstdc++ maintainers think that the
current wording does require a conforming program to include , I
think that an LWG issue would be required.

[Bug c++/112099] GCC doesn't recognize matching friend operator!= to resolve ambiguity in operator==

[daniel.kruegler at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112099

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
This could be related to https://cplusplus.github.io/CWG/issues/2804.html

[Bug libstdc++/108760] ranges::iota is not included in

[daniel.kruegler at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
(In reply to 康桓瑋 from comment #0)
> It seems wrong that libstdc++ needs to include  for ranges::iota.

I agree, this looks like a defect, both std::iota and std::ranges:iota are
specified to be part of header 

[Bug c++/110853] New: [c++-concepts] Bad interaction between deduction guide with decay and constraints

[daniel.kruegler at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110853

Bug ID: 110853
   Summary: [c++-concepts] Bad interaction between deduction guide
with decay and constraints
   Product: gcc
   Version: 14.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 simplified code snippet demonstrates a breakage our company code
when updating gcc from C++17 to C++20. I'm starting first with the original
example, because it provides a bit more context information:


#include 

void value_twice(int& result)
{
  result = 2 * result;
}

auto key_value_gen()
{
  return std::pair("key", value_twice);
}

int main()
{
}


Using gcc HEAD 14.0.0 20230728 and compiled with the previous settings
-Wall -Wextra -pedantic -std=c++17
the code is accepted, but switching to
-Wall -Wextra -pedantic -std=c++20
it becomes rejected with the following diagnostics:


In file included from /opt/wandbox/gcc-head/include/c++/14.0.0/utility:69,
 from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/14.0.0/bits/stl_pair.h: In instantiation of
'struct std::pair':
/opt/wandbox/gcc-head/include/c++/14.0.0/bits/stl_pair.h:307:57:   required by
substitution of 'template pair(const _T1&, const _T2&)->
std::pair<_T1, _T2> requires (std::pair<_T1, _T2>::_S_constructible)() [with _T1 = char [4]; _T2 = void(int&)]'
prog.cc:10:38:   required from here
/opt/wandbox/gcc-head/include/c++/14.0.0/bits/stl_pair.h:194:11: error: data
member 'std::pair::second' invalidly declared function
type
  194 |   _T2 second;///< The second member
  |   ^~

Note that std::pair has a "decaying" deduction guide

template
pair(T1, T2) -> pair;

but the error message reveals that attempts the produce a std::pair of the
undecayed types.

Additional information:
a) Current MSVC accepts the code but clang also rejects it but for different
reasons than gcc (see below).
b) I'm aware that a simple workaround exists by returning std::pair("key",
_twice) instead, and this is what we did to fix this. Nonetheless I think
that not everyone is able to fix such a problem in similar code when it was
provided by thirdparty libraries.

Basically the same error occurs when we use std::tuple(value_twice) instead.

The C++20 std::pair implementation uses noexcept, conditional explicit, and
trailing requires-clause based on static member functions as predicates, but
for gcc the problem can be reduced to the trailing requires-clause alone:

--
#define WITH_FUNC 1

template
constexpr bool is_copy_constructible_v = true;

template
struct p
{
  T1 first;

  static constexpr bool do_is_copy_constructible()
  {
return true;
  }

  p(const T1& t1) 
 requires (
#if WITH_FUNC
  do_is_copy_constructible()  // Line 19
#else
  is_copy_constructible_v
#endif
 )
  : first(t1) 
{}
};

template
p(T1) -> p;

void value_twice(int& result)
{
  result = 2 * result;
}

auto value_gen()
{
  return p(value_twice); // line 38
}

int main() {}
--

If we define WITH_FUNC to 0, the code is accepted, otherwise (as shown above),
the code is rejected with:

--
prog.cc: In instantiation of 'struct p':
prog.cc:19:31:   required by substitution of 'template p(const T1&)->
p requires (p::do_is_copy_constructible)() [with T1 = void(int&)]'
prog.cc:38:23:   required from here
prog.cc:9:6: error: data member 'p::first' invalidly declared
function type
9 |   T1 first;
  |  ^
--

Note that clang does accept the reduced case, even though it rejects the
original example as well due to slightly different reasons, which I will report
separately to them.

The reduced case uses the same implementation strategy as libstdc++ by means of
a static member function. What's special here is that the body of such a
function is a complete-class context of p, which I guess causes the error here
because the trailing requires-clause is not a complete-class context of p, so
one could say that this is actually a libstdc++ defect to use this
implementation strategy, it seems odd to me that the compiler attempts to
instantiate p with the undecayed function here and would like to open this
initially as compiler defect since the corresponding function does not actually
depend on p being complete. Feel free to correct me, but in case of a
correction of my understanding I would like to change this to a libstdc++ issue
instead of closing it because that wou

[Bug tree-optimization/95825] [10/11/12/13 Regression] boost::optional -Wuninitialized with -fsanitize=address

[daniel.kruegler at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95825

--- Comment #8 from Daniel Krügler  ---
(In reply to daniel.klauer from comment #7)
> Reduced test case:
> 
> 
> template
> struct tc_optional_base
> {
>   // default ctor leaves m_storage uninitialized
>   tc_optional_base() : m_initialized(false) {}
>   bool m_initialized;
>   T m_storage;
> };

This example seems unrelated to the issue, because you have here a struct, not
a union.

[Bug libstdc++/71899] An internal BooleanTestable trait should be provided

[daniel.kruegler at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899

--- Comment #6 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #5)
> LWG 2743 seems to be the wrong issue, I think https://wg21.link/lwg2114 is
> the right one.

Ah yes, this was an unintended mislinking on my side. Feel free to close this
issue, the resolution approach is now different already and it is likely the
libraries will already implement something like boolean-testable-impl anyway
(https://wg21.link/p1964r2).

[Bug c++/95686] undefined reference to static local variable within inline function

[daniel.kruegler at googlemail dot com]

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<>{};
}

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 libstdc++/95322] std::list | take | transform, expression does not work cbegin() == end()

[daniel.kruegler at googlemail dot com]

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 libstdc++/95322] std::list | take | transform, expression does not work cbegin() == end()

[daniel.kruegler at googlemail dot com]

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 c++/95368] gcc things that a lambda capture is both const and mutable

[daniel.kruegler at googlemail dot com]

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 c++/95242] [10/11 Regression] spurious "warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]" on comparisons with -std=c++2a

[daniel.kruegler at googlemail dot com]

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++/95242] [10/11 Regression] spurious "warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]" on comparisons with -std=c++2a

[daniel.kruegler at googlemail dot com]

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++/95307] Compiler accepts reinterpret_cast in constexpr

[daniel.kruegler at googlemail dot com]

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() - 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() - 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++/94923] False positive -Wclass-memaccess with trivially copyable std::optional

[daniel.kruegler at googlemail dot com]

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([0], , sizeof value);
  std::memcpy(, [0], sizeof value);
}

int main() {}
```

[Bug c++/94819] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't Pt. 2

[daniel.kruegler at googlemail dot com]

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++/94721] C++2a: Three-way comparison operator for function pointers rejected

[daniel.kruegler at googlemail dot com]

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++/94721] New: C++2a: Three-way comparison operator for function pointers rejected

[daniel.kruegler at googlemail dot com]

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 = 
  auto p2 = 
  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++/94025] Expected-to-fail compilation goes through by not detecting mutable-specifier on lambda

[daniel.kruegler at googlemail dot com]

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++/94644] Wrong is_nothrow_move_constructible result if used in a template first

[daniel.kruegler at googlemail dot com]

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++/94644] Wrong is_nothrow_move_constructible result if used in a template first

[daniel.kruegler at googlemail dot com]

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++/94550] False positive with -Wparentheses

[daniel.kruegler at googlemail dot com]

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 libstdc++/91630] std::any SFINAE breaks valid code since 9.1

[daniel.kruegler at googlemail dot com]

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++/94619] String literals as non-type template parameter fails to compile with partial specialization of calling function

[daniel.kruegler at googlemail dot com]

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 () [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++/94049] For better diagnostics CPOs should not use concepts for operator()

[daniel.kruegler at googlemail dot com]

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++/94554] spurious -Waddress warning within "if constexpr" function-null compares

[daniel.kruegler at googlemail dot com]

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 c++/94025] Expected-to-fail compilation goes through by not detecting mutable-specifier on lambda

[daniel.kruegler at googlemail dot com]

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 libstdc++/94565] New: C++20: Comparing comparison category types against 0/nullptr is not noexcept

[daniel.kruegler at googlemail dot com]

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++/94564] New: C++20: Three-way comparison between pointer and nullptr accepted

[daniel.kruegler at googlemail dot com]

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 c++/94563] Relational operations between pointer and nullptr accepted

[daniel.kruegler at googlemail dot com]

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++/94563] New: Relational operations between pointer and nullptr accepted

[daniel.kruegler at googlemail dot com]

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 libstdc++/94562] New: C++20: std::shared_ptr{} <=> nullptr ill-formed

[daniel.kruegler at googlemail dot com]

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/optional:1051:5: note:   template
argument deduction/substitution failed:
prog.cc:3:38: note:   mismatched types 'const std::option

[Bug c++/58074] [C++11][DR 1333] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58074

--- Comment #10 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Daniel Krügler from comment #0)
> > The deleted default constructor should not prevent type Trivial of being
> > trivial (Maybe this part of the problem is related to bug 52707, but I'm not
> > sure).
> 
> I think DR 1363 changed that (and DR 1496 reconfirmed it) so the first test
> is wrong. But G++ now passes that assertion, so that's also wrong (that is
> Bug 85723 though).

I agree in regard to DR 1496. The history behind that was that during the
Portland 2012 CWG drafting of that issue the following wording suggestion was
provided:

"A trivial class is a class that is trivially copyable and has either
a trivial default constructor or no default constructor (12.1 class.ctor)."

That wording had the effect that classes with either deleted or no default
constructor could be trivial and made these two cases consistent as pointed out
by DR 1496. That P/R was then later rejected and modified to the now accepted
wording at the Kona 2015 meeting, which also had the effect of making the two
cases consistent in a now a different way, by imposing the requirement that at
least one non-deleted default constructor exists. I don't think that DR 1363
changed the situation, because the meaning of the 1363 wording still didn't
exclude deleted constructors from being trivial.

[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754

--- Comment #6 from Daniel Krügler  ---
(In reply to Martin Sebor from comment #5)
> Would the solution described in bug 79078 comment 14 do what you're looking
> for?

Yes, that sounds plausible. But I'm just wondering: Don't you consider the
current attribute behaviour reasonable enough to make [[deprecated]] behave
equivalent? This would solve the problem more directly and is presumably easier
to understand from a user perspective.

[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754

--- Comment #4 from Daniel Krügler  ---
(In reply to Martin Sebor from comment #3)
> I find the [[deprecated]] behavior for the test cases here reasonable and
> useful: the struct type is declared deprecated and so its subsequent uses
> are diagnosed.

In general I would agree, but not here, because the second usage (old2) itself
is deprecated. This is a scenario that happens rather often: An older API get's
deprecated and part of that old API was Old2 and old2. You have provided a new
API (Not shown in the examples), but for a while you want to support the old,
deprecated API. What you want to realize is that the *user* of the old API
get's the warning. But now the plain declaration of the old API get's this
warning, too. THis is IMO annoying and the attribute behaviour seems preferable
to me.

> What I think is missing is a way for the author of a deprecated type (but
> not its users) to define objects of the type without triggering the warning,
> analogous to how it can be done for functions.  

Yes, that's what I was trying to argue about above.

I would expect the following
> to do it but it doesn't:
> 
> $ cat u.C && gcc -S -Wall -Wextra -Wpedantic u.C
> struct S { };
> 
> S a [[deprecated]];// expect no warning here
> 
> struct [[deprecated]] S;   // nor here
> 
> S b;   // expect -Wdeprecated-declarations here

I agree, but this is different from my example where b itself is also declared
deprecated.

> // Expected behavior:
> 
> int f () { return 0; }
> 
> [[deprecated]] int i = f  ();   // no warning
> 
> [[deprecated]] int f ();// no warning
> 
> int j = f ();   // -Wdeprecated-declarations
> u.C:5:23: warning: type attributes ignored after type is already defined
> [-Wattributes]
>  struct [[deprecated]] S;   // nor here
>^
> u.C:18:12: warning: ‘int f()’ is deprecated [-Wdeprecated-declarations]
>  int j = f ();   // -Wdeprecated-declarations
> ^
> u.C:12:5: note: declared here
>  int f () { return 0; }
>  ^
> Daniel, does this make sense to you?

These two latter examples make sense to me, but not the behaviour for my case.

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83981

--- Comment #11 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #10)
> Perhaps Daniel can comment, since he wrote the resolution of lwg 2033.
> 
> Daniel, if the intent was that vector::resize(size_type) must only move,
> even if that can throw, why is the exception-safety guarantee worded in
> terms of a non-CopyInsertable condition? Was the intention really to forbid
> implementations from giving the strong exception-safety guarantee (by
> copying) if possible?

I'm in the mid of something else, so forgive me if I'm still catching up. The
wording was slightly changed by LWG 2323 later on, does that clarify? [If not,
I can look deeper into it tomorrow evening, so please let me know] The basic
idea that the original wording tried to ensure is that strong exception-safety
holds for non-throwing move-only types or copyable types, because that was the
original intend suggested by Howard Hinnant.

[Bug c++/83956] [8 regression] error: use of deleted function ‘{anonymous}::a::~a()’

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83956

--- Comment #3 from Daniel Krügler  ---
(In reply to Daniel Krügler from comment #2)
> My understanding is that this is actually CWG 1353, discussed during the
> Bloomington 2011(!) meeting and still unresolved. This is item 17 in this
> document http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3307.pdf
> which had been created by the clang team at that time.

I need to correct myself: The above mentioned issue (albeit matching by title)
does not seem to match by content.

[Bug c++/83956] [8 regression] error: use of deleted function ‘{anonymous}::a::~a()’

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83956

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #2 from Daniel Krügler  ---
My understanding is that this is actually CWG 1353, discussed during the
Bloomington 2011(!) meeting and still unresolved. This is item 17 in this
document http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3307.pdf
which had been created by the clang team at that time.

[Bug libstdc++/83830] has_unique_object_representations_v is missing

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83830

--- Comment #1 from Daniel Krügler  ---
Looks like an oversight on my side when I implemented
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0607r0.html for gcc.

[Bug c++/79393] [7/8 Regression] cc1plus rejects valid code with noexcept

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79393

--- Comment #6 from Daniel Krügler  ---
(In reply to Jakub Jelinek from comment #5)
> Which DR has been filed for this and has there been any progress on it?

I understood the previous comments to refer to

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1658

[Bug c++/83160] [8 regression] lvalue required as unary ‘&’ operand

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83160

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The example looks invalid to me according to [expr.prim.lambda.capture] p7 b
(7.1), because the local variable bj is odr-used in the lambda expression

[](int bk) { a::ac(bk, bj); };

This is so, because the called function template

template  void ac(b, const b &);

attempts to bind its second argument by reference.

[Bug libstdc++/82891] stable_sort() won't compile with function object that takes parameters by non-const reference

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891

--- Comment #3 from Daniel Krügler  ---
(In reply to Daniel Krügler from comment #2)
> (In reply to Tony E Lewis from comment #1)
> > I should say that I've also raised the same issue against libc++ :
> > 
> > https://bugs.llvm.org/show_bug.cgi?id=35235
> 
> There is now an LWG issue submission request waiting to become published for
> this. I'll return when it has been added.

There exists now an official LWG issue for this:

http://cplusplus.github.io/LWG/lwg-active.html#3031

[Bug libstdc++/82891] stable_sort() won't compile with function object that takes parameters by non-const reference

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #2 from Daniel Krügler  ---
(In reply to Tony E Lewis from comment #1)
> I should say that I've also raised the same issue against libc++ :
> 
> https://bugs.llvm.org/show_bug.cgi?id=35235

There is now an LWG issue submission request waiting to become published for
this. I'll return when it has been added.

[Bug c++/82850] g++ permits redefinition of default arguments

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82850

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #4 from Daniel Krügler  ---
This looks like a dup of bug 50370 to me.

[Bug c++/82745] Fails to warn on narrowing conversion by std::forward (e.g. when calling make_unique)

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82745

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #3 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #2)
> Narrowing conversions only cause a diagnostic in braced-init-list, not in
> other contexts. This is how C++ has worked since day one.

I would even go so far and say: Since day zero ;-)

[Bug libstdc++/82749] piecewise_linear_distribution::densities() non conformity

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82749

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
I agree, that problem still exists in the current trunk as well. For the
record, the original specification was in terms of std::vector, that
was changed with LWG 1439:

http://cplusplus.github.io/LWG/lwg-defects.html#1439

Similar to the change request by that issue, class
piecewise_constant_distribution needs a similar correction.

[Bug c++/82247] [concepts] Name deduction in concepts fails depending on the argument type

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82247

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #2 from Daniel Krügler  ---
You need to provide the concrete compile conditions in the bug report. Using

the compiler flags

-Wall -Wextra -std=c++1z -pedantic "-fconcepts"

I couldn't verify the the result, see

https://wandbox.org/permlink/heubbLxMihDsJSBM

[Bug c++/82171] Cant use std::declval in concept testing map operator[]

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82171

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #2 from Daniel Krügler  ---
(In reply to Robert Douglas from comment #1)
> I came about this, transitioning from habits using SFINAE. I have just
> realized I can simplify it to:
> template
> concept bool MapLike = requires(T t) {
> {t[typename T::value_type::first_type{}]}
> -> typename T::value_type::second_type;
> };

IMO a better approach imposing less unnecessary constraints (such as
list-initialization) would be something along the lines of:

template
concept bool MapLike = requires(T t, typename T::value_type::first_type ft) {
{t[ft]} -> typename T::value_type::second_type;
};

> and bypass the declval, altogether. Question, though, does anything forbid
> declval in this context?

Technically the error results because the definition (and not only the
declaration) of std::declval() had been
instantiated here, because it seems to be considered as odr-used.

But according to [expr.prim.req] p2: 

"Expressions appearing within a requirement-body are unevaluated operands
(Clause 8)."

and following [expr] p8:

"In some contexts, unevaluated operands appear (8.1.7, 8.2.8, 8.3.3, 8.3.7,
10.1.7.2, Clause 17). An unevaluated operand is not evaluated. [Note: In an
unevaluated operand, a non-static class member may be named (8.1) and naming of
objects or functions does not, by itself, require that a definition be provided
(6.2). An unevaluated operand is considered a full-expression (4.6). — end
note]"

As I understand it, this wording should allow using std::declval within the
requirement-body as you did it without causing it being considered odr-used, so
the current behaviour looks like a bug to me.

[Bug c++/81852] Feature request: __cpp_threadsafe_static_init

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81852

--- Comment #3 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #2)
> trunk/gcc/testsuite/g++.dg/cpp1y/feat-neg.C

Thanks for your work on that Jonathan! Just out of curiosity: All tests within
feat-neg.C seem counter-intuitive to me, because it seems that the idea of that
test is that everything within is supposed to fail on success - is that
intended?

[Bug c++/81992] C++ toupper symbol clash?

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81992

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
This is a programming error on your side: The compiler sees two functions
tolower in the global namespace and both could be used equally good for
deduction purposes in the call:

std::transform(str.begin(), str.end(), str.begin(), ::tolower);

Since both could be used to deduce the template parameter UnaryOperation, this
deduction fails and the std::transform template with four function parameters
is excluded from overload resolution. The remaining one has five parameters and
fails as well. You can help the compiler by introducing a lambda expression:

std::transform(str.begin(), str.end(), str.begin(), [](auto c){ return
::tolower(c); });

Now the compiler can perform overload resolution on the call expression
::tolower(c) and can determine a single best candidate.

[Bug c++/81928] if(!this) optimization leads to possible errors without warnings

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928

--- Comment #7 from Daniel Krügler  ---
(In reply to Matthieu Brucher from comment #6)
> I never said that the test alone should be banned. Please read the original
> message first.

I had done so before I replied. And it seems that I'm not the only one who has
problems understanding your request.

> I said that if(!this) in the context of a method gives "unexpected" behavior
> (according to the standard and the difference in behavior of GCC between
> debug and optimized mode) and thus should give an error or at least a
> warning, and this is easy to catch.

I don't understand this. Please provide an example.

> At least make it a warning, like clang does when it detects that a path is
> always true or false, some kind of way for the user to _know_ that they
> messed up. 

I already suggested the same thing: The only reason to request a warning in
this case is because the test result has only one outcome. But this is
absolutely unrelated to undefined behaviour unless you clarify what precisely
your mean.

> And yes, there is something fundamentally wrong with comparing this to
> nullptr according to the C++ standard and the contract GCC has in its
> optimizer. 

You claim this repeatedly but I'm missing a proof for the "fundamentally wrong"
part. Except if you consider tautologies as "fundamentally wrong".

> Or give a reason why it is valid and where the standard says it
> supercedes the undefined behavior and the thread discussion on why GCC added
> the optimization constraint.
> And in that case, you should probably remove the optimization as well to be
> consistent.

This part is unclear without a specific example that you are talking about, see
above.

[Bug c++/81947] variadic template specialization doesn't compile

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81947

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
gcc 4.4.7 has no complete C++11 support. AFAIK the first gcc version targetting
C++11 is the 4.7 series and when testing against 4.7.3 (The oldest 4.7 version
available to me), compiles the code successfully. I don't think that any
further C++11 support is planned for 4.4.7, I recommend to switch to a newer
gcc version or to give up attempting to use C++11 code with a compiler that is
not designed to support C++11.

[Bug c++/81928] if(!this) optimization leads to possible errors without warnings

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #5 from Daniel Krügler  ---
(In reply to Matthieu Brucher from comment #4)
> I would agree if the debug and optimized versions had the same behavior.
> They do not. As such there should be a huge warning about the undefined
> behavior. 

The test alone is not undefined behaviour. This is like requesting that the
following code has undefined behaviour:

int main() 
{
  int i = 12;
  int* that = 
  if (!that) {}
}

> And no, it's not valid code, it's an undefined behavior, you can do whatever
> you want with it. Outputting an error is a better solution, even adding a
> warning is.  Silently optimizing an undefined behavior away is not.

This argumentation is wrong. There is nothing fundamentally wrong to compare
'this' against null. The only reason to request a warning is because this test
cannot evaluate to true in conforming programs.

[Bug libstdc++/81950] _GLIBCXX17_INLINE macro not used consistently

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81950

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #3 from Daniel Krügler  ---
(In reply to Judy Ward from comment #1)
> In the comment above I meant to say the line should be changed to:
> 
> _GLIBCXX17_INLINE constexpr in_place_t in_place{};

TC's guess is correct. The omission is intentionally, because the macro is
designed to be used in contexts which are unaware of the actual C++ version and
in_place_t was introduced with C++17, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0504r0.html and some
papers related to std::optional in-place construction. The surrounding #ifdef
block of the variable definition you are complaining about is only available
since C++17.

[Bug c++/81852] New: Feature request: __cpp_threadsafe_static_init

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81852

Bug ID: 81852
   Summary: Feature request: __cpp_threadsafe_static_init
   Product: gcc
   Version: 8.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: ---

Since the recent update of "Feature-testing recommendations for C++",

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0096r4.html#recs.cpp11

the feature macro "__cpp_threadsafe_static_init" has been recommended for C++
language level c++11 on. This is extremely useful to have for code that has to
program defensively against the possibility that thread-safe static locale
initialization has been deactivated (via -fno-threadsafe-statics). With that
feature macro available, portable code can be written that always provides a
thread-safe static initialization, for example by means of std::call_once as
the following excerpt demonstrates:

Thingy& get_thing()
{
#ifndef __cpp_threadsafe_static_init
[...]
static std::once_flag flag;
std::call_once(flag, init::get);
return init::get();
#else
static Thingy result;
return result;
#endif
}

Current clang HEAD 6.0.0 (https://github.com/llvm-mirror/clang.git 43) has
already provided support for this.

A test-case would be that given the compiler flags

$ g++ prog.cc -Wall -Wextra -std=c++11 -pedantic 

the following would be well-formed:

//<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
#ifndef __cpp_threadsafe_static_init
# error "__cpp_threadsafe_static_init not defined"
#endif

int main() 
{
}
//<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

while given the compiler flags

$ g++ prog.cc -Wall -Wextra -std=c++11 -pedantic "-fno-threadsafe-statics"

the same code should be ill-formed:

prog.cc:2:3: error: #error "__cpp_threadsafe_static_init not defined"
 # error "__cpp_threadsafe_static_init not defined"
   ^

[Bug c++/81632] spurious -Wterminate warning about throw in destructor

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81632

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
You are wrong. The warning is correct, because the code only catches the first
exception and then rethrows it within the int handler again. The rethrown
exception is not caught, you would need a separate try/catch for this.

[Bug libstdc++/79162] [7/8 Regression] [C++17] ambiguity in string assignment due to string_view overload

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162

--- Comment #16 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #15)
> Thanks, Daniel. Let's reopen this to make the T -> const T& changes.

I'm now working at that problem, thereby also attempting to implement the full
P/R of LWG 2946.

[Bug libstdc++/81468] is_constructible gives the wrong answer for time_point construction

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81468

--- Comment #2 from Daniel Krügler  ---
Shouldn't add a DR-1177 tag? (I forgot the exact construction pattern for this)
This may also help to validate that all other wording changes by this issue had
been implemented.

[Bug libstdc++/81468] is_constructible gives the wrong answer for time_point construction

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81468

--- Comment #1 from Daniel Krügler  ---
It seems that the implementation simply forgot to constrain overload
resolution, since this is the complete definition of the affected constructor:

template
  constexpr time_point(const time_point& __t)
  : __d(__t.time_since_epoch())
  { }

The constraints were added by LWG 1177,

http://cplusplus.github.io/LWG/lwg-defects.html#1177

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162

--- Comment #14 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to Jonathan Wakely from comment #8)
> > Richard also says the overload shouldn't exist and is a bug, but the
> > overload has to exist, because the C++17 draft is defective.
> 
> That's https://wg21.link/lwg2946

The problem here is that the current gcc implementation differs from the LWG
2949 wording. The wording suggests to use

template
basic_string& operator=(const T& t);

but the existing gcc approach uses effectively a by-value signature:

template
basic_string& operator=(T t);

In the example code, the model type llvm::cl::opt is not copy-constructible,
but the constraints accept it, because it is (a) convertible to
std::string_view (Because it inherits from std::string) and (b) it is not
convertible to char*. Now after acceptance of the constraints, the template
signature is instantiated, because it is a (slightly) better match than the
copy_assignment operator of std::string. When this has happened, the compile
error arises, because it is attempted to call the deleted (and private) copy
constructor of llvm::cl::opt.

It seems to me that it would suffice to change the signature of the constrained
assignment operator to use const T& instead of T, as suggested by the issue
resolution proposal.

Here is a reproducer for the situation:

#include 

template 
class opt : public DataType
{
  opt(const opt &) = delete;
  opt =(const opt &) = delete;
public:
  opt() {}
};

int main() 
{
  opt PGOTestProfileFile;
  std::string ProfileFileName;
  ProfileFileName = PGOTestProfileFile;
}

Here is a minimized emulation of basic_string that shows that the suggested fix
should work (Please uncomment '#define USE_FIX' below):

#include 
#include 
#include 
#include 

namespace xstd {

  template>
  struct basic_string_view
  {
 using traits_type = Traits;
 using size_type = std::size_t;

 constexpr basic_string_view() noexcept
  : len{0}, str{nullptr}
  {}

 constexpr basic_string_view(const CharT* str) 
   : len{str == nullptr ? 0 : traits_type::length(str)},
 str{str}
  {}

  constexpr size_type
  size() const noexcept
  { return this->len; }

  constexpr const CharT*
  data() const noexcept
  { return this->str; }

  private:
 size_type len;
 const CharT* str;
  };

  template>
  struct basic_string
  {
  private:
  using sv_type = basic_string_view;

  template
  using If_sv = std::enable_if_t<
 std::__and_<
   std::is_convertible,
   std::__not_
 >::value,
 Res>;

  public:

  using size_type = std::size_t;

  static const size_type npos = static_cast(-1);

  basic_string&
  operator=(const basic_string& str);

  basic_string&
  operator=(const CharT* s);

  basic_string&
  operator=(CharT c);

  basic_string&
  operator=(std::initializer_list);

  basic_string&
  operator=(basic_string&& str);

//#define USE_FIX  

#ifndef USE_FIX
  template
  If_sv
  operator=(T sv);
#else
  template
  If_sv
  operator=(const T& sv);
#endif

 operator sv_type() const noexcept;

};

using string = basic_string;

}

namespace llvm {
namespace cl {

template 
class opt_storage : public DataType
{
};

template 
class opt : public opt_storage 
{
  opt(const opt &) = delete;
  opt =(const opt &) = delete;
public:
  opt();
};

}
}

using namespace llvm;
cl::opt
PGOTestProfileFile;

namespace {
class PGOInstrumentationUseLegacyPass {
  PGOInstrumentationUseLegacyPass(xstd::string)
  {
  ProfileFileName = PGOTestProfileFile;
  }
  xstd::string ProfileFileName;
};
}

int main() 
{
}

[Bug c++/81349] Classes with deleted constructor templates incorrectly labeled as non-aggregates

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81349

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The suggested code contains several typos, here a corrected version:

#include 

struct S {
template 
S(T) = delete;
};

int main() {
static_assert(std::is_aggregate_v);
}

[Bug c++/81250] C++ warnings about unused stl

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81250

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The technical reason for that is that according to the language neither all
constructors nor the destructor of std::string are trivial special members. I
think the request as indicated by the title ("unused STL") should be withdrawn,
since there are obvious type (combinations) of the Standard Library that really
should be considered as used just if they are constructed or destructed, such
as std::tuple when SideEffects is a user-defined type whose
construction or destruction has side effects. Another example where a seemingly
"unused" object could exist for some purpose are smart pointers like
shared_ptr, weak_ptr, or unique_ptr, which might be constructed simplify to
define a scope where a contained object exists. Another candidate of an
"unused" object where you really don't want be nagged about is any of the lock
templates, and there are presumably a lot others. When considering to enable
such a warning for selected types, the hard question is: Where do we stop? Is
that a request that will never end? Today std::string, tomorrow ??

[Bug c++/81045] [7 Regression] return type deduction causes dependent types?

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81045

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)
> Somehow GCC is deciding that easyObjects->begin() and end() are dependent
> types so you need to use the template keyword for the call to cast.
> 
> That is:
> auto casted = obj.template cast();
> 
> I don't know if GCC is correct here or not.

It looks like a GCC bug to me, because easyObjects is a non-dependent
expression and the specification of the range-for loop doesn't result in a
dependent expression of obj given the participating begin()/end() members.

It should be noted that the demo code is broken, because it incorrectly
attempts to bind an rvalue (The result of vector<>::get) to an lvalue
reference, but that is another story.

[Bug c++/80841] Fails to match template specialization with polymorphic non-type template argument

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80841

--- Comment #3 from Daniel Krügler  ---
(In reply to Jason Bell from comment #2)
> Thanks that's a good reduced example.  I've changed it slightly so it works
> with constexpr input.

But that is just adding additional complexity: The constexpr declaration is
unnecessary when you provide an argument of reference type to a non-type
template of reference type.

[Bug c++/80841] Fails to match template specialization with polymorphic non-type template argument

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80841

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
(In reply to Jason Bell from comment #0)

An interesting case. Reduced example:

//#
template 
struct A {};

template 
struct B {};

template 
struct B> 
{
  using result = T;
};

static double input;

int main() {
  using result1 = typename B>::result; // OK
  using result2 = typename B>::result; // OK
  using result3 = typename B>::result; // Error
}
//#

results in:

prog.cc: In function 'int main()':
prog.cc:18:59: error: 'result' in 'struct B >' does
not name a type
   using result3 = typename B>::result;
   ^~
Clang behaves exactly the same and from the compiler behaviour it looks like a
non-deducible situation, but I fail to match this with current non-deduced
context rules at the moment.

[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80654

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
Here are two problems involved:

1) std::vector's copy constructor is not SFINAE-friendly and causes
std::is_copy_constructible to evaluate to true regradless of it's element type.
This is a QoI issue but not a violation of the requirements of the standard.

2) The more serious problem is that the intrinsic __is_trivially_constructible
is the actual cause of the non-silent response here. This can be demonstrated
by evaluating the statement

__is_trivially_constructible(std::vector, const std::vector&);

which results in the following compiler error:

//
H:\Develop\Cpp\C++0x\ScratchBook\main.cpp||In function 'int main()':|
H:\Develop\Cpp\C++0x\ScratchBook\main.cpp|28|warning: statement has no effect
[-Wunused-value]|
c:\program files\develop\gcc\include\c++\8.0.0\bits\stl_construct.h||In
instantiation of 'void std::_Construct(_T1*, _Args&& ...) [with _T1 = nocopy;
_Args = {const nocopy&}]':|
c:\program
files\develop\gcc\include\c++\8.0.0\bits\stl_uninitialized.h|83|required from
'static _ForwardIterator
std::__uninitialized_copy<_TrivialValueTypes>::__uninit_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator =
__gnu_cxx::__normal_iterator >;
_ForwardIterator = nocopy*; bool _TrivialValueTypes = false]'|
c:\program
files\develop\gcc\include\c++\8.0.0\bits\stl_uninitialized.h|134|required from
'_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = __gnu_cxx::__normal_iterator >; _ForwardIterator = nocopy*]'|
c:\program
files\develop\gcc\include\c++\8.0.0\bits\stl_uninitialized.h|289|required from
'_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator,
_ForwardIterator, std::allocator<_Tp>&) [with _InputIterator =
__gnu_cxx::__normal_iterator >;
_ForwardIterator = nocopy*; _Tp = nocopy]'|
c:\program files\develop\gcc\include\c++\8.0.0\bits\stl_vector.h|331|required
from 'std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with
_Tp = nocopy; _Alloc = std::allocator]'|
H:\Develop\Cpp\C++0x\ScratchBook\main.cpp|28|required from here|
c:\program files\develop\gcc\include\c++\8.0.0\bits\stl_construct.h|75|error:
use of deleted function 'nocopy::nocopy(const nocopy&)'|
H:\Develop\Cpp\C++0x\ScratchBook\main.cpp|18|note: declared here|
||=== Build failed: 1 error(s), 7 warning(s) (0 minute(s), 0 second(s)) ===|
//

Note that evaluating

std::is_copy_constructible

alone doesn't spit at the programmer, but happily instantiates.

The only clean choice is to fix the __is_trivially_constructible intrinsic.
Wrapping the current call of that intrinsic by expanding the current
std::is_trivially_copy_constructible definition as follows

  template
  struct __is_trivially_constructible_delayed
  : public integral_constant
  { };

  template
  struct is_trivially_copy_constructible
  : public __and_,
__is_trivially_constructible_delayed<_Tp>>
  { };

wouldn't solve the problem, because due to the wrong positive result of
std::is_copy_constructible the protected
__is_trivially_constructible_delayed would still be instantiated.

[Bug c++/79078] Warnings from deprecated attribute are too noisy

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79078

--- Comment #11 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to Daniel Krügler from comment #9)
> > PR 61754 seems to be related.
> 
> I think for the examples here it makes no difference if you use
> __attribute__((deprecated(""))) or [[deprecated("")]]

Oops, you are right, I was mislead!

[Bug c++/79078] Warnings from deprecated attribute are too noisy

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79078

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #9 from Daniel Krügler  ---
PR 61754 seems to be related.

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390

--- Comment #10 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Daniel Krügler from comment #6)
> > Do you recommend to reopen 51222 or should I open a separate bug? I'm
> > inclined to create a new one at the moment.
> 
> Agreed, let's have a new bug for that.

I have just created DR 80475.

[Bug c++/80475] New: Unevaluated combined delete new expression doesn't handle access error in class template SFINAE

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80475

Bug ID: 80475
   Summary: Unevaluated combined delete new expression doesn't
handle access error in class template SFINAE
   Product: gcc
   Version: 7.0.1
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, compiled with gcc 7.0.1 20170419 (experimental) using the
flags

-Wall -Wextra -std=c++11 -pedantic

or - alternatively -

-Wall -Wextra -std=c++1z -pedantic

//---
struct true_type 
{
  static const bool value = true;
};

struct false_type 
{
  static const bool value = false;
};

template
T&& declval();

template
struct is_direct_constructible_impl : false_type
{ };

template
struct is_direct_constructible_impl<T, Arg,
  decltype(::delete ::new T(declval()))>
: true_type
{ };

struct S
{
  S(int);
};

struct DCS
{
  DCS(int) = delete;
};

struct PCS
{
private:
  PCS(int);
};

struct DDS 
{
  DDS(int);
  ~DDS() = delete;
};

struct PDS 
{
  PDS(int);
private:
  ~PDS() = default;
};

int main() 
{
  static_assert(is_direct_constructible_impl<S, int>::value, "Ouch");
  static_assert(!is_direct_constructible_impl<DCS, int>::value, "Ouch");
  static_assert(!is_direct_constructible_impl<PCS, int>::value, "Ouch");
  static_assert(!is_direct_constructible_impl<DDS, int>::value, "Ouch");
  static_assert(!is_direct_constructible_impl<PDS, int>::value, "Ouch");
}
//---

is rejected with the following diagnostics:


prog.cc: In instantiation of 'struct is_direct_constructible_impl<PCS, int>':
prog.cc:57:56:   required from here
prog.cc:20:25: error: 'PCS::PCS(int)' is private within this context
   decltype(::delete ::new T(declval()))>
 ^~~
prog.cc:37:3: note: declared private here
   PCS(int);
   ^~~
prog.cc:20:25: error: 'PCS::PCS(int)' is private within this context
   decltype(::delete ::new T(declval()))>
 ^~~
prog.cc:37:3: note: declared private here
   PCS(int);
   ^~~
prog.cc: In function 'int main()':
prog.cc:57:3: error: static assertion failed: Ouch
   static_assert(!is_direct_constructible_impl<PCS, int>::value, "Ouch");
   ^
prog.cc:57:18: error: 'PCS::PCS(int)' is private within this context
   static_assert(!is_direct_constructible_impl<PCS, int>::value, "Ouch");
  ^~
prog.cc:37:3: note: declared private here
   PCS(int);
   ^~~
prog.cc: In instantiation of 'struct is_direct_constructible_impl<PDS, int>':
prog.cc:59:56:   required from here
prog.cc:22:1: error: 'PDS::~PDS()' is private within this context
 { };
 ^
prog.cc:50:3: note: declared private here
   ~PDS() = default;
   ^
prog.cc:22:1: error: 'PDS::~PDS()' is private within this context
 { };
 ^
prog.cc:50:3: note: declared private here
   ~PDS() = default;
   ^
prog.cc:59:3: error: static assertion failed: Ouch
   static_assert(!is_direct_constructible_impl<PDS, int>::value, "Ouch");
   ^
prog.cc:59:18: error: 'PDS::~PDS()' is private within this context
   static_assert(!is_direct_constructible_impl<PDS, int>::value, "Ouch");
  ^~
prog.cc:50:3: note: declared private here
   ~PDS() = default;
   ^


This code example is somewhat different from PR 51222 because it uses "class
template SFINAE" and is maybe related to PR 61806. 

This example occurred while discussing a possible alternative implementation of
is_constructible, see PR 80390.

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390

--- Comment #9 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #8)
> Maybe we should just ask Jason to suppress the notes in a SFINAE context.

Yes, that sounds like a preferred direction to me.

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390

--- Comment #6 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #2)
> Created attachment 41235 [details]
> avoid over-aligned new in is_constructible
> 
> [..]. We can also combine it
> with the delete check, because PR 51222 is fixed.

It seems that PR 51222 didn't cover private destructors. Using this test class

struct PS 
{
  PS(int);
private:
  ~PS() = default;
};

The attempt to evaluate the revised __is_direct_constructible_impl
produces a compiler error (so not SFINAE-friendly), but the current
implementation (using std::is_destructible) works nicely. 

Do you recommend to reopen 51222 or should I open a separate bug? I'm inclined
to create a new one at the moment.

Another question I have is the following: What is you main motivation to
introduce the idiom

struct __uneval_new_t;
inline void* operator new(std::size_t, std::__uneval_new_t*);
decltype(::delete ::new((__uneval_new_t*)0) _Tp(std::declval<_Arg>()))

compared to the seemingly simpler alternative

decltype(::delete ::new _Tp(std::declval<_Arg>()))

?

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390

--- Comment #4 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #3)
> Daniel, please see above.

Sorry for the late response. I would like to shortly double-check, can you
await a definitive response until tomorrow?

[Bug libstdc++/78156] constexpr basic_string_view::basic_string_view(const charT *) calls non-constexpr char_traits::length

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78156

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
Strictly speaking, the provided example doesn't reveal a defect in the existing
implementation.

Changing char_traits::length to be constexpr would be non-conforming (at least
an extension), albeit one could argue that an implementation *could* decide to
implement std::string_view::string_view(const char*) [but only this specific
constructor] in a way where a built-in would be used (very similar as you
describe), whose semantics would be equivalent to calling
std::char_traits::length, since the existing wording does only impose
post-conditions and requirements imposed on user-input, it doesn't require
specifically the usage of std::char_traits::length (given the specific
type char). For user-defined traits and character types there would be no
alternative, though. But all this is just QoI and no requirement. 

As a user you could provide your own hand-rolled fully constexpr character
trait class and instantiate basic_string_view with that one or you could write
a constexpr helper function that uses a constexpr length function and returns a
std::string_view object by internally calling the
std::string_view::string_view(const char*, size_type) constructor instead.

Note that there exists an open library evolution issue related to that:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2232

[Bug c++/77474] sizeof and function template don't work properly together

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77474

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The same problem occurs for the current gcc HEAD 7.0.0 20160901 (experimental).

[Bug libstdc++/77395] [6/7 Regression] std::is_constructible is false for type constructible via implicit conversion operator affecting std::tuple

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77395

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
I think a better test-case is the following one, which does not depend on tuple
at all:

//#
#include 

struct derived;
struct base
{
  operator derived & () &;
  operator derived const & () const &;
  operator derived && () &&;
};

struct derived : base {};

static_assert(std::is_constructible::value, "");

int main()
{
}
//#

[Bug c++/72868] Constexpr expressions mistreat case ranges

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72868

--- Comment #3 from Daniel Krügler  ---
The quoted essentials also require you to provide the full command line (A
range in a switch case is not Standard C++), please read about what's needed in
the quoted document.

[Bug c++/72868] Constexpr expressions mistreat case ranges

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72868

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
This is an incomplete bug report, please read https://gcc.gnu.org/bugs/#need
and provide a test case

[Bug c++/72865] Adding __may_alias__ attribute triggers a compilation error

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72865

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #3 from Daniel Krügler  ---
The code is also accepted by the current gcc HEAD 7.0.0 20160807
(experimental).

[Bug c++/72842] non-type template-parameter of type void

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72842

--- Comment #7 from Daniel Krügler  ---
(In reply to Daniel Krügler from comment #5)
> (In reply to Barry Revzin from comment #4)
> > I'll just email. Instantiating foo creates a function template with a
> > non-type template parameter of type void. That's not an allowed type of a
> > non-type template parameter, so I think it should be ill-formed.
> 
> It truely is ill-formed, but the question is whether an implementation is
> required to diagnose it. For the non-depending case the diagnostics is a
> hard requirement. But for the dependent case we have [temp.res] p8:
> 
> "The program is ill-formed, no diagnostic required, if:
> [..]
> — every valid specialization of a variadic template requires an empty
> template parameter pack, or [..]"
> 
> My argument is that this is the case we are entering here: Ill-formed, but
> no diagnostics required.

After a second look at your original foo template I need to correct myself a
bit, so let me be more precise:

1) Your second bar() example is ill-formed, no diagnostics required, as
explained above. But it is nonetheless diagnosed here (because the case is
simple).

2) Your original foo example is simply valid, because the pack is empty and so
there is no non-type template parameter of type void, as I described in my very
first response. For this example my [temp.res] quote doesn't hold, because one
can produce several other valid specializations of that template without an
empty parameter pack (e.g. when selecting T=int). Of-course it would still not
be valid to attempt to generate a non-empty pack expansion of the second
parameter using void or other types that are not valid as non-type parameters.

[Bug c++/72842] non-type template-parameter of type void

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72842

--- Comment #6 from Daniel Krügler  ---
(In reply to Daniel Krügler from comment #5)
> (In reply to Barry Revzin from comment #4)
> > I'll just email. Instantiating foo creates a function template with a
> > non-type template parameter of type void. That's not an allowed type of a
> > non-type template parameter, so I think it should be ill-formed.
> 
> It truely is ill-formed, but the question is whether an implementation is
> required to diagnose it. For the non-depending case the diagnostics is a
> hard requirement. But for the dependent case we have [temp.res] p8:
> 
> "The program is ill-formed, no diagnostic required, if:
> [..]
> — every valid specialization of a variadic template requires an empty
> template parameter pack, or [..]"
> 
> My argument is that this is the case we are entering here: Ill-formed, but
> no diagnostics required.

Having said that, it might be worth to point out that there are at least two
core issues involving this area:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1785
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2067

[Bug c++/72842] non-type template-parameter of type void

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72842

--- Comment #5 from Daniel Krügler  ---
(In reply to Barry Revzin from comment #4)
> I'll just email. Instantiating foo creates a function template with a
> non-type template parameter of type void. That's not an allowed type of a
> non-type template parameter, so I think it should be ill-formed.

It truely is ill-formed, but the question is whether an implementation is
required to diagnose it. For the non-depending case the diagnostics is a hard
requirement. But for the dependent case we have [temp.res] p8:

"The program is ill-formed, no diagnostic required, if:
[..]
— every valid specialization of a variadic template requires an empty template
parameter pack, or [..]"

My argument is that this is the case we are entering here: Ill-formed, but no
diagnostics required.

[Bug c++/72842] non-type template-parameter of type void

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72842

--- Comment #3 from Daniel Krügler  ---
Since this is not a newsgroup, let me ask differently: Can you please elaborate
what you consider as a concrete compiler defect, violating the existing
standard? I fail to see the point.

[Bug c++/72842] non-type template-parameter of type void

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72842

--- Comment #1 from Daniel Krügler  ---
I don't see anything wrong with that code, since the parameter pack is empty,
so there is never any attempt to declare void as non-type template parameter
type. The standard has this restriction only for a non-type parameter type, but
there is none in your example.

[Bug libstdc++/71899] An internal BooleanTestable trait should be provided

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899

--- Comment #4 from Daniel Krügler  ---
(In reply to Ville Voutilainen from comment #2)
[..]
> I'm also not a fan of the name boolean_testable

Note that no-one yet has made an improved name suggestion for this thingee that
is discussed in LWG 2743. Unless this happens, I think that the corresponding
trait should match this name and should match the intention of what is tested
here.

> - perhaps boolean_like would
> be better? The rationale being that there are "boolean testable" types
> that work in cases where a contextual conversion to bool is performed,
> but those types are otherwise not "boolean-like". 

If you believe so, please make a corresponding comment to LWG 2743 and convince
people for accepting this revised name.

[Bug libstdc++/71899] An internal BooleanTestable trait should be provided

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899

--- Comment #3 from Daniel Krügler  ---
(In reply to Ville Voutilainen from comment #2)
> I dislike the #ifdef parts.

I'm sorry for my misleading proposal. My extended proposal is not suggesting to
add this macro. I was using this macro solely for experimentation purposes. My
intended question was solely whether we would prefer to have the more reduced
set of requirements as defined in my original proposal or the more complete
requirement set that would result if you consider the macro
EXT_BOOLEAN_TESTABLE_OPS defined (but without the #ifdef logic of that macro).
This more complete set corresponds more strictly to the current BooleanTestable
requirement set.

[Bug libstdc++/71899] An internal BooleanTestable trait should be provided

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899

--- Comment #1 from Daniel Krügler  ---
I have now a working implementation available, my minimum requirement set is
summarized by the following trait definition:

//
  // Utility to detect BooleanTestable types (NB: LWG 2114).

  template::value>
struct __is_boolean_testable_impl;

  template
struct __is_boolean_testable_impl<_Tp, false>
: public false_type { };

  template
struct __is_boolean_testable_impl<_Tp, true>
: public __and_>
{ };

  template
struct __is_boolean_testable
: public __is_boolean_testable_impl<_Tp> { };
//

During my work on this I wanted to stretch its limits and extended the
definition to cover basically all statically testable expressions as currently
specified by the BooleanTestable requirements [booleantestable] in LWG 2743 as
follows:

//
  // Utility to detect BooleanTestable types (NB: LWG 2114).

  template::value>
struct __is_boolean_testable_impl;

  template
struct __is_boolean_testable_impl<_Tp, false>
: public false_type { };

#ifdef EXT_BOOLEAN_TESTABLE_OPS
  struct __do_is_boolean_testable_ext_impl
  {
struct __bt
{
  operator bool() const;
};

template()), 
 typename _Rt1
 = decltype(declval<_Tp>() && declval()), 
 typename _Rt2
 = decltype(declval<_Tp>() || declval()), 
 typename _Rt3
 = decltype(declval() && declval<_Tp>()), 
 typename _Rt4
 = decltype(declval() || declval<_Tp>()), 
 typename _Rt5
 = decltype(declval<_Tp>() && declval<_Tp>()), 
 typename _Rt6
 = decltype(declval<_Tp>() || declval<_Tp>()),
 typename = typename enable_if<__and_<
   is_same<_Rt0, bool>,
   is_same<_Rt1, bool>, is_same<_Rt2, bool>,
   is_same<_Rt3, bool>, is_same<_Rt4, bool>,
   is_same<_Rt5, bool>, is_same<_Rt6, bool>
 >::value>::type>
  static true_type __test(int);

template
  static false_type __test(...);
  };

  template
struct __is_boolean_testable_ext
: public __do_is_boolean_testable_ext_impl
{
  typedef decltype(__test<_Tp>(0)) type;
};

  template
struct __is_boolean_testable_ext_safe
: public __is_boolean_testable_ext<_Tp>::type
{ };
#endif

  template
struct __is_boolean_testable_impl<_Tp, true>
: public __and_
#ifdef EXT_BOOLEAN_TESTABLE_OPS
,
__is_boolean_testable_ext_safe
#endif
   >
{ };

  template
struct __is_boolean_testable
: public __is_boolean_testable_impl<_Tp> { };
//

Please note that the extended test added the slightly stricter requirement
is_same<_Rt0, bool> instead of __is_boolean_testable<_Rt0>, because the latter
would have lead to an indefinite recursion. But even this much stricter (and
more complex) __is_boolean_testable definition (i.e. with
EXT_BOOLEAN_TESTABLE_OPS being defined as shown above) resulted in an accepted
test case: 

//-
#include 
#include 
#include 

struct BooleanLike
{
  operator bool() const;
};

struct NotBooleanLike1
{
  explicit operator bool() const;
};

struct NotBooleanLike2
{
  using Bool = int;
  explicit operator bool() const = delete;
  operator Bool() const;
};

struct NotBooleanLike3
{
  operator bool();
};

void test01()
{
  using std::__is_boolean_testable;
  // Positive tests.
  static_assert(__is_boolean_testable::value, "");
  static_assert(__is_boolean_testable::value, "");
  static_assert(__is_boolean_testable::value, "");
  static_assert(__is_boolean_testable::value, "");
  static_assert(__is_boolean_testable::value, "");
  static_assert(__is_boolean_testable::value, "");
  static_assert(__is_boolean_testable::reference>::value, "");
  static_assert(__is_boolean_testable::reference>::value, "");
  static_assert(__is_boolean_testable::value,
"");

  // Negative tests.
  static_assert(!__is_boolean_testable::value, "");
  static_assert(!__is_boolean_testable::value, "");
  static_assert(!__is_boolean_testable::value, "");
  static_assert(!__is_boolean_testable::value, "");
}
//-

I would therefore like to ask which form of the trait would be considered more
welcome as internal utility for libstdc++?

[Bug libstdc++/71899] New: An internal BooleanTestable trait should be provided

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899

Bug ID: 71899
   Summary: An internal BooleanTestable trait should be provided
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.kruegler at googlemail dot com
  Target Milestone: ---

I suggest to provide an internal type trait that corresponds to the currently
discussed BooleanTestable requirement set as described in LWG 2743:

http://cplusplus.github.io/LWG/lwg-active.html#2743

This trait could be used in SFINAE-constraints such as for the recently added
comparison functions of std::optional or as argument of static_assert for the
existing comparison functions of std::tuple and possibly other places as well.

In the absence of any better name, I suggest to introduce a type trait named
__is_boolean_testable in header .

Given that LWG 2743 is not resolved yet, I recommend to start with a very weak
set of requirements for some type T, e.g. the logical AND of

std::is_convertible::value
std::is_constructible<bool, const T&>::value

I'm willing to provide this contribution.

[Bug c++/71896] Constexpr function with pointer to member parameter doesn't return constexpr value

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71896

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
That looks like a regression to me: It worked from gcc 4.6.4 on until gcc 5.3.0
and does no longer work in gcc 6.1.0 or in gcc HEAD 7.0.0.

[Bug c++/71886] Incorrect error on operator() being an member in template

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71886

--- Comment #3 from Daniel Krügler  ---
(In reply to Ville Voutilainen from comment #2)
> Clang also rejects the template.

And Visual Studio 2015 rejects the template also.

[Bug c++/71841] variadic template can't cast to base class

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71841

--- Comment #5 from Daniel Krügler  ---
(In reply to Daniel Krügler from comment #4)
> I cannot confirm this:
> 
> http://melpon.org/wandbox/permlink/Y6tlw5LQ71o1o6ei

Sorry, this should be:

http://melpon.org/wandbox/permlink/3L5qgWb4x0gJw6FV

> But it doesn't really matter much, because I already provided two arguments
> why the program that you have provided is non-conforming.

[Bug c++/71841] variadic template can't cast to base class

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71841

--- Comment #4 from Daniel Krügler  ---
(In reply to johan.leroy from comment #3)
> clang version I've used:
> 
> $ clang --version
> clang version 3.8.0 (branches/release_38)
> Target: x86_64-pc-windows-msvc
> Thread model: posix
> InstalledDir: C:\LLVM\bin
> 
> file compiles without a problem

I cannot confirm this:

http://melpon.org/wandbox/permlink/Y6tlw5LQ71o1o6ei

But it doesn't really matter much, because I already provided two arguments why
the program that you have provided is non-conforming.

[Bug c++/71841] variadic template can't cast to base class

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71841

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #2 from Daniel Krügler  ---
Given the fact, that a reinterpret_cast expression cannot appear in constant
expressions, I have severe doubts that Clang would accept the code. I tried to
create a complete test-code from the given snippet as follows:

//-
#include 
#include 

struct IItem
{
  virtual void printTree(int level) = 0;
  virtual void SetRoot(IItem* RootItem) = 0;
};

template
class Item : public IItem
{
private:
static constexpr size_t c_NumberOfChilderen = (sizeof...(aItem) > 0 ?
sizeof...(aItem) : 1);
public:
IItem* RootItem;
IItem* ChildItem[c_NumberOfChilderen] = { aItem... };

Item()
{
for (size_t x = 0; x < sizeof...(aItem); x++)
{
ChildItem[x]->SetRoot(this);
}
}

void printTree(int level)
{
for (int y = 0; y < level; y++)
printf("\t");
printf("%p\n", this);
for (size_t x = 0; x < sizeof...(aItem); x++)
{
ChildItem[x]->printTree(level + 1);
}
}
void SetRoot(IItem* RootItem)
{
RootItem = RootItem;
}
};

Item<> Level10;
Item<> Level11;
Item(), reinterpret_cast()>
ItemLevel00;

int main()
{
ItemLevel00.printTree(0);
return 0;
}
//-

and as expected it is rejected by all Clang versions tested (Between 3.5.0
release and 3.9.0 trunk). Visual Studio 2015 accept the code but it shouldn't,
because (among other reasons, see below) it violates [expr.const] p2:

"A conditional-expression e is a core constant expression unless the evaluation
of e, following the rules of the abstract machine (1.9), would evaluate one of
the following expressions:
[..]
— a reinterpret_cast (5.2.10);
[..]
"

GCC currently accepts reinterpret_cast in constant expressions (see bug 49171),
but that is a different story. 

Another reason why your code is invalid is determined by the constraints of
non-type template parameters. According to [temp.arg.nontype] p1 b1, it is
invalid that a template parameter refers to a subobject, but in your code IItem
clearly is a subobject of Item.

I suggest to declare this issue as invalid.

[Bug libstdc++/71780] std::map::operator[] crashes with std::vector of objects used as key

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71780

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
I can reproduce the problem for gcc versions smaller than 4.7.3, but I doubt
that these old versions will be maintained for a fix.

[Bug libstdc++/71545] Incorrect irreflexive comparison debug check in std::lower_bound

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71545

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
I concur with the reporter, lower_bound and related functions from 25.5.3 did
got a special exception rule as of LWG 270,

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270

[Bug c++/70254] Compiler crash

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70254

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #2 from Daniel Krügler  ---
The following code:

//---
template
class NamedResourceFactory
{
using ResourceType = decltype(Creator())::type::pointer;
};

int main(){}
//---

compiled against gcc 4.9.0, 5.1.0, 5.2.0 results in the following output:


prog.cc:4:26: internal compiler error: Segmentation fault
 using ResourceType = decltype(Creator())::type::pointer;
  ^
0x94d21f crash_signal
../../gcc-4.9.0/gcc/toplev.c:337
0x56c94a resolve_typename_type(tree_node*, bool)
../../gcc-4.9.0/gcc/cp/pt.c:21385
0x5b1c01 cp_parser_nested_name_specifier_opt
../../gcc-4.9.0/gcc/cp/parser.c:5188
0x5bcc13 cp_parser_id_expression
../../gcc-4.9.0/gcc/cp/parser.c:4713
0x5bd5ff cp_parser_parse_and_diagnose_invalid_type_name
../../gcc-4.9.0/gcc/cp/parser.c:3024
0x5aa3e7 cp_parser_type_specifier_seq
../../gcc-4.9.0/gcc/cp/parser.c:18139
0x5ba452 cp_parser_type_id_1
../../gcc-4.9.0/gcc/cp/parser.c:18000
0x5bf069 cp_parser_type_id
../../gcc-4.9.0/gcc/cp/parser.c:18040
0x5bf069 cp_parser_alias_declaration
../../gcc-4.9.0/gcc/cp/parser.c:16135
0x5a43a5 cp_parser_member_declaration
../../gcc-4.9.0/gcc/cp/parser.c:20186
0x5a7f50 cp_parser_member_specification_opt
../../gcc-4.9.0/gcc/cp/parser.c:20093
0x5a7f50 cp_parser_class_specifier_1
../../gcc-4.9.0/gcc/cp/parser.c:19321
0x5a7f50 cp_parser_class_specifier
../../gcc-4.9.0/gcc/cp/parser.c:19548
0x5a7f50 cp_parser_type_specifier
../../gcc-4.9.0/gcc/cp/parser.c:14337
0x5be620 cp_parser_decl_specifier_seq
../../gcc-4.9.0/gcc/cp/parser.c:11573
0x5c2d63 cp_parser_single_declaration
../../gcc-4.9.0/gcc/cp/parser.c:23159
0x5c3224 cp_parser_template_declaration_after_export
../../gcc-4.9.0/gcc/cp/parser.c:23035
0x5cb639 cp_parser_declaration
../../gcc-4.9.0/gcc/cp/parser.c:10973
0x5ca1a8 cp_parser_declaration_seq_opt
../../gcc-4.9.0/gcc/cp/parser.c:10895
0x5cb9aa cp_parser_translation_unit
../../gcc-4.9.0/gcc/cp/parser.c:4030
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

1

Finish


The problem seems to be fixed in the current head (Tested: gcc HEAD 6.0.0
20160311 (experimental)), where the normal compiler diagnostics is produced:


prog.cc:4:26: error: need 'typename' before 'typename decltype
(Creator())::type::pointer' because 'typename decltype (Creator())::type' is a
dependent scope
 using ResourceType = decltype(Creator())::type::pointer;

[Bug c++/69924] gcc5.2 compile Error: std::basic_istream: no match for 'operator>>', while gcc 4.8 works

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69924

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #5 from Daniel Krügler  ---
(In reply to derrick from comment #3)
>   if(static_cast(std::cin  >> loc)!=1)
>  return 1;
>   if(static_cast(std::cout << loc)!=1);
>  return 1;

This is not an improvement, because that code still relies on an implicit
conversion from std::cin/std::cout to another type. In additiona the second
"if" has a suspecious semicolon right after the parentheses.

This should be correct code:

  if((static_cast(std::cin)  >> loc)!=1)
 return 1;
  if((static_cast(std::cout) << loc)!=1)
 return 1;

and it is accepted by the compiler as it should be.

[Bug c++/69898] Possibility for function with cv-qualifier-seq be adjusted to function pointer

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69898

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
I would argue that the code should be ill-formed, because the attempt to form a
pointer to a function with cv-qualifier-seq is invalid, see

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1417

[Bug libstdc++/69717] std::pair is incompatible with std::is_constructible

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69717

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
This is

http://cplusplus.github.io/LWG/lwg-defects.html#2367

[Bug libstdc++/69717] std::pair is incompatible with std::is_constructible

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69717

--- Comment #2 from Daniel Krügler  ---
This is fixed in the current trunk (Tested on gcc HEAD 6.0.0 20160207
(experimental)). Btw.: Your test case is confusing. A better test case would be
the following one, where the static assertion tests the expected outcome:

#include 
#include 

struct S {
S(int) {}
};

int main() {
using pair_t = std::pair;
static_assert(!std::is_default_constructible::value, "");
}