[Bug c++/52343] [C++11] alias-definition dont work in `templateclass` params type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52343 --- Comment #2 from Larry Evans cppljevans at suddenlink dot net 2012-11-06 20:53:02 UTC --- Created attachment 28625 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28625 test file
[Bug c++/52343] [C++11] alias-definition dont work in `templateclass` params type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52343 --- Comment #3 from Larry Evans cppljevans at suddenlink dot net 2012-11-06 20:55:19 UTC --- Created attachment 28626 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28626 compilation of test file with 2 compilers and 2 values of macro. The error is shown when -DUSE_ALIAS and with the later compiler, which was created with release configuration. The earlier compiler, with debug configuration, doesn't show error.
[Bug c++/54710] moderately large tuple, with many gets, ballons compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 --- Comment #8 from Larry Evans cppljevans at suddenlink dot net 2012-09-27 14:03:25 UTC --- Created attachment 28292 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28292 with optimization set to -O1 for both gcc and clang Shows much larger user (and elapsed) times with -O1, but still same trend of gcc vs clang as LAST_LESS increases, i.e. relative gcc performance degrades.
[Bug c++/54710] moderately large tuple, with many gets, ballons compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 --- Comment #9 from Larry Evans cppljevans at suddenlink dot net 2012-09-27 14:12:24 UTC --- (In reply to comment #7) Can you provide absolute compile-times The .out files show output of unix time command. Is that not what you mean by absolute compile-times? If not, could you explain how I get absolute compile-times? alongside source complexity (like the number of required template instantiations?). How would you recommend I get this information? Also you are using the compiler default optimization settings which for CLANG is (IIRC) to do optimization and for GCC is to not do. You might want to try -O1 for both and/or explicit -O0 for both. I've just attached another .zip file where -O1 was used. OTOH, looking at the clang compiler command path, I see it includes: /Debug+Asserts/bin/clang which suggests it was created with some sort of runtime checks which maybe slows it down, like the: --enable-checking=assert,misc,tree,gc,rtl,runtime does for clang. Will investigate. HTH. -regards, Larry
[Bug c++/54710] moderately large tuple, with many gets, ballons compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 Larry Evans cppljevans at suddenlink dot net changed: What|Removed |Added Attachment #28292|0 |1 is obsolete|| --- Comment #10 from Larry Evans cppljevans at suddenlink dot net 2012-09-27 18:58:17 UTC --- Created attachment 28294 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28294 with optimized clang, still with optimized gcc, both with -O1 Remade clang with make ENABLE_OPTIMIZED=1. Clang times improved a lot. Now, the degradation of relative performance of gcc w.r.t. clang is more dramatic. Still, gcc does better at low LAST_LESS, but reaches break even at lower LAST_LESS (about 8).
[Bug c++/54710] moderately large tuple, with many gets, ballons compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 --- Comment #5 from Larry Evans cppljevans at suddenlink dot net 2012-09-26 19:01:30 UTC --- (In reply to comment #4) That: --enable-checking=assert,misc,tree,gc,rtl,runtime will enable very compile-time intensive internal checking. Use --enable-checking=release or at most the default checking options (which are yes). If you compare with other compilers always use release checking. Thanks Richard. I've downloaded: ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120923/gcc-4.8-20120923.tar.bz2 and configured with --enable-checking=release. As a result, the gcc times to improve a lot; however, there's still the degredation of the time w.r.t. clang and the macro, LAST_LESS approaches TUPLE_SIZE: LAST_LESS gcc/clang times - --- 4 0.28 16 1.15 20 1.70 Certainly 1.70 is much better than 3.34. A new .zip file is attached. I don't know if this indicates there's still a problem. -regards, Larry
[Bug c++/54710] moderately large tuple, with many gets, ballons compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 Larry Evans cppljevans at suddenlink dot net changed: What|Removed |Added Attachment #28274|0 |1 is obsolete|| --- Comment #6 from Larry Evans cppljevans at suddenlink dot net 2012-09-26 19:04:14 UTC --- Created attachment 28288 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28288 newer gcc with --enable-checking=release still shows relative performance degradation wrt clang
[Bug c++/54710] New: moderately large tuple, with many gets, ballons compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 Bug #: 54710 Summary: moderately large tuple, with many gets, ballons compile time Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: cppljev...@suddenlink.net Created attachment 28274 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28274 zip file containing source code, make files, make output, timing output Using a multiple inheritance tuple implementation, and with many gets to elements of tuple, compile time ballons from: 0.5 * the compile time using clang to: 3.4 * the compile time using clang when tuple size is 20. The attached include a make file (suffix .mk) and the test driver (suffix .cpp). The time results are in the .txt files. The time results show that as macro value LAST_LESS goes from 4 to 20, g++ compiles faster than clang, but as LAST_LESS approaches TUPLE_SIZE, g++ slows down dramatically. Could g++ be enhanced so that the compile times do no increase so dramatically? -regards, Larry
[Bug c++/54710] moderately large tuple, with many gets, ballons compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 --- Comment #2 from Larry Evans cppljevans at suddenlink dot net 2012-09-25 17:15:29 UTC --- The gcc compiler was downloaded from: ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120624/gcc-4.8-20120624.tar.bz2 it was configured with the shell script: #!/bin/bash this_dir=`pwd` $this_dir/../src/configure \ --prefix=$this_dir/../install \ --enable-languages=c++ \ --enable-checking=assert,misc,tree,gc,rtl,runtime and my system is: uname -a Linux evansl-desktop 2.6.32-41-generic #90-Ubuntu SMP Tue May 22 11:29:51 UTC 2012 x86_64 GNU/Linux
[Bug c++/41727] inner template specialization on non-type arg template causes ICE
--- Comment #2 from cppljevans at suddenlink dot net 2009-11-21 16:46
---
Created an attachment (id=19075)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19075action=view)
zip archive with test case and Makefile and compile output
The recently attached .zip file contains:
M Filemode Length Date Time File
- -- --- -
-rw-r--r-- 1621 21-Nov-2009 09:40:04 bug.value_wrap.cpp
-rw-r--r-- 1061 21-Nov-2009 09:57:30 bug.value_wrap.report
-rw-r--r-- 1215 21-Nov-2009 09:53:30 Makefile
- -- --- -
3897 3 files
The .cpp File is the source file which was compiled with the Makefile
to produce the .report file. The .report shows the compilation of the
.cpp with every possible combination of {defined,undefined} properties
for Macros in {OUTER_ARG0_SPECIALIZED,INNER_ARG1_NON_TYPE}. All
compiles with -DOUTER_ARG0_SPECIALIZED succeed. Both compiles with
-UOUTER_ARG0_SPECIALIZED fail; however, the one with
-DINNER_ARG1_NON_TYPE produces the ICE.
I suspect the problem is related to the attempt to substitute an outer
template argument into the slot for an inner template parameter as
noted in the following post to the gcc.devel newsgroup:
http://article.gmane.org/gmane.comp.gcc.devel/110111/match=pt+c+most_specialized_class
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41727
[Bug c++/41727] New: inner template specialization on non-type arg template causes ICE
when:
template
class Tag
struct
outer
{
template
typename Arg0
, typename Arg1
struct
inner
;
};
is specialized on Tag and Arg1 where Arg1 is value_wrapArg1Int,
ICE is generated at cp/pt.c:9668 from recent (yesterday?)
svn update.
--
Summary: inner template specialization on non-type arg template
causes ICE
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cppljevans at suddenlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41727
[Bug c++/41727] inner template specialization on non-type arg template causes ICE
--- Comment #1 from cppljevans at suddenlink dot net 2009-10-16 10:01 --- Created an attachment (id=18807) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18807action=view) testcase with compiler output shown in comments Compiler output showing ICE is shown in comments after: //CompilerOutput: at bottom of source code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41727
[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
--- Comment #12 from cppljevans at suddenlink dot net 2009-08-16 13:44 --- Created an attachment (id=18375) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18375action=view) compare of `make -k check-c++` before and after patch The attached .zip file contains the diffs between gcc/cp/tree.c before and after the `make -k check-c++` runs shown in other element of the diffs file. These diffs of check-c++ before and after the patch were made according to the instructions here: http://gcc.gnu.org/contribute.html#testing Does anything else need to be done before the patch is accepted? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
--- Comment #11 from cppljevans at suddenlink dot net 2009-08-15 15:44 --- Created an attachment (id=18371) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18371action=view) test case for gcc/testsuite/g++.dg/cpp0x with gcc-4.5 compile This is even a more minimal test case. This is modelled after the other files in gcc/testsuite/g++.dg/cpp0x. Would someone conform this as a bug or briefly explain why it's not a bug? TIA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
--- Comment #10 from cppljevans at suddenlink dot net 2009-08-13 19:15 --- Created an attachment (id=18356) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18356action=view) minimal test case demonstrating bug The comments at bottom show that wrong template instance is being selected by cp_tree_equal. For example, with: //#define INTEGRAL0_C cp_tree_equal tries to select the integral_c,Values from struct package_c for integral1_c,Value_1::type_1; however, since Value_1 is not a parameter pack, compiler gives confusing error message about Values not being expanded, OTOH, with: #define INTEGRAL0_C the compiler tries to use the type of integral0_c,Value_0::type_0 for the integral,Values in the supertype of package_c; however, since, in this case, Value_0 is not a parameter pack, compiler gives error about no contained argument packs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
--- Comment #9 from cppljevans at suddenlink dot net 2009-08-12 19:15 --- As indicated here: http://article.gmane.org/gmane.comp.gcc.bugs/254672 the problem occurs because an additional test is needed in cp_tree_equal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
--- Comment #8 from cppljevans at suddenlink dot net 2009-08-03 12:08 --- Created an attachment (id=18288) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18288action=view) Shows Value_0 fail but Value_1 pass Since Value_0 and Value_1 only differ in argument number, hopefully this gives some further hint about where problem lies. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
--- Comment #6 from cppljevans at suddenlink dot net 2009-07-13 12:48 --- Created an attachment (id=18184) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18184action=view) Similar but simpler source (no Tail... in impl_front specialization) Same error message, but no Tail... in impl_front template. Compile output in separate attachment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
--- Comment #7 from cppljevans at suddenlink dot net 2009-07-13 12:50 --- Created an attachment (id=18185) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18185action=view) compilation using gcc-4.5-20090702 Compiler source from: ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090702/gcc-4.5-20090702.tar.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
--- Comment #5 from cppljevans at suddenlink dot net 2009-06-11 21:24 --- Created an attachment (id=17984) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17984action=view) another version of earlier attach with a little different code but similar error msg This version shows a little different error. The compiler error msg suggests compiler is looking at wrong subtree. In this version it appears to think Values is the expansion pattern; however, integral_cIntegral,Values is the actual expansion pattern. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
--- Comment #4 from cppljevans at suddenlink dot net 2009-05-15 01:19 --- Created an attachment (id=17869) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17869action=view) Much simpler code showing problem Code has #defines which can be enabled or disabled to show or hide bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/40092] New: -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
When compile trysto expand: : seq integral_c Integral , Vals ... the error diagnostic prints integral_cT, val instead of integral_cIntegral,Vals. The integral_constant template is derived from integral_c and does have T and val args: struct integral_constant:public mpl::integral_c T, val However, when that is replaced with: struct integral_constant;//:public mpl::integral_c T, val Compilation succeeds. -- Summary: -std=gnu++0x expansion pattern fails with error about derived template instead of actual template Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cppljevans at suddenlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
--- Comment #3 from cppljevans at suddenlink dot net 2009-05-10 16:24 --- Created an attachment (id=17846) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17846action=view) system type -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
--- Comment #2 from cppljevans at suddenlink dot net 2009-05-10 16:22 --- Created an attachment (id=17845) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17845action=view) compilation output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
--- Comment #1 from cppljevans at suddenlink dot net 2009-05-10 16:22 --- Created an attachment (id=17844) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17844action=view) The .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
[Bug c++/33983] stdexcept and ostream invalid_argument name clash with -std=gnu++0x
--- Comment #2 from cppljevans at suddenlink dot net 2007-11-02 15:17 --- Created an attachment (id=14469) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14469action=view) output of preprocessor -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33983
[Bug c++/33983] stdexcept and ostream invalid_argument name clash with -std=gnu++0x
--- Comment #1 from cppljevans at suddenlink dot net 2007-11-02 15:10 --- Created an attachment (id=14468) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14468action=view) Shows nameclash when using -std=-std=gnu++0x The following is compile commands and output: /home/evansl/download/gcc/4.3-20071026/install/bin/g++ -c -std=gnu++0x -Wall -ftemplate-depth-100 -O0 -fno-inline -I/home/evansl/prog_dev/boost-svn/ro/trunk/sandbox/.. -I/home/evansl/prog_dev/boost-svn/ro/trunk/sandbox/lje /home/evansl/prog_dev/boost-svn/ro/trunk/sandbox/lje/libs/xpressive/proto/example/std_invalid_argument_name_clash.cpp -o /home/evansl/prog_dev/boost-svn/ro/trunk/sandbox/build/gcc4_3v/lje/libs/xpressive/proto/example/std_invalid_argument_name_clash.o -MMD /home/evansl/prog_dev/boost-svn/ro/trunk/sandbox/lje/libs/xpressive/proto/example/std_invalid_argument_name_clash.cpp:10: error: expected constructor, destructor, or type conversion before 'const' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33983
[Bug c++/33983] New: stdexcept and ostream invalid_argument name clash with -std=gnu++0x
Both these system include files define invalid_argument. ostream does this by indrectly including i686-pc-linux-gnu/bits/error_constants.h. This is for the 20071026 snapshot. -- Summary: stdexcept and ostream invalid_argument name clash with -std=gnu++0x Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cppljevans at suddenlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33983
[Bug c++/33959] [4.1/4.2/4.3 Regression] ICE in instantiate_class_template, at cp/pt.c:6649
--- Comment #5 from cppljevans at suddenlink dot net 2007-11-01 21:26 --- Created an attachment (id=14459) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14459action=view) testcase Several macros to enable exploring reasons for ice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33959
[Bug c++/33959] [4.1/4.2/4.3 Regression] ICE in instantiate_class_template, at cp/pt.c:6649
--- Comment #6 from cppljevans at suddenlink dot net 2007-11-01 21:28 --- Created an attachment (id=14460) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14460action=view) testcase Several macros to enable exploring reasons for ice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33959
[Bug c++/33959] [4.1/4.2/4.3 Regression] ICE in instantiate_class_template, at cp/pt.c:6649
--- Comment #7 from cppljevans at suddenlink dot net 2007-11-01 21:38 --- Please ignore 1st attachment. I selected auto-detect thinking it would auto-detect it as text/plain. When #define INST_GT, the friend operator is instantiated and this give the ice. OTOH, when #undef INST_GT, apparently the fried operator is not instantiated and compiler gives: main-pt-c-ice.cpp:68: error: no match for 'operator' in 'a_arg a_arg' So maybe the compiler is right about having to instantiate enclosing class. Maybe what I really need is a templated namespace, as mentioned here: http://groups.google.com/group/comp.std.c++/browse_thread/thread/4baec3f90675a166/6eb713e7bb143b09?lnk=gstq=namespace+template#6eb713e7bb143b09 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33959
[Bug c++/33959] New: ice in cp/pt.c instantiate_class_template
Error also occurs in g++4.3 in 20071026 snapshot. In that snapshot, the ice occurred on line 6651 which is a gcc_assert preceded by comment: /* We should never instantiate a nested class before its enclosing class; we need to look up the nested class by name before we can instantiate it, and that lookup should instantiate the enclosing class. */ I will attach the output from make showing the error and the .ii file (once I figure how to do that). -- Summary: ice in cp/pt.c instantiate_class_template Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cppljevans at suddenlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33959
[Bug c++/33959] ice in cp/pt.c instantiate_class_template
--- Comment #1 from cppljevans at suddenlink dot net 2007-10-31 15:09
---
I was unable to create attachment; so, here's the source (no #includes).
-- cut here --
//Purpose:
// Reproduce, with simplified code, the error:
/*
main.cpp:1675: instantiated from here
main.cpp:1277: internal compiler error: in instantiate_class_template, at
cp/pt.c:6651
*/
//reported in main.cpp.log on line 767 which occured during
//compile of main.cpp with gcc-4.3-20071026 on:
// Tue Oct 30 08:45:37
//The same error occurred with gcc-4.1, but not gcc-3.4.
//
template
typename Variables
struct
gram_tree
{
typedef
Variables
vars
;
struct
defn_variable
{
public:
typedef
defn_variable
my_type
;
defn_variable(void)
{}
defn_variable(my_type const a_copy)
;
template
typename Rhs
defn_variable(Rhs const a_rhs)
;
my_type const
operator=(my_type const a_var)
;
template
typename Rhs
my_type const
operator=(Rhs const a_rhs)
;
};//end defn_variable struct
struct
productions
{
productions(void)
;
defn_variable
operator[](typename vars::symb_enum)
;
};//end productions struct
//begin: Composite expressions
struct
expr_sequence
{
template
typename Left
, typename Right
struct
node
{
node(Left const a_left, Right const a_right)
;
};
};
template
typename Left
, typename Right
friend
expr_sequence::nodeLeft,Right
operator(Left const a_left, Right const a_right)
;
//end: Composite expressions
};//end gram_treeVariables struct
struct
vars
{
enum
symb_enum
{ e
};
};//exit vars struct
int
main(void)
{
typedef gram_treevars gt;
gt::productions prods;
prods[vars::e]=prods[vars::e] prods[vars::e] ;
return 0;
}
-- cut here --
and here's the make output
-- cut here --
cd
/home/evansl/prog_dev/boost-svn/ro/trunk/sandbox/lje/libs/grammar_pipeline/test/spirit_proto/
make -f Makefile.imk bugrept
/usr/bin/g++-4.1 -c -Wall -ftemplate-depth-100 -O0 -fno-inline -v -save-temps
main-pt-c-ice.cpp -o bugrept
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
/usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -E -quiet -v -D_GNU_SOURCE
main-pt-c-ice.cpp -mtune=i686 -Wall -ftemplate-depth-100 -fno-inline -O0
-fpch-preprocess -o main-pt-c-ice.ii
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/i486-linux-gnu
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.1.2/include
/usr/include
End of search list.
/usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -fpreprocessed main-pt-c-ice.ii
-quiet -dumpbase main-pt-c-ice.cpp -mtune=i686 -auxbase-strip bugrept -O0 -Wall
-version -ftemplate-depth-100 -fno-inline -o main-pt-c-ice.s
GNU C++ version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (i486-linux-gnu)
compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian
4.1.1-21).
GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=48218
Compiler executable checksum: 183d42a838ed2b7313bffcb8f2f2fda7
main-pt-c-ice.cpp: In instantiation of
'gram_treevars::expr_sequence::nodegram_treevars::defn_variable,
gram_treevars::defn_variable':
main-pt-c-ice.cpp:109: instantiated from here
main-pt-c-ice.cpp:74: internal compiler error: in instantiate_class_template,
at cp/pt.c:5652
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
Preprocessed source stored into /tmp/ccITi2V4.out file, please attach this to
your bugreport.
make: *** [bugrept] Error 1
Compilation exited abnormally with code 2 at Wed Oct 31 09:20:49
-- cut here --
--
http://gcc.gnu.org
[Bug c++/33959] [4.1/4.2/4.3 Regression] ICE in instantiate_class_template, at cp/pt.c:6649
--- Comment #3 from cppljevans at suddenlink dot net 2007-10-31 18:49
---
When that following main is used instead of the one posted earlier,
the error no longer occurs.
-- cut here --
int
main(void)
{
typedef gram_treevars gt;
gt::productions prods;
#define INST_SEQ
#ifdef INST_SEQ
gt::expr_sequence inst_seq;
#endif
prods[vars::e]=prods[vars::e]
#ifdef INST_SEQ
inst_seq
#else
prods[vars::e]
#endif
;
return 0;
}
-- cut here --
IOW, the pt.c insource comment mentioned in my first post
really means what it says, i.e. the above code instantiates
the outer class, expr_sequence, and the ice no longer occurs.
Maybe the gcc_assert that's in pt.c on line 6651
and that was mentioned in my first post should be removed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33959
[Bug c++/33959] [4.1/4.2/4.3 Regression] ICE in instantiate_class_template, at cp/pt.c:6649
--- Comment #4 from cppljevans at suddenlink dot net 2007-11-01 03:58 --- The reason version 3.4.6 doesn't have similar ice is that the corresponding check is surrounded by: #ifdef ENABLE_CHECKING ... #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33959
