[Bug c++/92523] Unhelpful error messages when requires-clause contains function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92523 --- Comment #2 from Ryou Ezoe --- That is regression. The latest HEAD build of the Clang as of now indeed pass that code. But this is explicitly ill-formed code. parentheses are required. See 13.1, paragraph 9, Note.
[Bug c++/92787] New: P0634R3 is not implemented correctly if parameter-declaration appears in a default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92787
Bug ID: 92787
Summary: P0634R3 is not implemented correctly if
parameter-declaration appears in a default argument
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Target Milestone: ---
The lambda expression's parameter-declaration don't assume a qualified-id to
name a type if that parameter-declaration appears in a default argument.
> parameter-declaration in a lambda-declarator, unless that
> parameter-declaration appears in a default argument, or
parameter-declaration of a (non-type) template-parameter.
template < typename T >
// lambda expression's parameter-declaration appears in a default argument
void f( typename T::type x = []( T::type x ){return x ;}( typename T::type{})
)
{
}
https://wandbox.org/permlink/7d2d6aqjZWOhL5Pq
But current GCC 10 head assume it to name a type.
Or am I reading the wording wrong?
[Bug c++/92652] function call to lambda expression that return true does not satisfy the constraint in requires-clause if using return type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92652 --- Comment #2 from Ryou Ezoe --- Yes. this is C++20 concepts .
[Bug libstdc++/92688] New: including introduce the name index to global namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92688
Bug ID: 92688
Summary: including introduce the name index to global
namespace scope
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Target Milestone: ---
This code introduce regression after GCC 4.9 and onward.
#include
template < typename T >
struct index { }
int main() { }
Also, this code fails to compile even at GCC 4.4.7(I don't have an easy test
environment of GCC older than this version)
#include
int index ;
int main(){}
The reason is include , which include which has a
function name index on global namespace scope. The index function was
originally came from . For some reason, its name is declared on
default in
and its index function is not part of the C++ standard nor C
standard. it has been deprecated long ago. GCC without GNU extention(like with
option -std=c++XX) shall not pollute the global namespace scope with the
non-standard conforming library name that is so generic like "index" if it only
include the standard library header files.
[Bug c++/92652] New: function call to lambda expression that return true does not satisfy the constraint in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92652
Bug ID: 92652
Summary: function call to lambda expression that return true
does not satisfy the constraint in requires-clause
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Target Milestone: ---
Following code has unsatisfied constraint with error messages
prog.cc:15:25: error: could not convert 'true' from 'bool' to 'auto'
prog.cc: In lambda function:
prog.cc:15:25: error: invalid use of 'auto'
template < typename T >
requires ([]{return true ;}())
void h() { }
int main()
{
h() ; // unsatisfied constraint
}
if require-clause is like: requires(yes()), with the yes was defined like this.
constexpr auto yes(){ return true ; }
It satisfy the constraint.
As well as : requires( []()->bool{return true; }() )
but requires( []{return true;}() ) does not satisfy the constraint which I
believe it satisfy the constraint.
The entire code example.
https://wandbox.org/permlink/tlkVJFEp3LbSWqhf
[Bug c++/92556] New: ICE if using dependent name inside lambda expression in simple-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92556
Bug ID: 92556
Summary: ICE if using dependent name inside lambda expression
in simple-requirement
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Target Milestone: ---
This code produced ICE on GCC 10 2019-11-12.
template < typename T >
requires requires
{
// ICE
[]{ T::value ; } ;
}
void f()
{ }
struct S { inline static int value = 0 ; } ;
int main ()
{
// ill-formed.
f< int >() ;
// should be well-formed?
f< S >() ;
}
https://wandbox.org/permlink/cIj1qRiKzEh9ZYfw
If my understanding on P0315r4 is right, f is ill-formed, and f is
well-formed.
GCC messages.
prog.cc: In lambda function:
prog.cc:5:9: internal compiler error: in dependent_type_p, at cp/pt.c:25933
5 | []{ T::value ; } ;
| ^
0x5a50dc dependent_type_p(tree_node*)
../../source/gcc/cp/pt.c:25933
0x7062e7 dependent_scope_p(tree_node*)
../../source/gcc/cp/pt.c:25968
0x7062e7 tsubst_qualified_id
../../source/gcc/cp/pt.c:15852
0x6e3633 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:19081
0x6ec286 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:18753
0x6ec286 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18411
0x6eb71b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:17497
0x6eb71b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:17526
0x6eacf9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:17497
0x6eacf9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:17814
0x6eacf9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:17497
0x6eacf9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:17814
0x7018e5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:17497
0x7018e5 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:18707
0x6e56c3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:20099
0x6ec286 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:18753
0x6ec286 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18411
0x61ef93 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/constraint.cc:1818
0x6e4e49 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:20130
0x6ec286 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:18753
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/92523] New: Unhelpful error messages when requires-clause contains function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92523
Bug ID: 92523
Summary: Unhelpful error messages when requires-clause contains
function call
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Target Milestone: ---
Following code produce unhelpful error messages:
constexpr bool f() { return true ; }
template < typename T >
requires f()
void g(){}
https://wandbox.org/permlink/bH2Eo2aTC2JeueZt
prog.cc:4:14: error: constraint expression does not have type 'bool'
4 | requires f()
| ^
prog.cc:4:16: error: expected unqualified-id before ')' token
4 | requires f()
|^
If the requires-clause was like this:
requires 2 + 2 == 5
It does produce helpful error messages which clearly show what's wrong here.
https://wandbox.org/permlink/xIMiqWVcVrDkMU55
prog.cc:4:14: error: constraint expression does not have type 'bool'
4 | requires 2 + 2 == 5
| ^
prog.cc:4:16: error: expression after 'requires' must be enclosed in
parentheses
4 | requires 2 + 2 == 5
| ~~^~~~
| ( )
function call expression inside the requires-clause should produce helpful
messages like it already does in other expressions.
[Bug c++/92494] New: ICE on function templates with placeholder return type decltype([]{}) and return type doesn't match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92494
Bug ID: 92494
Summary: ICE on function templates with placeholder return type
decltype([]{}) and return type doesn't match
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Target Milestone: ---
Following code produce the ICE on GCC 9 and the GCC 10 latest HEAD:
template < typename T >
decltype([]{}) f( )
{ return 0 ; }
int main ()
{ f() ; }
https://wandbox.org/permlink/Cto4TbyBw0U3ywkB
Expected behaviour:
main.cpp: In function ‘ f()’:
main.cpp:3:10: error: could not convert ‘0’ from ‘int’ to ‘’
Actual behaviour:
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/80417] New: GCC does not accept a well-formed code of using declaration with pack expansion results inheriting constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80417
Bug ID: 80417
Summary: GCC does not accept a well-formed code of using
declaration with pack expansion results inheriting
constructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Target Milestone: ---
GCC does not accept a well-formed code of using declaration with pack expansion
results inheriting constructor.
Following code shall be well-formed but GCC reject it.
struct A
{
A( int ) { }
} ;
template < typename ... Types >
struct B : Types ...
{
// Inheriting Constructor
// GCC reject it
/// Clang accept it
using Types::Types... ;
} ;
int main()
{
B obj(0) ;
}
Although I have no practical application for this code, I see no wording in the
standard prohibit this so this shall be well-formed.
[Bug c++/79817] New: GCC does not recognize [[deprecated]] attribute for namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79817
Bug ID: 79817
Summary: GCC does not recognize [[deprecated]] attribute for
namespace
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Target Milestone: ---
GCC does not recognize [[deprecated]] attribute for namespace
http://melpon.org/wandbox/permlink/LVpUyDhcI75rNozy
namespace [[deprecated]] ns { int i ; }
int main()
{
ns::i = 0;
}
Above code produce following warning message.
prog.cc:1:29: warning: 'deprecated' attribute directive ignored [-Wattributes]
namespace [[deprecated]] ns { int i ; }
^
Expect this messages.
prog.cc: In function 'int main()':
prog.cc:5:9: warning: 'ns' is deprecated [-Wdeprecated-declarations]
ns::i = 0;
^
prog.cc:1:49: note: declared here
namespace [[deprecated]] ns { int i ; }
^
[Bug c++/79815] New: gcc does not implement C++ standard 7.1.7.4.1 p5 correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79815
Bug ID: 79815
Summary: gcc does not implement C++ standard 7.1.7.4.1 p5
correctly.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Target Milestone: ---
§7.1.7.4.1 paragraph 5 said.
>If the placeholder is the decltype(auto) type-specifier, T shall be the
>placeholder alone.
Following code shall be ill-formed if compiled with -std=c++14.
Because it is not placeholder alone.
int const i{} ;
// ill-formed, But GCC accept this code.
decltype(auto) const x = i ;
Affect all version of GCC.
[Bug c++/78929] Incorrect implementation of Refining Expression Evaluation Order for Idiomatic C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78929 --- Comment #2 from Ryou Ezoe --- My bad. §1.10 p18 still said "i++ + i" is undefined.
[Bug c++/78929] New: Incorrect implementation of Refining Expression Evaluation Order for Idiomatic C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78929
Bug ID: 78929
Summary: Incorrect implementation of Refining Expression
Evaluation Order for Idiomatic C++
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Target Milestone: ---
GCC 7 claims to support Refining Expression Evaluation Order for Idiomatic C++,
proposed by P0145R3.
https://gcc.gnu.org/projects/cxx-status.html#cxx1z
Current GCC 7 head does incorrect evaluation on this code.
#include
int main()
{
int i = 0 ;
std::cout << ++i + ++i ;
}
The output should be 3 but current GCC 7 head output 4.
[Bug c++/64794] New: GCC failed at virtual function with override trailing return type name, followed by override virt-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64794
Bug ID: 64794
Summary: GCC failed at virtual function with override
trailing return type name, followed by override
virt-specifier
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
GCC failed at virtual function with override
trailing return type name, followed by override virt-specifier.
Following code should be well-formed.
struct override { } ;
struct Base
{
virtual auto f() - override ;
} ;
struct Derived : Base
{
// GCC issues error: two or more data types in declaration of 'type name'
auto f() - override override ;
} ;
[Bug c++/59246] GCC should issue runtime error for calling pure virtual function with definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59246 --- Comment #3 from Ryou Ezoe boostcpp at gmail dot com --- Sorry. I should have provide a complete source code. I thought it's more helpful to issue runtime abort even though the standard doesn't requires it.
[Bug c++/59246] New: GCC should issue runtime error for calling pure virtual function with definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59246
Bug ID: 59246
Summary: GCC should issue runtime error for calling pure
virtual function with definition
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Consider the following code:
struct Base
{
virtual void f() = 0 ;
virtual ~Base() ;
} ;
// pure virtual function with definition
void Base::f() { }
Base::~Base()
{
// call by unqualified name is virtual function call.
// virtual function call during destruction is undefined.
f() ;
}
GCC does not issue runtime abort for a virtual function that also has
definition.
According to the standard(10.4 paragraph 6), this is undefined.
Since this is undefined, GCC can do anything.
But I think GCC should issue runtime abort if it is technically possible.
Clang issues runtime abort for this code.
[Bug c++/59246] GCC should issue runtime error for calling pure virtual function with definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59246 --- Comment #1 from Ryou Ezoe boostcpp at gmail dot com --- According to the de facto standard C++ ABI: http://mentorembedded.github.io/cxx-abi/abi.html#pure-virtual __cxa_pure_virtual will be called: if the user calls a non-overridden pure virtual function, which has undefined behavior according to the C++ Standard. When this abstract class Base's destructor was called, class objects derived from Base are already destructed. So it is non-overridden and it is also undefined behavior.
[Bug c++/48884] New: decltype's operand doesn't consider friend declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48884
Summary: decltype's operand doesn't consider friend declaration
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boost...@gmail.com
decltype's operand doesn't consider friend declaration if it's used as a return
type of the function.
Following code failed.
class X
{
int value ;
friend class Y ;
} ;
class Y
{
public :
template typename T
static auto f(T t) - decltype( t.value )
{
return t.value ; // OK. Y is a friend of X.
}
} ;
int main()
{
X x ;
Y::f(x) ; // gcc issues error
}
The error message is
In function 'int main()':
error: 'int X::value' is private
error: within this context
It looks like access checking is done in the main rather than Y::fX.
[Bug c++/48871] New: gcc doesn't accept null pointer value as a template non-type argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48871
Summary: gcc doesn't accept null pointer value as a template
non-type argument
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boost...@gmail.com
According to 14.3.2 [temp.arg.nontype],
a constant expression that evaluates to a null pointer or null member pointer
value can be a template argument.
Thus, following code is well-formed.
But gcc issues errors.
template void * ptr
struct X { } ;
int main()
{
X 0 x1 ; // error: could not convert template argument '0' to 'void*'
X nullptr x2 ; // error: could not convert template argument 'nullptr'
to 'void*'
}
[Bug c++/48582] New: Template non-type arguments doesn't accept null pointer constant value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48582
Summary: Template non-type arguments doesn't accept null
pointer constant value
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boost...@gmail.com
According to current C++0x draft 14.3.2 [temp.arg.nontype],
template non-type arguments can be a constant expression that evaluates to a
null pointer value or null member pointer value.
This change was made in n1905.
So the following code is well-formed.
template void * = nullptr void f() { }
int main()
{
f() ;
fnullptr() ;
f0() ;
constexpr void * ptr = nullptr ;
fptr() ;
}
But current gcc does not accept it.
Or is this just unimplemented feature?
[Bug c++/48296] New: constexpr member function cannot use the class type it belongs as parameter type or return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48296
Summary: constexpr member function cannot use the class type it
belongs as parameter type or return type
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boost...@gmail.com
constexpr member function cannot use the class type it belongs as parameter
type or return type.
gcc issues errors for the following code.
struct X
{
constexpr X() { }
// error : invalid parameter type and return type.
// same for static and non-static member function
constexpr X f( X x ) { return x ; }
} ;
I think this is a well-formed code.
Base class name can be used.
Also gcc issues errors for the following code which I think it's caused by the
same problem.
struct X
{
constexpr X() { }
// declaration
constexpr X f( X x ) ;
} ;
// definition
// error : redeclaration differs
constexpr X X::f( X x ) { return x ; }
There is no difference in the redeclaration.
So this error is wrong.
[Bug c++/47956] New: gcc accepts static data member declaration with initializer for non-const literal type if type-specifier is auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47956
Summary: gcc accepts static data member declaration with
initializer for non-const literal type if
type-specifier is auto
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boost...@gmail.com
gcc accepts static data member declaration with brace-or-equal-initializer for
non-const literal type, when the type-specifier is the plain auto specifier.
struct X
{
static auto member = 0 ;
} ;
The type of X::member is deduced to be int.
But static data member declaration is allowed to have
brace-or-equal-initializer if the type is const literal type.
So this code must be ill-formed.
[Bug c++/47957] New: Type mismatch when a class derived a same name with template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47957
Summary: Type mismatch when a class derived a same name with
template parameter
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boost...@gmail.com
This bug report is for gcc 4.6(built in 2011/02/26)
I tried other version(gcc 4.1). But it doesn't have this problem.
struct Base
{
typedef int T ;
} ;
template typename T
struct Derived : Base
{
T member ; // T is Base::T, its type is int.
void f()
{// for instantiation Derived double
// type of T is double
std::cout T= typeid(T).name() std::endl ;
T variable ;
// type of variable is double
std::cout variable= typeid(variable).name() std::endl ;
// type of member is int
std::cout member= typeid(member).name() std::endl;
}
};
int main()
{
Derived double d ;
d.f() ;
}
Derived's base class is non-dependent name, so in the class scope Derived, name
T is Base::T, not a template parameter name T.
So for instantiation Deriveddouble, the name T in Derived class scope is
Base::T. it's type is int.
But in gcc 4.6,
Although the type of Derived::member is int,
the type of T become double in the member function body.
It looks like gcc 4.6 treat name T as a template parameter T in member function
body.
[Bug c++/47210] New: Compile error on type specifier in a friend declaration designates a class type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47210
Summary: Compile error on type specifier in a friend declaration
designates a class type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boost...@gmail.com
The restriction,
An elaborated-type-specifier shall be used in a friend declaration for a
class.
, does not exists in the current C++0x draft.
In the latest draft(N2335),
11.4 Friends [class.friend] paragraph 3 said
If the type specifier in a friend declaration designates a (possibly
cv-qualified) class type, that class is declared as a friend
So, following well-formed code should be accepted under the compile option
-std=c++0x.
class Y ;
class X
{
// error on the 2011-01-01 snapshot of gcc 4.6
friend Y ; // OK, Y is class type.
} ;
[Bug c++/47210] [C++0x] Compile error on type specifier in a friend declaration designates a class type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47210 --- Comment #2 from Ryou Ezoe boostcpp at gmail dot com 2011-01-07 14:02:43 UTC --- Sorry, I didn't noticed that.
[Bug c++/45755] New: Member function template is instantiated to perform the copy
A member function template is never instantiated to perform the copy of a
class object to an object of its
class type.
But gcc instantiates it if function parameter type is the rvalue reference.
Following code shall not output anything if executed.
struct S
{
S() = default ;
template typename T
S( T ) { std::cout bad constructor std::endl ; }
template typename T
S operator = ( T ){ std::cout bad assignment operator
std::endl ; return *this ; }
} ;
int main()
{
S a ;
S b = a ; // must use trivial copy constructor
b = a ; // must use trivial assignment operator
}
But gcc instantiate and call bad constructor and assignment operator to perform
the copy.
--
Summary: Member function template is instantiated to perform the
copy
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boostcpp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45755
[Bug c++/45625] New: Template parameter name does not hide outer class scope's member name
Consider following code.
struct Outer
{
static const int value = 1 ;
template int value
struct Inner
{
static const int inner_value = value ;
static int get_value() { return value ; } // which value?
} ;
} ;
int main()
{
typedef Outer::Inner2 type ;
type::inner_value ; // 2. value is template parameter name.
type::get_value() ; // 1. value is Outer::value.
}
For Outer::Inner2, template parameter name value is 2.
Outer::Inner2::inner_value is evaluated to 2.
But Outer::Inner2::get_value() is evaluated to 1.
It looks like gcc lookup Outer::value for unqualified name value in the
function body scope of get_value().
Is it a correct behavior?
I think template parameter name of Inner should hide the Outer::value.
--
Summary: Template parameter name does not hide outer class
scope's member name
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boostcpp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45625
[Bug c++/45539] New: Redeclare a deleted funciton makes gcc does not issue compile error
I think re-declare a deleted function is well-formed.
void f() = delete ; // shall be the first declaration of the function
void f() ; // re-declare a previous deleted function.
But doing so makes gcc does not issue correct compile errors on following code.
void f() = delete ;
void f() ; // if I comment out this line. gcc issues correct errors.
int main()
{
// should be error: use of deleted function 'void f()'
// gcc does not issue error for this.
typedef decltype(f) type ;
// gcc issues error for this.
// However, error message was: undefined reference to `f()'
// correct error should be: use of deleted function 'void f()'
f() ;
}
--
Summary: Redeclare a deleted funciton makes gcc does not issue
compile error
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boostcpp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45539
[Bug c++/45225] New: gcc accepts ill-formed template code combining Variadic Templates and Partial specialization
gcc accepts following code.
Basically, this code specify template arguments to ordinary template parameter
pack(i.e. non template template parameter pack).
// given this primary template
template typename ... Types
class Foo { } ;
// gcc accepts this parcial specialization
// If I use template keyword.
template typename ... Types, typename ... Params
class Foo template Types Params... ...
{ } ;
// gcc also accepts this. the difference is position of template keyword.
template typename ... Types, typename ... Params
class Foo Types template Params... ...
{ } ;
This must be ill-formed.
The template keyword for the typename-specifier is for nested-name-specifier.
Types is not.
Types is not a template template parameter pack, yet it takes template
arguments if I use broken typename-specifier-like syntax.
When I found this, I wanted to write class template Foo which can be
instantiated like this:
Foo
std::tupleint, char, short,
std::tuplefloat,
std::tupledouble, double
foo ;
It accepts any number of std::tuple types(or whatever class templates) with
each std::tuple take any number of template arguments in any type.
The obvious implementation of this is using template template parameter pack in
partial specialization.
template typename ... Types
class Foo { };
template
template typename ... class ... Types,
typename ... Params
class Foo Types Params... ...
{ } ;
But I happened to write above ordinary template parameter pack version.
And found this bug.
--
Summary: gcc accepts ill-formed template code combining Variadic
Templates and Partial specialization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boostcpp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45225
[Bug c++/45225] gcc accepts ill-formed template code combining Variadic Templates and Partial specialization
--- Comment #1 from boostcpp at gmail dot com 2010-08-07 12:18 ---
I also noticed gcc accept this code.
Should I create separate bug report?
template typename ... Types
class Foo { };
// Params is template parameter.
template typename ... Types, typename Params
class Foo typename template Types Params ...
{ } ;
int main()
{
// gcc accepts this.
// actually tuple must take exactly one template argument.
Foo std::tupleint, int, std::tupleint, float, double a ;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45225
[Bug c++/45225] gcc accepts ill-formed template code combining Variadic Templates and Partial specialization
--- Comment #2 from boostcpp at gmail dot com 2010-08-07 12:18 ---
My bad. Never mind.
(In reply to comment #1)
I also noticed gcc accept this code.
Should I create separate bug report?
template typename ... Types
class Foo { };
// Params is template parameter.
template typename ... Types, typename Params
class Foo typename template Types Params ...
{ } ;
int main()
{
// gcc accepts this.
// actually tuple must take exactly one template argument.
Foo std::tupleint, int, std::tupleint, float, double a ;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45225
[Bug c++/45225] gcc accepts ill-formed template code combining Variadic Templates and Partial specialization
--- Comment #3 from boostcpp at gmail dot com 2010-08-07 12:25 --- Come to think of it, It just use primary template. If I don't write the difinition of primary template, gcc issues error. template typename ... Types class Foo ; But still, I think this template keyword usage in partial specialization is ill-formed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45225
[Bug c++/45225] gcc accepts ill-formed template code combining Variadic Templates and Partial specialization
--- Comment #4 from boostcpp at gmail dot com 2010-08-07 14:17 ---
It doesn't compile the following code which I think well-formed.
#include tuple
template typename ... Types
class Foo ;
template
template typename ... class ... Types,
typename ... Params
class Foo Types Params... ...
{ } ;
int main()
{
Foo std::tupleint, std::tupleint, int a ;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45225
[Bug c++/44703] New: List initialization fail if parameter is typedef name for the std::initializer_list
List initialization fail if parameter is typedef-name of the
std::initializer_list.
#include initializer_list
typedef std::initializer_listint type ;
void f(type) {}
int main()
{
// error: could not convert '{1, 2, 3}' to 'type'
f({1,2,3}) ;
}
--
Summary: List initialization fail if parameter is typedef name
for the std::initializer_list
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boostcpp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44703
[Bug c++/43397] New: std::function can't forward rvalue reference for pointer to member function
std::function can't forward rvalue reference for pointer to member function
struct Foo
{
void operator() ( int ) { }
void func( int ) { }
} ;
int main()
{
Foo foo ;
// OK
std::function void ( int ) f1( foo ) ;
f1(0) ;
// Error
std::function void ( Foo , int ) f2( Foo::func ) ;
f2(foo, 0) ;
}
--
Summary: std::function can't forward rvalue reference for pointer
to member function
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boostcpp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43397
[Bug c++/43315] Variadic Templates affects the overload resolution rank
--- Comment #4 from boostcpp at gmail dot com 2010-03-11 12:26 --- It looks like gcc is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43315
[Bug c++/43315] Variadic Templates affects the overload resolution rank
--- Comment #3 from boostcpp at gmail dot com 2010-03-10 22:30 --- I'm not sure about this. Maybe gcc is right. Even though it take zero parameter, it's still there. I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43315
[Bug c++/43315] New: Variadic Templates affects the overload resolution rank
Following code is compiled and print #1.
But I think it should be ambiguous error.
template typename T
void f(T) { std::cout #1 std::endl ; }
template typename T, typename ... Types
void f( T, Types ... ) { std::cout #2 std::endl ; }
int main()
{
f(0) ;// #print #1
}
It looks like gcc thinks Non-Variadic Templates version of f(#1) is the best
viable function.
However, since overload resolution is performed after the template
instantiation.
And template parameter pack is defined as follows.
In 14.6.3 Variadic templates [temp.variadic]
A template parameter pack is a template parameter that accepts zero or more
template arguments.
It says that template parameter pack can accept zero template argument.
The expression f(0) has zero template argument for template parameter pack.
So in the above code, I think Variadic Templates function's signature after
instantiated will be void (int).
Because template parameter pack has zero types.
template typename T, typename ... Types
void f( T, Types ... )
{
int status = 0 ;
std::cout abi::__cxa_demangle(typeid(fT, Types...).name(), 0, 0,
status) std::endl ;
}
int main()
{
f(0) ;// print void ()(int)
}
It looks like gcc thinks the same way.
So if Variadic Templates version of f()'s signature is void (int), it's
exactly same with Non-Variadic Templates version of f().
Thus, call should be ambiguous.
--
Summary: Variadic Templates affects the overload resolution rank
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boostcpp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43315
[Bug c++/43315] Variadic Templates affects the overload resolution rank
--- Comment #1 from boostcpp at gmail dot com 2010-03-10 00:08 --- Umm, I found that non-variadic template is more specialized than the variadic templates. I wonder it affects this. However, in this case, I think there is no type to be specialized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43315
[Bug c++/43261] New: name depends on Variadic Template Parameter is looked up at the point of definition
Dependant name shall be look up at the point of instantiation.
But for names that depends on Variadic Template Parameter, are looked up at the
point of definition.
Following code is well-formed. and shall be compiled.
template typename T, typename ... Args
void f(T, Args... rest)
{// point of defination
f(rest...) ;
}
template typename T
void f(T)
{ /* Terminate the recursion. */}
int main()
{
// point of instantiation.
f(0,0,0,0) ;
}
But compiler said error: no matching function for call to 'f()'
If I change the declaration order:
// just flip the order.
template typename T
void f(T)
{ /* Terminate the recursion. */}
template typename T, typename ... Args
void f(T, Args... rest)
{// point of definition
f(rest...) ;
}
int main()
{
f(0,0,0,0) ;
}
It works.
So the name depends on Variadic Tamplate Parameter is somehow looked up at the
point of definition where it shall be at the point of instantiation.
--
Summary: name depends on Variadic Template Parameter is looked up
at the point of definition
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boostcpp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43261
[Bug c++/43261] name depends on Variadic Template Parameter is looked up at the point of definition
--- Comment #3 from boostcpp at gmail dot com 2010-03-05 00:55 --- Thank you. Now I understand the real problem. But still, it's nasty. I wonder C++0x fix this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43261
