Re: c++/8511: (hopefully) reproducible cc1plus SIGSEGV.

[Wolfgang Wieser <wwieser@gmx.de>]

The following reply was made to PR c++/8511; it has been noted by GNATS.

From: Wolfgang Wieser <wwieser@gmx.de>
To: Zack Weinberg <zack@codesourcery.com>,
 mark@codesourcery.com
Cc: Volker Reichelt <reichelt@igpm.rwth-aachen.de>,
 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<n>&, const
 >    internal_vect::matrix<r, c>&, const internal_vect::vector<c>&) [with int
 > r = 4, int c = 4, int N = 3]':
 > val/vector.hpp:50:   instantiated from `vect::Vector<N>
 > vect::operator*(const vect::Matrix<R, C>&, const vect::Vector<C>&) [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<int N> class A
 {
     template<int I,int J> friend int foo();
 };
 
 A<0> a;
 
 template<int I,int J> 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