[Bug c++/92494] New: ICE on function templates with placeholder return type decltype([]{}) and return type doesn't match

[boostcpp at gmail dot com]

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++/92523] New: Unhelpful error messages when requires-clause contains function call

[boostcpp at gmail dot com]

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++/92556] New: ICE if using dependent name inside lambda expression in simple-requirement

[boostcpp at gmail dot com]

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++/92652] New: function call to lambda expression that return true does not satisfy the constraint in requires-clause

[boostcpp at gmail dot com]

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 libstdc++/92688] New: including introduce the name index to global namespace scope

[boostcpp at gmail dot com]

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] function call to lambda expression that return true does not satisfy the constraint in requires-clause if using return type deduction

[boostcpp at gmail dot com]

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

--- Comment #2 from Ryou Ezoe  ---
Yes. this is C++20 concepts .

[Bug c++/92787] New: P0634R3 is not implemented correctly if parameter-declaration appears in a default argument

[boostcpp at gmail dot com]

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++/92523] Unhelpful error messages when requires-clause contains function call

[boostcpp at gmail dot com]

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++/47210] New: Compile error on type specifier in a friend declaration designates a class type

[boostcpp at gmail dot com]

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

[boostcpp at gmail dot com]

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

--- Comment #2 from Ryou Ezoe  2011-01-07 14:02:43 
UTC ---
Sorry, I didn't noticed that.

[Bug c++/47956] New: gcc accepts static data member declaration with initializer for non-const literal type if type-specifier is auto

[boostcpp at gmail dot com]

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

[boostcpp at gmail dot com]

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 Derived, 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++/59246] New: GCC should issue runtime error for calling pure virtual function with definition

[boostcpp at gmail dot com]

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

[boostcpp at gmail dot com]

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

--- Comment #1 from Ryou Ezoe  ---
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++/59246] GCC should issue runtime error for calling pure virtual function with definition

[boostcpp at gmail dot com]

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

--- Comment #3 from Ryou Ezoe  ---
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++/78929] New: Incorrect implementation of Refining Expression Evaluation Order for Idiomatic C++

[boostcpp at gmail dot com]

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++/78929] Incorrect implementation of Refining Expression Evaluation Order for Idiomatic C++

[boostcpp at gmail dot com]

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++/79815] New: gcc does not implement C++ standard 7.1.7.4.1 p5 correctly.

[boostcpp at gmail dot com]

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++/79817] New: GCC does not recognize [[deprecated]] attribute for namespace

[boostcpp at gmail dot com]

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++/80417] New: GCC does not accept a well-formed code of using declaration with pack expansion results inheriting constructor

[boostcpp at gmail dot com]

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++/43261] New: name depends on Variadic Template Parameter is looked up at the point of definition

[boostcpp at gmail dot com]

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

[boostcpp at gmail dot com]

--- 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

[Bug c++/43315] New: Variadic Templates affects the overload resolution rank

[boostcpp at gmail dot com]

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(f).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

[boostcpp at gmail dot com]

--- 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++/43315] Variadic Templates affects the overload resolution rank

[boostcpp at gmail dot com]

--- 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] Variadic Templates affects the overload resolution rank

[boostcpp at gmail dot com]

--- 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++/43397] New: std::function can't forward rvalue reference for pointer to member function

[boostcpp at gmail dot com]

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++/64794] New: GCC failed at virtual function with "override" trailing return type name, followed by override virt-specifier

[boostcpp at gmail dot com]

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++/48296] New: constexpr member function cannot use the class type it belongs as parameter type or return type

[boostcpp at gmail dot com]

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++/48582] New: Template non-type arguments doesn't accept null pointer constant value

[boostcpp at gmail dot com]

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() ;
f() ;
f<0>() ;

constexpr void * ptr = nullptr ;
f() ;
}

But current gcc does not accept it.
Or is this just unimplemented feature?

[Bug c++/48871] New: gcc doesn't accept null pointer value as a template non-type argument

[boostcpp at gmail dot com]

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++/48884] New: decltype's operand doesn't consider friend declaration

[boostcpp at gmail dot com]

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::f.

[Bug c++/45225] New: gcc accepts ill-formed template code combining Variadic Templates and Partial specialization

[boostcpp at gmail dot com]

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::tuple,
std::tuple,
std::tuple
> 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

[boostcpp at gmail dot com]

--- 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::tuple, std::tuple > 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

[boostcpp at gmail dot com]

--- 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::tuple, std::tuple > 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

[boostcpp at gmail dot com]

--- 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

[boostcpp at gmail dot com]

--- 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 

template < typename ... Types >
class Foo ;

template <
template < typename ...  > class ... Types,
typename ... Params
>
class Foo< Types< Params... > ... >
{ } ;


int main()
{
Foo< std::tuple, std::tuple > a ;
}


-- 


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

[Bug c++/45539] New: Redeclare a deleted funciton makes gcc does not issue compile error

[boostcpp at gmail dot com]

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++/45625] New: Template parameter name does not hide outer class scope's member name

[boostcpp at gmail dot com]

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::Inner<2> type ;

type::inner_value ; // 2. value is template parameter name.
type::get_value() ; // 1. value is Outer::value.
}

For Outer::Inner<2>, template parameter name "value" is 2.
Outer::Inner<2>::inner_value is evaluated to 2.
But Outer::Inner<2>::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++/45755] New: Member function template is instantiated to perform the copy

[boostcpp at gmail dot com]

"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++/44703] New: List initialization fail if parameter is typedef name for the std::initializer_list

[boostcpp at gmail dot com]

List initialization fail if parameter is typedef-name of the
std::initializer_list.

#include 

typedef std::initializer_list 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