[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776 Philipp changed: What|Removed |Added CC||jason at redhat dot com --- Comment #1 from Philipp --- CCing Jason because this bug is still unconfirmed. Please tell me if that's ok to do. This issue is still present in gcc-4.8.1 and also on trunk.
[Bug c++/53599] New: gcc-4.7.1_rc20120606 segfaults compiling boost.karma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53599 Bug #: 53599 Summary: gcc-4.7.1_rc20120606 segfaults compiling boost.karma Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: s...@s-e-f-i.de The attached preprocessed source makes the first release candidate of gcc-4.7 segfault, gcc-4.7.0 was fine. No additional compilation options are required. I have just spotted this and not begun to try to reduce the testcase.
[Bug c++/53599] gcc-4.7.1_rc20120606 segfaults compiling boost.karma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53599 --- Comment #1 from Philipp 2012-06-06 21:45:30 UTC --- Created attachment 27574 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27574 Preprocessed source
[Bug c++/53599] [4.7/4.8 Regression] gcc-4.7.1_rc20120606 segfaults compiling boost.karma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53599 --- Comment #3 from Philipp 2012-06-07 09:14:56 UTC --- Created attachment 27575 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27575 Reduced testcase
[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51930 --- Comment #7 from Philipp 2012-02-15 09:29:27 UTC --- The test struct might come from an external library I have no control of, which will make it difficult to change its visibility. Currently, I have quite some code that depends on the behaviour of gcc-4.6 and lower that won't be easy to change.
[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51930 --- Comment #10 from Philipp 2012-02-15 12:02:09 UTC --- But think about a header only library. My test case isn't that far fetched. A simple struct with no member functions (except for the implicitly generated ones) should need no visibility at all, in my opinion. I can work around this somehow, but wouldn't it be better to fix it?
[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51930 --- Comment #14 from Philipp 2012-02-27 11:06:20 UTC --- The new behaviour makes it pretty much impossible for me to retain the visibility gcc has been giving me with the old behaviour. It is impossible to only give every type that is somehow involved in a template instantiation (and a lot of them happen to be simple typedef helper structs) default visibility. A lot of them come from external libraries I have no control over. I have tried and gave up after some hours. The push/pop visibility can be done, if one is very careful. Doing this on a fine grained level is out of the question. You know how C++ includes and their include guards work. You have to put the push/pop macros around the first inclusion of such a header, which is almost never possible. If you decide to go for a wider push/pop scope (for example all the headers in the TU that does the explicit instantiation(s)) then you might end up giving a lot of stuff default visibility that you don't want to. Even if this method would succeed, it would still mean a lot of extra macro invocations just for gcc-4.7. Please, I don't know how to properly deal with this, and would like the old behaviour to be restored.
[Bug c++/51813] New: -fvisibility=hidden causes std::codecvt members to be undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51813
Bug #: 51813
Summary: -fvisibility=hidden causes std::codecvt members to be
undefined
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@s-e-f-i.de
The following program causes undefined symbols when -fvisibility=hidden is
used:
#include
int main()
{
std::use_facet
>(std::locale());
}
g++-4.7 -fvisibility=hidden test.cpp
/tmp/cclBRkzy.o: In function `main':
test.cpp:(.text+0x1d): undefined reference to `std::codecvt const& std::use_facet
>(std::locale const&)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120107/../../../../x86_64-pc-linux-gnu/bin/ld:
a.out: hidden symbol
`_ZSt9use_facetISt7codecvtIwc11__mbstate_tEERKT_RKSt6locale' isn't defined
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120107/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value
collect2: error: ld returned 1 exit status
It works with gcc-4.6.2.
use_facet is only an example. I had other functions like do_length, the
destructor, etc. reported as undefined as well.
[Bug c++/51930] New: Explicitly instantiated template gets hidden visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51930
Bug #: 51930
Summary: Explicitly instantiated template gets hidden
visibility
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@s-e-f-i.de
gcc-4.7 produces a symbol with hidden visibility for testfunc, while
gcc-4.6 produces a symbol with default visibility.
struct foo
{
};
template<
typename T
>
__attribute__ ((visibility("default")))
void testfunc();
template<
typename T
>
void testfunc()
{
}
template
__attribute__ ((visibility("default")))
void testfunc();
I compiled this with
g++-4.7 -fvisibility=hidden -shared test.cpp
If I replace
struct foo {};
with
struct __attribute__ ((visibility("default"))) foo {};
then testfunc gets default visibility even with gcc-4.7.
Is this intentional?
[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51930
Philipp changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #5 from Philipp 2012-01-29 12:19:48 UTC ---
Thanks, Jason, the above test case now works.
However, a similar problem with explicitly instantiated template classes still
exists.
Here is a test case.
struct test
{
};
template<
typename T
>
struct template_test
{
__attribute__((visibility("default")))
void function();
};
template<
typename T
>
void template_test::function()
{
}
template
__attribute__((visibility("default")))
struct template_test;
With gcc-4.7, template_test::function gets hidden visibility, while with
gcc-4.6.2 it gets default visibility.
[Bug c++/55776] New: -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776
Bug #: 55776
Summary: -Wshadow generates an incorrect warning with enum
classes
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@s-e-f-i.de
In C++11 mode, enum classes can generate incorrect -Wshadow warnings:
g++ -Wshadow -std=c++11 test.cpp
typedef int foo;
enum class myenum
{
foo
};
test.cpp:5:2: warning: declaration of 'foo' shadows a global declaration
[-Wshadow]
test.cpp:1:13: warning: shadowed declaration is here [-Wshadow]
Note, that if the typedef and the definition of the enum class are reversed, no
warning is produced.
[Bug c++/55908] New: Problem binding a const member function to a const object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55908
Bug #: 55908
Summary: Problem binding a const member function to a const
object
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@s-e-f-i.de
The following code fails to compile:
#include
typedef std::functionfunc;
struct foo
{
void f(int) const
{
}
void g() const
{
func(std::bind(&foo::f, this, std::placeholders::_1));
}
};
int main()
{
}
g++-4.8.0-alpha20130106 -std=c++11 test.cpp
test.cpp: In member function 'void foo::g() const':
test.cpp:14:55: error: no matching function for call to
'std::function::function(std::_Bind_helper&>::type)'
func(std::bind(&foo::f, this, std::placeholders::_1));
^
test.cpp:14:55: note: candidates are:
In file included from test.cpp:1:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2252:2:
note: template std::function<_Res(_ArgTypes
...)>::function(_Functor)
function(_Functor);
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2252:2:
note: template argument deduction/substitution failed:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2227:7:
note: std::function<_Res(_ArgTypes ...)>::function(std::function<_Res(_ArgTypes
...)>&&) [with _Res = void; _ArgTypes = {int}]
function(function&& __x) : _Function_base()
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2227:7:
note: no known conversion for argument 1 from 'std::_Bind_helper&>::type {aka
std::_Bind(const foo*,
std::_Placeholder<1>)>}' to 'std::function&&'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2430:5:
note: std::function<_Res(_ArgTypes ...)>::function(const
std::function<_Res(_ArgTypes ...)>&) [with _Res = void; _ArgTypes = {int}]
function<_Res(_ArgTypes...)>::
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2430:5:
note: no known conversion for argument 1 from 'std::_Bind_helper&>::type {aka
std::_Bind(const foo*,
std::_Placeholder<1>)>}' to 'const std::function&'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2207:7:
note: std::function<_Res(_ArgTypes ...)>::function(std::nullptr_t) [with _Res =
void; _ArgTypes = {int}; std::nullptr_t = std::nullptr_t]
function(nullptr_t) noexcept
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2207:7:
note: no known conversion for argument 1 from 'std::_Bind_helper&>::type {aka
std::_Bind(const foo*,
std::_Placeholder<1>)>}' to 'std::nullptr_t'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2200:7:
note: std::function<_Res(_ArgTypes ...)>::function() [with _Res = void;
_ArgTypes = {int}]
function() noexcept
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2200:7:
note: candidate expects 0 arguments, 1 provided
The problem goes away if the int parameter is taken out, or if g() is not
const.
gcc-4.7.2 accepts the test case.
[Bug c++/48003] Regression in Template Constants from 4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48003
Philipp changed:
What|Removed |Added
CC||s...@s-e-f-i.de
--- Comment #1 from Philipp 2011-03-06 12:29:29 UTC ---
Small testcase.
#include
template
struct test
{
typedef test prior;
};
typedef test foo;
foo f;
int main()
{
}
Of course INT_MIN - 1 is undefined but should gcc really evaluate it here?
[Bug c++/49507] New: ICE because of defaulted template destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49507
Summary: ICE because of defaulted template destructor
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@s-e-f-i.de
The following code makes rc1 of gcc-4.6.1 segfault:
template
struct ConcretePoolKey
{
virtual ~ConcretePoolKey();
};
template
ConcretePoolKey::~ConcretePoolKey() = default;
int main()
{
ConcretePoolKey foo;
}
/usr/bin/g++ -std=c++0x test.cpp
test.cpp: In destructor 'ConcretePoolKey::~ConcretePoolKey() [with T =
int]':
test.cpp:13:1: instantiated from here
test.cpp:2:8: internal compiler error: Segmentation fault
[Bug c++/49507] [4.6/4.7 Regression] ICE because of defaulted template destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49507 --- Comment #6 from Philipp 2011-06-24 10:26:06 UTC --- Applying the changes on top of gcc-4.6.1 rc1 fixes the problem for me. Thanks!
