using the debian sid standard : GNU C++ (Debian 4.7.2-5) version 4.7.2 (x86_64-linux-gnu) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 warning: MPFR header version 3.1.0-p10 differs from library version 3.1.1-p2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiling boost spirit.qi code, Here is the one that creates the error. Invocation is : /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -std=gnu++11 -fdump-translation-unit treedumpparse.ii the output is: (this is the last of the function print ) std::size_t boost::detail::variant::variant_hasher::operator()(const T&) const the error is : In file included from /usr/include/boost/variant/variant.hpp:35:0, from /usr/include/boost/spirit/home/support/info.hpp:14, from /usr/include/boost/spirit/home/qi/domain.hpp:16, from /usr/include/boost/spirit/home/qi/meta_compiler.hpp:15, from /usr/include/boost/spirit/home/qi/action/action.hpp:14, from /usr/include/boost/spirit/home/qi/action.hpp:14, from /usr/include/boost/spirit/home/qi.hpp:14, from /usr/include/boost/spirit/include/qi.hpp:16, from treedumpparse.cpp:6: /usr/include/boost/variant/detail/hash_variant.hpp:32:33: internal compiler error: in timevar_start, at timevar.c:344 Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions. This can be reproduced with this one include : #include "/usr/include/boost/variant/detail/hash_variant.hpp" I am trying to reduce the problem, but it is difficult.
I tried to reduce the input size but it is not producing any results. namespace std { typedef long unsigned int size_t; }; namespace boost { namespace detail { struct is_static_visitor_tag { }; typedef void static_visitor_default_return; } template <typename R = ::boost::detail::static_visitor_default_return> class static_visitor : public detail::is_static_visitor_tag { public: typedef R result_type; protected: static_visitor() { } ~static_visitor() { } };} namespace boost { template <class T> struct hash; template <class T> void hash_combine(std::size_t& seed, T const& v); template <class It> std::size_t hash_range(It, It); template <class It> void hash_range(std::size_t&, It, It); } namespace boost { namespace detail { namespace variant { struct variant_hasher: public boost::static_visitor<std::size_t> { template <class T> std::size_t operator()(T const& val) const { using namespace boost; hash<T> hasher; return hasher(val); } }; } }}
Here is a small change to work around the crash : namespace boost { namespace detail { namespace variant { struct variant_hasher: public //boost:: static_visitor<std::size_t> { template <class T> std::size_t operator()(T const& val) const { //using namespace boost; hash<T> hasher; return hasher(val); } }; }} } It is the uneeded namespace usage that causes the problem.
I'm still not seeing in attach a self contained (minimized) reproducer.
Created attachment 30259 [details] test case this is the minimal test case that I have. by applying the small namespace changes to the end it will go away.
Sorry, It seems that the original attachment was not applied, I have bzip2ed it so now it fits. thanks mike
I have filed a small cosmetic bug in boost about this change to the namespace usage : https://svn.boost.org/trac/boost/ticket/8651
I can't reproduce the issue anywhere. Eg, not on stock FSF 4.7.2, not on 4.8 or current mainline. Can somebody reproduce?
Tested like this: /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -std=gnu++11 -fdump-translation-unit testvariant_min.ii
Calling cc1plus directly, I can reproduce with trunk. The failing assert in timevar.c is: /* Don't allow the same timing variable to be started more than once. */ gcc_assert (!tv->standalone); /usr/include/boost/variant/detail/hash_variant.hpp:33:24: internal compiler error: in timevar_start, at timevar.c:343 0xcce161 timevar_start(timevar_id_t) /data/repos/gcc/trunk/gcc/timevar.c:343 0x7cfa85 push_using_directive /data/repos/gcc/trunk/gcc/cp/name-lookup.c:5652 0x7cfa34 push_using_directive_1 /data/repos/gcc/trunk/gcc/cp/name-lookup.c:5641 0x7cfa91 push_using_directive /data/repos/gcc/trunk/gcc/cp/name-lookup.c:5653 0x7ca70e do_using_directive(tree_node*) /data/repos/gcc/trunk/gcc/cp/name-lookup.c:3933 0x7ca7a7 parse_using_directive(tree_node*, tree_node*) /data/repos/gcc/trunk/gcc/cp/name-lookup.c:3957 0x6ddce4 cp_parser_using_directive /data/repos/gcc/trunk/gcc/cp/parser.c:15732 0x6d5ceb cp_parser_block_declaration /data/repos/gcc/trunk/gcc/cp/parser.c:10670 0x6d53df cp_parser_declaration_statement /data/repos/gcc/trunk/gcc/cp/parser.c:10344 0x6d2e33 cp_parser_statement /data/repos/gcc/trunk/gcc/cp/parser.c:9107 0x6d371b cp_parser_statement_seq_opt /data/repos/gcc/trunk/gcc/cp/parser.c:9379 0x6d361e cp_parser_compound_statement /data/repos/gcc/trunk/gcc/cp/parser.c:9333 0x6e1e23 cp_parser_function_body /data/repos/gcc/trunk/gcc/cp/parser.c:18066 0x6e20b0 cp_parser_ctor_initializer_opt_and_function_body /data/repos/gcc/trunk/gcc/cp/parser.c:18102 0x6e8f28 cp_parser_function_definition_after_declarator /data/repos/gcc/trunk/gcc/cp/parser.c:22080 0x6eab72 cp_parser_late_parsing_for_member /data/repos/gcc/trunk/gcc/cp/parser.c:22730 0x6e36cc cp_parser_class_specifier_1 /data/repos/gcc/trunk/gcc/cp/parser.c:18825 0x6e3795 cp_parser_class_specifier /data/repos/gcc/trunk/gcc/cp/parser.c:18849 0x6da899 cp_parser_type_specifier /data/repos/gcc/trunk/gcc/cp/parser.c:13861 0x6d66b4 cp_parser_decl_specifier_seq /data/repos/gcc/trunk/gcc/cp/parser.c:11152
I have reported the problem in the code to boost, they have fixed it. https://svn.boost.org/trac/boost/ticket/8651#comment:1 The problem is having to do with underspecifed namespace selection. They changed the code to remove the crash. mike
This still happens with 4.9: markus@x4 more % cat test.ii namespace detail { namespace indirect_traits {} using namespace indirect_traits; void fn1() { using namespace detail; } } markus@x4 more % g++ -ftime-report -c test.ii test.ii: In function ‘void detail::fn1()’: test.ii:5:17: internal compiler error: in timevar_start, at timevar.c:343 using namespace detail; ^
As far as I can see, it's just matter of using timevar_cond_start instead of timevar_start.
Author: paolo Date: Fri Jan 24 15:45:14 2014 New Revision: 207047 URL: http://gcc.gnu.org/viewcvs?rev=207047&root=gcc&view=rev Log: /cp 2014-01-24 Paolo Carlini <paolo.carlini@oracle.com> PR c++/57524 * name-lookup.c (push_using_directive): Use timevar_cond_start. /testsuite 2014-01-24 Paolo Carlini <paolo.carlini@oracle.com> PR c++/57524 * g++.dg/ext/timevar2.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/timevar2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
Author: paolo Date: Fri Jan 24 15:53:07 2014 New Revision: 207048 URL: http://gcc.gnu.org/viewcvs?rev=207048&root=gcc&view=rev Log: /cp 2014-01-24 Paolo Carlini <paolo.carlini@oracle.com> PR c++/57524 * name-lookup.c (push_using_directive): Use timevar_cond_start. /testsuite 2014-01-24 Paolo Carlini <paolo.carlini@oracle.com> PR c++/57524 * g++.dg/ext/timevar2.C: New. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/ext/timevar2.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/name-lookup.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
Fixed mainline and 4.8.3.