From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/8582: 3.2.1 pre-release: ICE in exception handling
Date: Thu, 14 Nov 2002 09:34:25 -0600 (CST)

 Just as a caution: Whoever wants to look at this, it takes an awful lot of 
 memory. I couldn't confirm this report since my machine stopped gcc at 
 around 500 MB of memory usage...
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 

State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed.
    
    The question whether this is actually a regression or not
    is not that easy to answer:
    The preprocessed file also crashes gcc 3.2 and gcc 3.0.4
    with the same error message.
    gcc 3.1 produces a segfault (I didn't investigate that further).
    
    But since you said it's definitely a regression, I assume that the
    header files have changed. Could you please provide a preprocessed
    file that does *not* crash 3.1 for example?

From: Volker Reichelt <reichelt@igpm.rwth-aachen.de>
To: gcc-gnats@gcc.gnu.org, gawrilow@math.tu-berlin.de, gcc-bugs@gcc.gnu.org,
        nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/8582: 3.2.1 pre-release: ICE in exception handling
Date: Thu, 14 Nov 2002 23:15:57 +0100

 Here's a reduced testcase:
 
 ----------------------------snip here-------------------------------
 void* operator new(unsigned int, void*) throw();
 void operator delete (void*, void*) throw();
 
 struct A { A(); };
 
 struct B
 {
    struct X
    {
       ~X();
       operator void* () const;
    };
 
    X bar();
 };
 
 struct C
 {
    B b;
 
    C(A&) { new(b.bar()) A; }
 };
 
 void foo()
 {
    A a;
    C c(a);
 }
 ----------------------------snip here-------------------------------
 
 This one crashes gcc 3.0.x, gcc 3.1 - gcc 3.2.1:
 
 bug.cc: In constructor `C::C(A&)':
 bug.cc:21: Internal compiler error in convert_from_eh_region_ranges_1, at
    except.c:1404
 Please submit a full bug report, [etc.]
 
 However, it does not crash gcc 2.95.3 (regression!) and mainline.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8582
 
 

From: Janis Johnson <janis187@us.ibm.com>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gawrilow@math.tu-berlin.de,
   gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, jason@redhat.com
Cc:  
Subject: Re: c++/8582: [3.2 regression] ICE in exception handling
Date: Fri, 20 Dec 2002 14:50:24 -0800

 The regression reported in PR c++/8582 was fixed in the
 mainline with this patch, but still exists in the 3.2 branch:
 
 gcc (really 2002-04-04):
 
 2002-04-03  Jason Merrill  <jason@redhat.com>
 
         * except.c
         * except.h
         * expr.c
 
         PR c++/5636
         * tree.h
         * stmt.c
         * c-semantics.c
         * c-common.h
 
 gcc/cp:
 
 2002-04-04  Jason Merrill  <jason@redhat.com>
 
         * semantics.c
         * cp-tree.h
         * init.c
         * cp-tree.def
         * cp-tree.h
         * decl.c
         * dump.c
         * pt.c
         * tree.c
 
         * init.c
 
         PR c++/5636
         * semantics.c
 
         PR c++/5104
         * typeck.c
 
 Here's a small test case that causes the compiler to ICE
 when compiled on i686-linux:
 
 -------------------
 void* operator new(unsigned int, void*) throw();
 void operator delete (void*, void*) throw();
 
 struct A { A(); };
 
 struct B
 {
   struct X
   {
     ~X();
     operator void* () const;
   };
 
   X bar();
 };
 
 struct C
 {
   B b;
 
   C(A&) { new(b.bar()) A; }
 };
 
 void foo()
 {
   A a;
   C c(a);
 }
 -------------------
 
 Output from the 3.2 branch compiler:
 
 8582.C: In constructor `C::C(A&)':
 8582.C:21: Internal compiler error in convert_from_eh_region_ranges_1,
 at
    except.c:1404
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8582
 
 
 

From: Joe Buck <jbuck@synopsys.com>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, reichelt@igpm.rwth-aachen.de,
   gawrilow@math.tu-berlin.de
Cc:  
Subject: Re: c++/8582: [3.2 regression] ICE in exception handling
Date: Fri, 25 Apr 2003 12:38:00 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8582
 
 There is no ICE for the 3.3 branch, but there is an ICE in the trunk 
 (20030423)
 for the original testcase.
 
 8582.C:32616: internal compiler error: Segmentation fault
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See <URL:http://gcc.gnu.org/bugs.html> for instructions.
 
 The reduced testcase does *not* cause a crash, so evidently 3.4 has a 
 different
 bug.
 
 I will change the synopsis line to read "3.4 regression".
 

State-Changed-From-To: analyzed->closed
State-Changed-Why: The ICE in line 32616 is caused by a missing template keyword in line 32611:
    
    32602:  template <typename Top, typename Traits>
    32603:  class modified_container_pair_typebase : public manip_container_top<Top, Traits> {
    32604:     typedef manip_container_top<Top, Traits> _super;
    32605:  public:
    32606:     typedef typename deref<typename extract_type_param<Traits, Container1>::result>::exact_type container1;
    32607:     typedef typename deref<typename extract_type_param<Traits, Container2>::result>::exact_type container2;
    32608:  
    32609:     typedef typename extract_type_param<Traits, Accessor>::result accessor;
    32610:     typedef typename extract_type_param<Traits, Coupler, pair_coupler>::result coupler;
    32611:     typedef typename coupler::defs<typename container_traits<container1>::iterator,
    32612:                                    typename container_traits<container2>::iterator, void>
    32613:        coupler_defs;
    32614:     typedef typename extract_type_param<Traits, Modifier, binary_transform_modifier<> >::result modifier;
    32615:  
    32616:     typedef typename modifier::template defs<typename coupler_defs::iterator, accessor, typename _super::expected_features>
    32617:        first_try_defs;
    
    It should read "coupler::template defs" instead of just "coupler::defs".
    The new parser (rightfully) chokes on the missing template keyword, thus
    leaving "coupler_defs" undefined. This in turn causes the ICE in line 32616.
    
    The bug can be demonstrated with the following little code snippet where
    X::Y plays the role of coupler_defs::iterator
    
    ----------------------------snip here---------------------------------
    template <typename> struct A {};
    
    template <typename> struct B
    {
        typedef A<typename X::Y> C;
    };
    ----------------------------snip here---------------------------------
    
    Compiling this with mainline I get:
    
    PR8582B.cc:5: error: `X' is not a class-name or namespace-name
    PR8582B.cc:5: internal compiler error: Segmentation fault
    Please submit a full bug report, [etc.]
    
    With gcc 3.2.3 or 3.3 branch I get:
    
    PR8582B.cc:5: error: `X' is not a class or namespace
    PR8582B.cc:5: error: `Y' is not a class or namespace
    PR8582B.cc:5: error: `X' fails to be a typedef or built in type
    PR8582B.cc:5: error: ISO C++ forbids declaration of `type name' with no type
    
    So we have an ice-on-illegal-code (error recovery problem) on mainline
    which is a regression w.r.t. prior versions.
    
    
    Unfortunately that's not all. Adding the missing template in line 32616
    makes the parser ICE at a different place:
    
    There are severeral places with code like that (with X = generic_type
    and foo = operator=):
    
    -------------------------------snip here------------------------
    template <typename> struct A
    {
        typedef A X;
        void foo();
    };
    
    template <typename T> struct B : A<T>
    {
        using X::foo;
    };
    -------------------------------snip here------------------------
    
    X is declared in template class A and there's a using declaration in a
    derived class that uses X. The using declaration is illegal, it should
    of course read "using A<T>::X::foo;". Alternatively one could add a
    "using typename A<T>::X;" before (which presently does not work due to
    PR 9447).
    
    Due to incorrect name lookup the above code compiles with gcc 3.2.x and
    3.3 branch. With mainline we get an ICE:
    
    PR8582C.cc:9: error: `X' is not a class-name or namespace-name
    PR8582C.cc:9: error: expected nested-name-specifier
    PR8582C.cc:9: internal compiler error: Segmentation fault
    Please submit a full bug report, [etc.]
    
    So we have another ice-on-illegal-code (error recovery problem) on mainline
    which, however, is not a regression. The situation is actually an improvement
    on mainline, because we had an accepts-illegal before and now we only have
    an error recovery problem. But it's still a bug.
    
    
    Just out of curiosity, I ripped out all the broken using declarations
    (fixing them would not help because of PR 9447) and started the compiler
    again. The result was a new ICE caused by code like this:
    
    -------------------------------snip here------------------------
    template <typename> struct A
    {
        template <typename> struct B;
    };
    
    template <typename T> struct C
    {
        typedef typename A<T>::template B<U> X; // U is undefined
    };
    
    C<void> c;
    -------------------------------snip here------------------------
    
    PR8582D.cc:8: error: `U' has not been declared
    PR8582D.cc: In instantiation of `C<void>':
    PR8582D.cc:11:   instantiated from here
    PR8582D.cc:8: error: template argument 1 is invalid
    PR8582D.cc:8: internal compiler error: tree check: expected tree_vec, have 
       error_mark in check_instantiated_args, at cp/pt.c:8403
    Please submit a full bug report,
    
    So we have a third ice-on-illegal-code (error recovery problem).
    This one, however, affects mainline, 3.3 branch and the 3.2 branch
    (at least if configured with --enable-checking).
    
    Since this gets way out of hand for the audit trail of this PR, I close
    this PR and open three new ones.
    
    Regards,
    Volker