[Bug c++/65870] New: Explicit function instantiation with default valued lambda causes duplicate symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65870
Bug ID: 65870
Summary: Explicit function instantiation with default valued
lambda causes duplicate symbol
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: w.shane.grant at gmail dot com
When explicitly instantiating functions with default lambda parameters, g++
generates multiple versions of the lambda with the same symbol names.
I've created a minimal example:
struct Any
{
template class T
Any( T const ){}
};
template class T
void func( T t, Any a = [](){} ){}
template void funcint( int, Any );
template void funcdouble( double, Any );
int main()
{
func( 3 );
func( 3.0 );
return 0;
}
Compiled with g++ -std=c++11 (4.7.4, 4.8.3, and 4.9.1) , this causes the error:
/tmp/ccND7XlM.s:104: Error: symbol `_ZN3AnyC2IUlvE_EERKT_' is already defined
If this is indeed incorrect behavior (I don't know enough about the spec to
confirm this), I believe the problem is that the name mangling for the lambda
is not taking the parent template into account.
[Bug c++/57713] New: Template functions see friendship as inherited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57713
Bug ID: 57713
Summary: Template functions see friendship as inherited
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: w.shane.grant at gmail dot com
Template functions that are friends of a class bypass access control for
derived classes.
--
template class T T declval();
template class T
auto foo() - decltype(declvalT().bar()) {}
class Base
{
private:
template class T
friend auto foo() - decltype(declvalT().bar());
void bar(){}
};
class Derived : public Base {};
int main()
{
fooDerived();
}
---
bar should be private in Derived but the friend declaration in Base is allowing
foo to access it, preventing compilation from failing. Here's another very
similar example:
-
template class T
void foo(Tt)
{
t.bar();
}
class Base
{
private:
template class T
friend void foo(T);
void bar(){}
};
class Derived : public Base {};
int main()
{
foo(Derived());
}
Derived gets the ability to call bar() only inside of the template function
foo.
Happens on (4.9.0 20130625 (experimental)) and (4.8.1).
[Bug c++/57713] Template functions see friendship as inherited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57713
Shane w.shane.grant at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Shane w.shane.grant at gmail dot com ---
Marking invalid since I think this was actually a case of not interpreting
friendship correctly. A simpler test case:
class Base {
private:
friend void foo();
void bar();
};
class Derived : public Base {};
void foo() { Derived().bar(); }
also compiles with no error because has access to Base (due to friendship) and
thus access to bar.
[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
Shane w.shane.grant at gmail dot com changed:
What|Removed |Added
CC||w.shane.grant at gmail dot com
--- Comment #16 from Shane w.shane.grant at gmail dot com ---
I think some variant of this bug may still exist (using g++ (Ubuntu
4.8.1-2ubuntu1~13.04) 4.8.1). The following code will fail to compile under
g++ but will correctly compile under a recent version of clang++ (3.3).
template class T
T declval();
template class T
constexpr auto hasSize(int) - decltype(declvalT().size(), bool())
{ return true; }
template class T
constexpr bool hasSize(...)
{ return false; }
struct A
{
int size();
};
struct B : private A
{
};
static_assert(hasSizeA(0), A);
static_assert(!hasSizeB(0), B);
int main() {}
The error produced is:
test.cpp: In substitution of ‘templateclass T constexpr decltype
((declvalT().size(), bool())) hasSize(int) [with T = B]’:
test.cpp:22:28: required from here
test.cpp:5:61: error: ‘A’ is not an accessible base of ‘B’
constexpr auto hasSize(int) - decltype(declvalT().size(), bool())
^
test.cpp: In substitution of ‘templateclass T constexpr decltype
((declvalT().size(), bool())) hasSize(int) [with T = B]’:
test.cpp:22:28: required from here
test.cpp:5:61: error: ‘A’ is not an accessible base of ‘B’
[Bug c++/41437] No access control for classes in template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
Shane w.shane.grant at gmail dot com changed:
What|Removed |Added
CC||w.shane.grant at gmail dot com
--- Comment #5 from Shane w.shane.grant at gmail dot com ---
This bug still exists for g++ 4.8.1. Crops up regardless of where the template
function is that tries to access the protected/private member:
class Base { void snarf() {} };
struct Derived : public Base
{
template class T
void bar( T t )
{
snarf(); // this is incorrectly marked ok
}
};
[Bug c++/57243] New: Using auto in range based for with templated container in templated function requires extraneous template qualifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57243
Bug ID: 57243
Summary: Using auto in range based for with templated container
in templated function requires extraneous template
qualifier
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: w.shane.grant at gmail dot com
Using the auto keyword in a range based for loop under three conditions related
to templating requires an unnecessary use of the template qualifier for
compilation to happen successfully:
1. The container being iterated is templated
2. The range based for loop is inside of a template function
3. The iterated item has a template function
Here is a minimal example:
struct snarf
{
template class T
void get() {}
};
template class T
struct container
{
snarf * begin() { return nullptr; }
snarf * end() { return nullptr; }
};
template class T
void foo()
{
containerint arr;
for( auto i : arr )
i.getint();
}
int main()
{
return 0;
}
The issue goes away if any of the following happen:
- foo is made a non template function
- arr is made a non template container
- auto is replaced with the actual type (snarf in this example)
- the function called on the range declaration (i) is not templated
- the template keyword is used to disambiguate the call to get
- the range based for loop is replaced with a standard for loop over the
iterators (auto works fine here)
Issue seems to happen with both versions of g++ I have installed (4.7.3 and g++
4.8.1 20130401) but not under clang (version 3.3 (trunk 178896)).
[Bug c++/56774] New: G++ 4.8 reverses variadic template types during unpacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774
Bug #: 56774
Summary: G++ 4.8 reverses variadic template types during
unpacking
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w.shane.gr...@gmail.com
In g++ 4.8, it seems as if variadic templates are reversed when being unpacked.
Consider the following minimal example:
#include tuple
#include iostream
template class T, class ... OtherT
void something( std::tupleT, OtherT... tup )
{
std::cout std::get1(tup) std::endl;
}
int main()
{
std::tupleint, char, bool myTuple(3, 'a', true);
// Compiles OK in GCC 4.6.3 but NOT 4.8
somethingint, char, bool( myTuple );
// Compiles OK in GCC 4.8 but NOT 4.6.3
somethingint, bool, char( myTuple );
return 0;
}
The output of this, if the appropriate line is commented out, will be: 'a'. To
get code that previously worked under 4.6.3, the template parameters that will
be unpacked have to be reversed.
See relevant Stack Overflow post here:
http://stackoverflow.com/questions/15692112/gcc-4-8-is-reversing-variadic-template-parameter-pack
[Bug c++/56774] [4.7/4.8/4.9 Regression] G++ 4.8 reverses variadic template types during unpacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774
--- Comment #4 from Shane w.shane.grant at gmail dot com 2013-03-29 00:21:32
UTC ---
(In reply to comment #1)
We badly need a reduced testcase not using the whole tuple (not to mention
iostream of course)
Here's a more reduced test case.
template class ... Args
struct mytype {};
template class T, class ... Args
void something( mytypeT, Args... )
{ }
int main()
{
// Compiles OK in GCC 4.6.3 but NOT 4.8
somethingint, char, bool( mytypeint, char, bool() );
// Compiles OK in GCC 4.8 but NOT 4.6.3
somethingint, bool, char( mytypeint, char, bool() );
return 0;
}
I tried to make simpler cases using purely variadic templates (e.g. no class
T), but the issue only shows up when there is an individually named template
parameter as well as a variadic pack. To get the error to show up it also
requires types that cannot be implicitly converted to each other.
