Bug 28088 - [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp
Summary: [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.1.1
: P2 normal
Target Milestone: 4.2.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
: 29653 32104 (view as bug list)
Depends on: cwg150
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-19 21:04 UTC by Caleb Epstein
Modified: 2008-07-04 15:36 UTC (History)
11 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.2.0 4.0.3
Known to fail: 4.1.1 4.1.2 4.1.3
Last reconfirmed: 2006-07-05 20:35:23


Attachments
PReprocessed source to boost/mpl/test/apply.cpp (88.84 KB, application/octet-stream)
2006-06-19 21:05 UTC, Caleb Epstein
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Caleb Epstein 2006-06-19 21:04:49 UTC
% 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
Comment 1 Caleb Epstein 2006-06-19 21:05:37 UTC
Created attachment 11707 [details]
PReprocessed source to boost/mpl/test/apply.cpp
Comment 2 Andrew Pinski 2006-06-19 22:10:00 UTC
Reducing.
Comment 3 Andrew Pinski 2006-06-19 23:37:38 UTC
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;
Comment 4 Mark Loeser 2006-06-21 04:05:03 UTC
4.1.2 fails as well.
Comment 5 Andrew Pinski 2006-06-21 04:21:48 UTC
"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.
Comment 6 Richard Biener 2006-07-05 14:23:06 UTC
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).
Comment 7 Janis Johnson 2006-07-05 20:35:23 UTC
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
Comment 8 Andrew Pinski 2006-08-04 16:57:40 UTC
Unassining as pre Janis's request.
Comment 9 Wolfgang Bangerth 2006-10-21 04:28:37 UTC
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.
Comment 10 Mark Mitchell 2006-10-22 04:59:34 UTC
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.
Comment 11 bangerth@math.tamu.edu 2006-10-23 03:18:03 UTC
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/

Comment 12 David Fang 2006-10-23 03:34:49 UTC
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

Comment 13 bangerth@math.tamu.edu 2006-10-23 04:01:49 UTC
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/

Comment 14 Andrew Pinski 2006-11-08 09:49:00 UTC
*** Bug 29653 has been marked as a duplicate of this bug. ***
Comment 15 Andrew Pinski 2006-11-08 09:51:03 UTC
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;
}

Comment 16 Richard Biener 2007-05-27 19:30:38 UTC
*** Bug 32104 has been marked as a duplicate of this bug. ***
Comment 17 Joseph S. Myers 2008-07-04 15:36:58 UTC
Closing 4.1 branch.