[Bug c++/88675] New: std::make_integer_sequence not working for enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88675
Bug ID: 88675
Summary: std::make_integer_sequence not working for enums
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: huili80 at gmail dot com
Target Milestone: ---
The following code doesn't compile with --std=c++17:
#include
enum Number
{
Zero,
One,
Two,
Three
};
int main()
{
std::make_integer_sequence s;
}
The error read:
/usr/include/c++/8/utility: In substitution of 'template
using make_integer_sequence = std::integer_sequence<_Tp,
__integer_pack(_Num)...> [with _Tp = Number; _Tp _Num = (Number)3]':
t.cpp:13:43: required from here
/usr/include/c++/8/utility:329:55: error: invalid conversion from 'sizetype' to
'Number' [-fpermissive]
= integer_sequence<_Tp, __integer_pack(_Num)...>;
^
/usr/include/c++/8/utility:329:55: error: invalid conversion from 'sizetype' to
'Number' [-fpermissive]
/usr/include/c++/8/utility:329:55: error: invalid conversion from 'sizetype' to
'Number' [-fpermissive]
I suspect that this would be an easy fix by changing
/usr/include/c++/8/utility:329 to
= integer_sequence<_Tp, _Tp(__integer_pack(_Num))...>;
[Bug c++/91477] New: error messages stop including column numbers for large source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91477 Bug ID: 91477 Summary: error messages stop including column numbers for large source file Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: huili80 at gmail dot com Target Milestone: --- At work we have generated headers that can be millions of lines. While compiling with gcc-8.2.1, I noticed that I'm not getting column numbers in error messages, only getting filenames and line numbers. I initially tried adding -fshow-column but that didn't help. After experimenting a bit, the problem appears to show up when header files are large, regardless what code is actually in the headers, and regardless of whether the code in the headers is related to the code that is erroneous. I didn't try to find the exact file size to produce this problem, but I observed that when the pre-processed source file had about 690k lines (~26MB in size), column numbers were no longer shown in errors. The only other compiler i had was gcc4.8.2 and I don't have the same problem.
[Bug c++/66674] New: name lookup failure in lambda construction in a member function of a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66674
Bug ID: 66674
Summary: name lookup failure in lambda construction in a member
function of a template class
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: huili80 at gmail dot com
Target Milestone: ---
The following causes internal compiler error with gcc4.8.2.
struct base
{
void foo(){};
};
template < typename >
struct derived : base
{
void foo()
{
auto l = [this](){base::foo();};
// workaround:
// auto l = [this](){this->base::foo();};
};
};
int main()
{
derived d;
d.foo();
}
[Bug c++/99186] New: std::tuple compilation error when elements are specializations of template class declared with template < auto E > syntax with E being a enumerator of a enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99186
Bug ID: 99186
Summary: std::tuple compilation error when elements are
specializations of template class declared with
template < auto E > syntax with E being a enumerator
of a enum
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: huili80 at gmail dot com
Target Milestone: ---
Example code below:
#include
#include
enum class E1 {a};
enum class E2 {b,c};
template < auto >
struct S
{
int i;
};
static_assert(not std::is_same_v,S>);
struct D
: S, S
{};
int main()
{
D d;
d.S::i = 0;
std::tuple,S,S> x;
std::get<0>(x).i = 0;
std::get>(x).i = 0;
std::get>(x).i = 0; // does not compile
return 0;
}
GCC 10.2 c++17 gives the following error:
In file included from main.cpp:2:
/usr/local/include/c++/10.2.0/tuple: In instantiation of 'constexpr _Tp&
std::get(std::tuple<_UTypes ...>&) [with _Tp = S _Types = {S,
S, S}]':
main.cpp:27:24: required from here
/usr/local/include/c++/10.2.0/tuple:1339:37: error: no matching function for
call to '__get_helper2 >(std::tuple, S, S >&)'
1339 | { return std::__get_helper2<_Tp>(__t); }
| ~~~^
/usr/local/include/c++/10.2.0/tuple:1327:5: note: candidate: 'template constexpr _Head&
std::__get_helper2(std::_Tuple_impl<__i, _Head, _Tail ...>&)'
1327 | __get_helper2(_Tuple_impl<__i, _Head, _Tail...>& __t) noexcept
| ^
/usr/local/include/c++/10.2.0/tuple:1327:5: note: template argument
deduction/substitution failed:
/usr/local/include/c++/10.2.0/tuple:1339:37: note: 'std::_Tuple_impl<__i,
S, _Tail ...>' is an ambiguous base class of 'std::tuple,
S, S >'
1339 | { return std::__get_helper2<_Tp>(__t); }
| ~~~^
/usr/local/include/c++/10.2.0/tuple:1332:5: note: candidate: 'template constexpr const _Head&
std::__get_helper2(const std::_Tuple_impl<__i, _Head, _Tail ...>&)'
1332 | __get_helper2(const _Tuple_impl<__i, _Head, _Tail...>& __t)
noexcept
| ^
/usr/local/include/c++/10.2.0/tuple:1332:5: note: template argument
deduction/substitution failed:
/usr/local/include/c++/10.2.0/tuple:1339:37: note: 'const
std::_Tuple_impl<__i, S, _Tail ...>' is an ambiguous base class of
'std::tuple, S, S >'
1339 | { return std::__get_helper2<_Tp>(__t); }
| ~~~^
Output:
If E1 and E2 had been non-scoped enums, the code results in the same compiler
error.
It's curious that the error mentions ambiguous base classes in std::tuple's
implementation. Given that std::get>(x) compiles fine, I speculated
that the compiler may have incorrectly thought that S and S are
the same type since E1::a and E2::b have the same numeric value (zero).
However, that speculation is proven wrong by other parts of the example code
clearly shows that the compiler does NOT think S and S are the
same type, e.g., the static_assert that S and S are not the same
type, and that even though struct D inherits from both S, S, we
can access its base S's member variable.
