Compiling of the attached program terminates with altshuler_det.cc:55753: Internal compiler error in convert_from_eh_region_ranges_1, at except.c:1404 Unfortunately, the source is terribly long. The first naive tries to reduce it made the error disappear, so I decided to submit it as is; probably you'll manage to localize the bug nevertheless. If not, let me know, please, then I'll make a more resolute try. At any rate, this source could be successfully compiled by 3.0 and 3.1 gcc series. Thus it is a clear regression case. Release: gcc version 3.2.1 20021114 (prerelease) Environment: RedHat 7.3 on AMD Athlon PC; binutils-2.13 gcc retrieved with 'cvs co -r gcc-3_2-branch gcc' How-To-Repeat: Just compile it: g++ -c altshuler_det.cc
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