% g++ -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: ../configure --cache-file=./config.cache --srcdir=/openpkg/RPM/TMP/gcc-4.1.1/obj/.. --prefix=/openpkg --exec-prefix=/openpkg --includedir=/openpkg/include/gcc --libexecdir=/openpkg/libexec/gcc --with-gxx-include-dir=/openpkg/include/g++ --with-local-prefix=/openpkg/lib/gcc --enable-languages=c,c++ --enable-threads=posix --disable-maintainer-mode --disable-shared --disable-nls --with-gnu-ld --with-ld=/openpkg/bin/ld --with-gnu-as --with-as=/openpkg/bin/as --disable-multilib Thread model: posix gcc version 4.1.1 (OpenPKG-CURRENT) % "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -fPIC -DBOOST_ALL_NO_LIB=1 -I".." -c -o "/home/cae/boost-regression/results/boost/bin.v2/libs/mpl/test/apply.test/gcc-4.1.1_sunos_i86pc/debug/debug-symbols-off/apply.o" "../libs/mpl/test/apply.cpp" ../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp: In instantiation of 'boost::mpl::aux::template_arity<T1>': ../libs/mpl/test/apply.cpp:63: instantiated from here ../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:98: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See attached apply.i.gz
Created attachment 11707 [details] PReprocessed source to boost/mpl/test/apply.cpp
Reducing.
Reduced testcase, this might be already fixed in 4.1.2 but I have not tried: template< typename T > struct type_wrapper{}; int arity_helper(...); template< template< typename P1 > class F, typename T1 > int arity_helper(type_wrapper< F<T1> >); template< typename F > struct template_arity { static const int value = sizeof(arity_helper(type_wrapper<F>() )); }; template< typename T, int t = template_arity<T>::value > struct lambda; typedef lambda< lambda<int> > t;
4.1.2 fails as well.
"4.0.3 20051105" fails by rejecting the code. Likewise for "4.1.0 20060208". But a real 4.0.3 accepts the code so this is a regression.
Program received signal SIGSEGV, Segmentation fault. 0x080f8a12 in type_dependent_expression_p (expression=0x0) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/pt.c:12518 12518 if (TREE_CODE (expression) == IDENTIFIER_NODE) #1 0x080b8640 in fold_non_dependent_expr (expr=0x0) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/pt.c:3363 #2 0x081aa65c in constant_value_1 (decl=0xb7d775d8, integral_p=1 '\001') at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/init.c:1592 #3 0x081aa93b in integral_constant_value (decl=0xb7d775d8) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/init.c:1632 #4 0x080b86ce in fold_decl_constant_value (expr=0xb7d775d8) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/pt.c:3397 #5 0x080b9281 in convert_nontype_argument (type=0xb7d7b284, expr=0xb7d775d8) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/pt.c:3544 #6 0x080bab48 in convert_template_argument (parm=0xb7d739b0, arg=0xb7d775d8, args=0xb7deb9e0, complain=tf_none, i=1, in_decl=0xb7deec98) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/pt.c:3998 #7 0x080bb077 in coerce_template_parms (parms=0xb7deb640, args=0xb7e117b0, in_decl=0xb7deec98, complain=tf_none, require_all_arguments=1) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/pt.c:4081 #2 0x081aa65c in constant_value_1 (decl=0xb7d775d8, integral_p=1 '\001') at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/init.c:1592 1592 init = fold_non_dependent_expr (DECL_INITIAL (decl)); (gdb) call debug_tree (decl) <var_decl 0xb7d775d8 value type <integer_type 0xb7e0fc94 int readonly type_6 SI size <integer_cst 0xb7d6a3f0 constant invariant 32> unit size <integer_cst 0xb7d6a180 constant invariant 4> align 32 symtab 0 alias set -1 precision 32 min <integer_cst 0xb7d6a3a8 -2147483648> max <integer_cst 0xb7d6a3c0 2147483647>> readonly constant used public static tree_2 external nonlocal decl_3 decl_6 SI file t.ii line 8 size <integer_cst 0xb7d6a3f0 32> unit size <integer_cst 0xb7d6a180 4> align 32 context <record_type 0xb7e152e0 template_arity<T1>> template-info 0xb7e14720 chain <type_decl 0xb7e13888 template_arity>> janis, can you check what fixed this on the trunk? Or what made it fail on the branch? (4.1.0 fails, too, so maybe start at the branch point).
Regression tests using the reduced testcase from comment #3 on mainline for powerpc-linux identified this patch where the test starts failing: http://gcc.gnu.org/viewcvs?view=rev&rev=103604 r103604 | mmitchel | 2005-08-29 14:08:50 +0000 (Mon, 29 Aug 2005) and this one where it starts passing again: http://gcc.gnu.org/viewcvs?view=rev&rev=110693 r110693 | mmitchel | 2006-02-07 11:11:30 +0000 (Tue, 07 Feb 2006) The regression hunts didn't use any special options and didn't ICE, but got these messages: elm3b11% /opt/gcc-nightly/trunk-20060131/bin/g++ -c 28088.cc 28088.cc: In instantiation of ‘const int template_arity<lambda<int, 4> >::value’: 28088.cc:14: instantiated from here 28088.cc:8: error: ‘template_arity<T1>::value’ is not a valid template argument for type ‘int’ because it is a non-constant expression 28088.cc:8: error: ‘template_arity<T1>::value’ is not a valid template argument for type ‘int’ because it is a non-constant expression
Unassining as pre Janis's request.
Mark, is there any way for a backport of your patch to the 4.1 branch? This appears to be a regression involving boost, and I got word from people whose codes break with 4.1.x because of this... Thanks W.
Technically, I think it would be feasible to backport the patch. However, because that patch eliminates a GNU extension we would change the set of programs accepted on the 4.1 branch. I'm not sure that's a good idea, even to fix a failure to accept conforming code. I can see arguments both ways, so I'd like to see if there's a consensus in the community and among Nathan and Jason.
Subject: Re: [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp > Technically, I think it would be feasible to backport the patch. However, > because that patch eliminates a GNU extension we would change the set of > programs accepted on the 4.1 branch. I'm not sure that's a good idea, even to > fix a failure to accept conforming code. I can see arguments both ways, so I'd > like to see if there's a consensus in the community and among Nathan and Jason. There were PRs that showed that this extension (for those who don't remember: we allowed to match templates with trailing default arguments to match template template parameters with fewer template arguments) leads to wrong code in some circumstances. It's also one of the more obscure and less well thought out extensions, in my opinion. So my view of things is that the patch should be backported. But then I'm not in charge of this, of course :-) W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@math.tamu.edu www: http://www.math.tamu.edu/~bangerth/
Subject: Re: [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp > There were PRs that showed that this extension (for those who don't > remember: we allowed to match templates with trailing default arguments to > match template template parameters with fewer template arguments) leads to > wrong code in some circumstances. It's also one of the more obscure and > less well thought out extensions, in my opinion. > > So my view of things is that the patch should be backported. But then I'm > not in charge of this, of course :-) My $.02, as a user: * This said extension was never given a period of deprecation before it was axed. * This extension is used in much existing code in practice, especially when using the STL container templates as template template arguments. (Since the Alloc param is always defaulted to std::allocator...) While I'm favor of removing extensions for the sake of standard conformance (and fixing wrong code), I think that a sudden change on the 4.1 release branch might cause some agony to those who aren't prepared to migrate to the 4.2-like behavior, in disabling the extension. The warning might even state the consequence of this extension: unexpected behavior or wrong code. Caveat emptor. I suggest adding such a diagnostic on existing release branches, to give fair warning when people are (often unknowingly) using the extension. Fortunately, it is easy to write an autoconf-macro to detect this feature, using the test case in http://gcc.gnu.org/gcc-4.2/changes.html. (and I have done so, if anyone would like it) End $.02. Fang
Subject: Re: [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp So maybe the question should be a different one: if it is difficult and/or potentially risky to backport the patch mentioned, may there be another way to fix this ice-on-valid bug on a release branch? ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@math.tamu.edu www: http://www.math.tamu.edu/~bangerth/
*** Bug 29653 has been marked as a duplicate of this bug. ***
Another testcase, this one from some other code that uses boost: template< typename T> struct has_begin {static const bool value =0;}; template<bool a> struct sequence_tag_impl{}; template< typename Sequence> struct sequence_tag : sequence_tag_impl<has_begin<Sequence>::value >{}; template<typename T>struct lambda{}; template<template< typename P1 > class F, typename T1 >struct lambda<F< T1 > >{}; template< typename Tag >struct size_impl; template<typename Tag, long Arity = size_impl< typename sequence_tag<Tag>::type >::value> struct basic_expr{}; int main() { lambda<basic_expr<short, 2> > a; }
*** Bug 32104 has been marked as a duplicate of this bug. ***
Closing 4.1 branch.