[Bug c++/94716] New: Address of constexpr variable not usable in constant expression

[bluescarni at gmail dot com]

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

Bug ID: 94716
   Summary: Address of constexpr variable not usable in constant
expression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bluescarni at gmail dot com
  Target Milestone: ---

The following code does not compile in GCC trunk:

-
template 
inline constexpr char test_impl = 0;

template 
inline constexpr auto *id = &test_impl;

int main() {
static_assert(id != id, "should not be equal");
}
-

The error message:

-
: In function 'int main()':

:8:27: error: non-constant condition for static assertion

8 | static_assert(id != id, "should not be equal");

  |   ^~~~

:8:27: error: '((& test_impl) != (& test_impl))' is not a
constant expression

Compiler returned: 1
-

See on godbolt:

https://godbolt.org/z/CS4D8B

Clang and MSVC accept the code.

[Bug c++/95132] New: Concept checked after auto return type deduction

[bluescarni at gmail dot com]

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

Bug ID: 95132
   Summary: Concept checked after auto return type deduction
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bluescarni at gmail dot com
  Target Milestone: ---

It seems like in GCC's implementation of C++20 concepts, concept checking is
done after the instantiation of the body of a function with auto return type
deduction.

See the godbolt link, where the same snippet of code is being compiled with
GCC, clang and MSVC:

https://godbolt.org/z/CMzZyV

As you see, the first GCC error comes from the failure in the instantiation of
the body of function bar(), and only later GCC complains about the concept
check failure. The other two compilers don't produce any error from the
instantiation of bar().

This is problematic because it means that another concept that would check
whether or not bar() can be called with a specific argument type would fail
with a hard compile time error, instead of marking the concept as not
satisfied.

[Bug c++/57626] New: [C++11] ICE with template alias and member function pointer

[bluescarni at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57626

Bug ID: 57626
   Summary: [C++11] ICE with template alias and member function
pointer
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bluescarni at gmail dot com

Created attachment 30309
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30309&action=edit
Test case showing the problem

The attached reduced code snippet produces an ICE in both GCC 4.8.1 and 4.7.3.
The error messages are respectively:

---
bug.cpp: In substitution of ‘template class TT,
class ... Args> using bar = void (T::*)(TT&, const symbol_set&) [with
T = Term; TT = Args ...; Args = {Args ...}]’:
bug.cpp:8:86:   required from here
bug.cpp:4:58: internal compiler error: in tsubst, at cp/pt.c:11324
 using bar = void(T::*)(TT &, const symbol_set &);
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.gentoo.org/> for instructions.
---

and

---
bug.cpp:4:58: internal compiler error: in tsubst, at cp/pt.c:11057
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.gentoo.org/> for instructions.
---

Note that the code snippet is malformed and it is not supposed to compile.
clang++ 3.2 produces the error message:

---
bug.cpp:8:79: error: template argument for template template parameter must be
a class template or type alias template
 template (&Term::multiply))>
  ^
1 error generated.
---

[Bug c++/57684] New: [c++11] Lambda is not convertible to std::function

[bluescarni at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684

Bug ID: 57684
   Summary: [c++11] Lambda is not convertible to std::function
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bluescarni at gmail dot com

Created attachment 30344
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30344&action=edit
Code snippet demonstrating the problem.

A specific setup with CRTP pattern and a static unordered_map member in the
base class is preventing conversion from a lambda expression to an
std::function. The problem is reproduced in the attached code snippet. The
error produced by GCC 4.8.1 is:


main.cpp: In function ‘int main()’:
main.cpp:20:3: error: no matching function for call to
‘std::function::function(main()::__lambda0)’
  });
   ^
main.cpp:20:3: note: candidates are:
In file included from main.cpp:1:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2255:2: note:
template std::function<_Res(_ArgTypes
...)>::function(_Functor)
  function(_Functor);
  ^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2255:2: note: 
 template argument deduction/substitution failed:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2230:7: note:
std::function<_Res(_ArgTypes ...)>::function(std::function<_Res(_ArgTypes
...)>&&) [with _Res = derived; _ArgTypes = {const derived&}]
   function(function&& __x) : _Function_base()
   ^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2230:7: note: 
 no known conversion for argument 1 from ‘main()::__lambda0’ to
‘std::function&&’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2433:5: note:
std::function<_Res(_ArgTypes ...)>::function(const std::function<_Res(_ArgTypes
...)>&) [with _Res = derived; _ArgTypes = {const derived&}]
 function<_Res(_ArgTypes...)>::
 ^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2433:5: note: 
 no known conversion for argument 1 from ‘main()::__lambda0’ to ‘const
std::function&’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2210:7: note:
std::function<_Res(_ArgTypes ...)>::function(std::nullptr_t) [with _Res =
derived; _ArgTypes = {const derived&}; std::nullptr_t = std::nullptr_t]
   function(nullptr_t) noexcept
   ^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2210:7: note: 
 no known conversion for argument 1 from ‘main()::__lambda0’ to
‘std::nullptr_t’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2203:7: note:
std::function<_Res(_ArgTypes ...)>::function() [with _Res = derived; _ArgTypes
= {const derived&}]
   function() noexcept
   ^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2203:7: note: 
 candidate expects 0 arguments, 1 provided


(Sorry for not being able to reduce the test case further, but I was able to
reproduce the problem only by pulling in std::unordered_map. GCC 4.7.3 and
Clang++ 3.3 both compile the snippet without errors.)

The problem disappears if one replaces the static member definition with one of
the commented lines or even if one replaces the existing main() body with this:


std::function foo([](const derived &d) {
return d;
});


I.e., by changing the std::function to return void instead of derived.

[Bug c++/57684] [c++11] Lambda is not convertible to std::function

[bluescarni at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684

--- Comment #2 from Francesco Biscani  ---
(In reply to Jonathan Wakely from comment #1)
> I think the problem is that unordered_map requires its template arguments to
> be complete at the time of instantiation, otherwise it's undefined behaviour.
> 
> When the static member is instantiated the type Derived is not complete,
> because base is instantiated before the body of derived.
> 
> So although it would be nice if this worked, I think it technically relies
> on undefined behaviour.

Thanks for the quick reply!

I understand this might be a bit OT here, but would wrapping the static member
in an std::unique_ptr avoid UB?

[Bug c++/57684] [c++11] Lambda is not convertible to std::function

[bluescarni at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684

--- Comment #4 from Francesco Biscani  ---
(In reply to Jonathan Wakely from comment #3)
> Yes, because std::unique_ptr has a special exception that says it can be
> instantiated with incomplete types, so that should work OK (like your case
> where the static member is a raw pointer, which prevents unordered_map being
> instantiated when base<> is instantiated.
> 
> I hope for GCC 4.9 we can make unordered_map support incomplete types again,
> so the original code would work, but it doesn't support them currently,
> which is allowed by the standard.

Thanks for the explanation, gonna wrap my code in unique_ptr then.

As a side note, this seems to work for std::map, are the requirements different
regarding the completeness of types?

[Bug libstdc++/58030] New: Mismatched tags in std::hash friends

[bluescarni at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58030

Bug ID: 58030
   Summary: Mismatched tags in std::hash friends
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bluescarni at gmail dot com

I am testing out clang in conjunction with GCC 4.8.1's libstdc++ in c++11 mode.
I routinely get these warnings when compiling with -Wall and -Wextra:

---

/home/yardbird/repos/piranha/src/rational.hpp:1753:1: warning: 'hash' defined
as a struct template here but previously declared as
  a class template [-Wmismatched-tags]
struct hash
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../include/c++/4.8.1/bits/stl_bvector.h:523:31:
note: did you mean struct here?
template friend class hash;
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../include/c++/4.8.1/bitset:763:33:
note: did you mean struct here?
  template friend class hash;
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../include/c++/4.8.1/bits/stl_bvector.h:523:31:
note: did you mean struct here?
template friend class hash;
  ^

---

Indeed, these friendship declarations in bitset and stl_bvector.h use 'class'
instead of 'struct' when referring to std::hash. It is my understanding that
this behaviour does not constitute a violation of the standard... still it irks
my compiler warnings OCD :)

Any chance this could be fixed sometimes?

[Bug libstdc++/58030] Mismatched tags in std::hash friends

[bluescarni at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58030

--- Comment #3 from Francesco Biscani  ---
Sorry, I did search for "mismatched tags" but it seemed like nothing came up :/

Thanks for taking the time to reply.

[Bug c++/51884] New: ICE with c++11 thread and templates

[bluescarni at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51884

 Bug #: 51884
   Summary: ICE with c++11 thread and templates
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bluesca...@gmail.com


Created attachment 26354
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26354
Code snippet demonstrating the issue.

The attached minimal code snippet causes an ICE on g++-4.5.3, g++-4.6.2 and
g++-4.7.0-alpha20111231. The compilation command is:

g++ -std=c++0x bug.cpp

The output on 4.5:

In file included from bug.cpp:1:0:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/thread:112:7: internal
compiler error: in dfs_walk_once, at cp/search.c:1645

The output on 4.6:

In file included from bug.cpp:1:0:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4/thread:109:14: internal
compiler error: in dfs_walk_once, at cp/search.c:1659

The output on 4.7:

‘
In file included from bug.cpp:1:0:
in dfs_walk_once, at cp/search.c:1695

The ICE is avoided at least in these cases:

- replace the method bar() with a non-templated version,
- replace the std::enable_if<...> enabler with void.

[Bug c++/51884] ICE with c++11 thread and templates

[bluescarni at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51884

--- Comment #1 from Francesco Biscani  2012-01-17 
17:02:16 UTC ---
Created attachment 26355
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26355
Code snippet demonstrating the issue.

[Bug c++/51884] ICE with c++11 thread and templates

[bluescarni at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51884

--- Comment #2 from Francesco Biscani  2012-01-17 
17:03:03 UTC ---
Sorry, had initially uploaded the wrong code snippet, now it should be the
correct one.

[Bug c++/78925] New: Inline friend template function not hidden during ADL

[bluescarni at gmail dot com]

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

Bug ID: 78925
   Summary: Inline friend template function not hidden during ADL
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bluescarni at gmail dot com
  Target Milestone: ---

Consider the code:

--

namespace ns
{

template 
struct foo
{
template 
friend void bar(U) {}
};

}

int main()
{
ns::foo f_int;
bar(f_int);

ns::foo f_double;
bar(f_double);
}

--

Clang compiles this code without complaining, but every GCC version I have
tried (namely, 5.4.0 and the current trunk) fails, complaining about the
redefinition of ns::bar(). What seems to happen here is that during the lookup
for the second bar() call, the instantiation of bar() triggered by the first
call is considered via ADL, thus leading to two identical overloads being
present at the same time in the candidate set.

[Bug c++/78925] Inline friend template function not hidden during ADL

[bluescarni at gmail dot com]

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

--- Comment #1 from Francesco Biscani  ---
Commenting either call to bar() leads to successful compilation.