From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1074 invoked by alias); 28 Jan 2003 00:46:00 -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 1059 invoked by uid 71); 28 Jan 2003 00:46:00 -0000 Date: Tue, 28 Jan 2003 00:46:00 -0000 Message-ID: <20030128004600.1058.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Wolfgang Bangerth Subject: Re: c/8268: no compile time array index checking Reply-To: Wolfgang Bangerth X-SW-Source: 2003-01/txt/msg01556.txt.bz2 List-Id: The following reply was made to PR c/8268; it has been noted by GNATS. From: Wolfgang Bangerth To: David Binderman , Cc: gcc-gnats@gcc.gnu.org Subject: Re: c/8268: no compile time array index checking Date: Mon, 27 Jan 2003 18:45:53 -0600 (CST) David, thanks for checking this out. This seems like if the patch was going in the right direction. Falk, regarding the abort, can you take a look at it? Thanks W. > I tried out the suggested patch, and it seems ok, until I run > the gcc test suite, where I get problems on test > > gcc.c-torture/execute/20010924-1.c > > as shown > > (gdb) r /tmp/1.i > Starting program: > /home/dcb/gnu/gcc321/results.check/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/cc1 > /tmp/1.i > main > Program received signal SIGSEGV, Segmentation fault. > 0x080f12d3 in get_inner_reference (exp=0x40271700, pbitsize=0xbffff1ec, > pbitpos=0xbffff1f0, poffset=0xbffff1f4, pmode=0x0, > punsignedp=0x40016c60, > pvolatilep=0xbffff1fc) at ../../src/gcc-3.2.1/gcc/expr.c:5338 > 5338 || (TREE_CODE (TYPE_MAX_VALUE (domain)) == > INTEGER_CST(gdb) list > 5333 > 5334 if (domain && TREE_CODE (index) == INTEGER_CST) > 5335 { > 5336 if ((TREE_CODE (low_bound) == INTEGER_CST > 5337 && tree_int_cst_lt(index, low_bound)) > 5338 || (TREE_CODE (TYPE_MAX_VALUE (domain)) == > INTEGER_CST5339 && tree_int_cst_lt (TYPE_MAX_VALUE > (domain), index) > 5340 /* Accesses after the end of arrays of size 0 > (gcc5341 extension) and 1 are likely > intentional. */ > 5342 && !tree_int_cst_lt (TYPE_MAX_VALUE (domain), > (gdb) > > > Further, it seems a good idea if the warning message produced could be > enhanced to give a clue about the index value and the size of the array. > > Something like > > warning: array index '10' in array 'fred' of size '5' is not valid. > > A possible second enhancement is to make sure that all six bugs in my > original demonstration case are found. The current version of the patch > only finds four of the six problems. > > The supplied patch does seem to find bugs in the gcc321 source code, > however. > > Regards > > dcb > > > ----- Original Message ----- > From: > To: ; ; ; > > Sent: Wednesday, January 08, 2003 2:40 AM > Subject: Re: c/8268: no compile time array index checking > > > > Synopsis: no compile time array index checking > > > > State-Changed-From-To: open->analyzed > > State-Changed-By: bangerth > > State-Changed-When: Tue Jan 7 18:40:02 2003 > > State-Changed-Why: > > Valid request. Falk even has a patch for that, but it > > does not seem to be in. > > > > In fact, the category should not be accepts-illegal, since > > the code is perfectly legal. It just does something > > undefined. > > > > W. > > > > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p > r=8268 > > > ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ticam.utexas.edu www: http://www.ticam.utexas.edu/~bangerth/