From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1083 invoked by alias); 14 Nov 2002 18:26:04 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 1014 invoked by uid 71); 14 Nov 2002 18:26:03 -0000 Date: Wed, 20 Nov 2002 18:12:00 -0000 Message-ID: <20021114182603.1004.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Wolfgang Wieser Subject: Re: c++/8511: (hopefully) reproducible cc1plus SIGSEGV. Reply-To: Wolfgang Wieser X-SW-Source: 2002-11/txt/msg00690.txt.bz2 List-Id: The following reply was made to PR c++/8511; it has been noted by GNATS. From: Wolfgang Wieser To: Zack Weinberg , mark@codesourcery.com Cc: Volker Reichelt , gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: c++/8511: (hopefully) reproducible cc1plus SIGSEGV. Date: Thu, 14 Nov 2002 19:17:41 +0100 On Wednesday 13 November 2002 03:29, Zack Weinberg wrote: > On Tue, Nov 12, 2002 at 10:25:10PM +0100, Wolfgang Wieser wrote: > > Ah - still: Doing abort() instead of exit(1) on ICE would make it easier > > debuggable. (Or am I wrong again? - Okay using a breakpoint...) > > Use of exit() happens to be the easiest way to prevent users from > getting 100MB core dumps (which they will then try to mail to > gcc-bugs) when ICEs happen. > Good argument. Okay, now I see. > > > We need you to give us a preprocessed source file. Using your > > > installation, issue this command: > > > > I'll provide you with preorocessed code. > > Using the file you attached, I can now reproduce the crash. It turns > out not to be a GC bug, but an access-beyond-end-of-array bug. > > [...] > > That prevents the invalid access. Your test case then carries on to > crash in c_expand_expr, which is the other bug that we already know > about, and Volker found a reduced test case for. I'm cc:ing Mark for > comments, he's a lot more familiar with this part of the compiler than > I am. I'm a bit concerned that this does not happen when unrelated > parts of the code are changed; the original data corruption could be > even earlier. > You're tough! I wish I could find bugs in a huge amount of code as good as you... But as I am not familiar with GCC code at all, I cannot comment on what you posted. But data corruption bugs are about the worst things to debug (at least in my code...) > val/internals.hpp: In function `void > internal_vect::mult_mv(internal_vect::vector&, const > internal_vect::matrix&, const internal_vect::vector&) [with int > r = 4, int c = 4, int N = 3]': > val/vector.hpp:50: instantiated from `vect::Vector > vect::operator*(const vect::Matrix&, const vect::Vector&) [with > int R = 4, int C = 4]' spline.cpp:102: instantiated from here > val/internals.hpp:84: internal compiler error: in c_expand_expr, at > c-common.c: 4319 > > If Volker's right that the code is invalid, this should be considered > a more serious case of ice-on-invalid than one where an error message > came up first. > Okay, the fact that one can extract an invalid test case does not necessarily mean that the code triggering the action is invalid. I cannot comment a lot on that because spline.cpp was written by a friend (all the other code is by me) but I have a different test case around which should be valid C++ (below). Nevertheless, I felt it as a duty to report any SIGSEGV immediately because a segmentation fault is a much more critical bug than an ordinary ICE. Okay, I just found the e-mail containing a test case triggering a bug in c_expand_expr: ----------------------------snip here--------------------------- template class A { template friend int foo(); }; A<0> a; template int foo() { return J; } void bar() { foo<0,0>(); } ----------------------------snip here--------------------------- This test case was generously provided by Volker Reichelt .. :) and can be accessed as problem report 6971 (filed by me). Volker and me agree that this is valid C++. Sorry that I cannot test if this bug is still in gcc (wrong computer here) but I am pretty sure because the last time I checked, is was still there and it is not marked "closed". I'd be pleased if you could fix that some time becuase my template code triggers this bug and I currently cannot go on implementing my design. (After all, the bug is already 6 months old.) Regards, Wolfgang Wieser