public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: reichelt@igpm.rwth-aachen.de To: gawrilow@math.tu-berlin.de, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org Subject: Re: c++/8582: [3.4 regression] ICE in exception handling Date: Tue, 29 Apr 2003 19:33:00 -0000 [thread overview] Message-ID: <20030429193336.25184.qmail@sources.redhat.com> (raw) Synopsis: [3.4 regression] ICE in exception handling State-Changed-From-To: analyzed->closed State-Changed-By: reichelt State-Changed-When: Tue Apr 29 19:33:36 2003 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 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8582
reply other threads:[~2003-04-29 19:33 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030429193336.25184.qmail@sources.redhat.com \ --to=reichelt@igpm.rwth-aachen.de \ --cc=gawrilow@math.tu-berlin.de \ --cc=gcc-bugs@gcc.gnu.org \ --cc=gcc-gnats@gcc.gnu.org \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).