Your message dated Wed, 2 May 2001 19:18:23 -0400 with message-id <[EMAIL PROTECTED]> and subject line Bug#96099: gcc bug(s) has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Darren Benham (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 2 May 2001 18:49:48 +0000 >From [EMAIL PROTECTED] Wed May 02 13:49:48 2001 Return-path: <[EMAIL PROTECTED]> Received: from c301573-a.grdjctn1.co.home.com (deadreckon.somerset-financial.com) [24.181.191.248] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 14v1h5-0003rB-00; Wed, 02 May 2001 13:49:47 -0500 Received: from somerset-financial.com (deadreckon.somerset-financial.com [146.145.51.14]) by deadreckon.somerset-financial.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f42IluEL006671 for <[EMAIL PROTECTED]>; Wed, 2 May 2001 12:47:56 -0600 Message-Id: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: gcc bug(s) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <[EMAIL PROTECTED]> Date: Wed, 02 May 2001 12:47:56 -0600 Sender: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] package: gcc version: 2.95.4-0.01042 running on intel based system (old pentium 133Mhz) first dpkg --list | grep gcc yeilds ii gcc 2.95.3-7 The GNU C compiler. ii gcc-2.95 2.95.4-0.01042 The GNU C compiler. I'm not 100% sure why my system thinks both "gcc" and "gcc-2.95" are installed. Suggestions on how to fix this would be appreciated. I upgraded from a "stable" debian release to "testing" a month or so ago. The command gcc --version yields gcc version 2.95.4 20010319 (Debian prerelease) so I really think "gcc-2.95" is installed but I'll do any other verification needed. >From a really bad piece of code I was looking at that had a bug in the code, leads me to believe there is also a compiler bug. { int arr[10][10], x, y; for (x = 0; x < 10; x++) { for (y = 0; y < 10; y++) { arr[x][y] = ((x = y) ? 1 : 0); printf("%d\n", arr[x][y]); } } } Don't ask where the code comes from, its not mine. The bug in the code is the "(x = y)" was susppose to be "(x == y)". But theoretically with the bug still in place I would expect arr[0][0], arr[1][1], ..., arr[9][9] to be the only elements filled in and arr[0][0] will contain 0 and the other arr[i][i] would contain 1. I tossed in the printf() to show what is happenning. compiled with "gcc T.c -o T" the output is 0 179931522 -1073745196 1073914572 126767887 1073833580 0 1073833240 1074870958 -1073744904 (the "funky numbers" are just values on the stack that are in the positions for arr[i][i]) where I would have expected 0 1 1 1 1 1 1 1 1 1 Just for giggles, if one changes arr[10][10], to arr[10][10] = { { 10 } }, the output is 0 0 0 0 0 0 0 0 0 0 which enforces my suspecition that for i > 0 arr[i][i] is _NOT_ being written/stored to. Its unclear whether arr[0][0] is being stored or not from the above output. I recompiled as "gcc -g3 T.c -o T" and the output remains consistent but here's the assembly language statements if that helps. I'm really not up on my x86 assembly anymore so I won't make any comments on it. 0x8048828 <t33>: push %ebp 0x8048829 <t33+1>: mov %esp,%ebp 0x804882b <t33+3>: sub $0x1a4,%esp 0x8048831 <t33+9>: push %ebx 0x8048832 <t33+10>: nop 0x8048833 <t33+11>: movl $0x0,0xfffffe6c(%ebp) 0x804883d <t33+21>: lea 0x0(%esi),%esi 0x8048840 <t33+24>: cmpl $0x9,0xfffffe6c(%ebp) 0x8048847 <t33+31>: jle 0x8048850 <t33+40> 0x8048849 <t33+33>: jmp 0x8048910 <t33+232> 0x804884e <t33+38>: mov %esi,%esi 0x8048850 <t33+40>: movl $0x0,0xfffffe68(%ebp) 0x804885a <t33+50>: lea 0x0(%esi),%esi 0x8048860 <t33+56>: cmpl $0x9,0xfffffe68(%ebp) 0x8048867 <t33+63>: jle 0x8048870 <t33+72> 0x8048869 <t33+65>: jmp 0x8048900 <t33+216> 0x804886e <t33+70>: mov %esi,%esi 0x8048870 <t33+72>: mov 0xfffffe68(%ebp),%eax 0x8048876 <t33+78>: mov %eax,%edx 0x8048878 <t33+80>: lea 0x0(,%edx,4),%eax 0x804887f <t33+87>: mov 0xfffffe6c(%ebp),%ecx 0x8048885 <t33+93>: mov %ecx,%edx 0x8048887 <t33+95>: shl $0x2,%edx 0x804888a <t33+98>: add %ecx,%edx 0x804888c <t33+100>: lea 0x0(,%edx,8),%ecx 0x8048893 <t33+107>: add %ecx,%eax 0x8048895 <t33+109>: lea 0xfffffe70(%ebp),%edx 0x804889b <t33+115>: mov 0xfffffe68(%ebp),%ecx 0x80488a1 <t33+121>: mov %ecx,0xfffffe6c(%ebp) 0x80488a7 <t33+127>: test %ecx,%ecx 0x80488a9 <t33+129>: setne %cl 0x80488ac <t33+132>: movzbl %cl,%ebx 0x80488af <t33+135>: mov %ebx,(%eax,%edx,1) 0x80488b2 <t33+138>: add $0xfffffff8,%esp 0x80488b5 <t33+141>: mov 0xfffffe68(%ebp),%eax 0x80488bb <t33+147>: mov %eax,%edx 0x80488bd <t33+149>: lea 0x0(,%edx,4),%eax 0x80488c4 <t33+156>: mov 0xfffffe6c(%ebp),%ecx 0x80488ca <t33+162>: mov %ecx,%edx 0x80488cc <t33+164>: shl $0x2,%edx 0x80488cf <t33+167>: add %ecx,%edx 0x80488d1 <t33+169>: lea 0x0(,%edx,8),%ecx 0x80488d8 <t33+176>: add %ecx,%eax 0x80488da <t33+178>: lea 0xfffffe70(%ebp),%edx 0x80488e0 <t33+184>: mov (%eax,%edx,1),%eax 0x80488e3 <t33+187>: push %eax 0x80488e4 <t33+188>: push $0x80489d4 0x80488e9 <t33+193>: call 0x8048434 <printf> 0x80488ee <t33+198>: add $0x10,%esp 0x80488f1 <t33+201>: incl 0xfffffe68(%ebp) 0x80488f7 <t33+207>: jmp 0x8048860 <t33+56> 0x80488fc <t33+212>: lea 0x0(%esi,1),%esi 0x8048900 <t33+216>: incl 0xfffffe6c(%ebp) 0x8048906 <t33+222>: jmp 0x8048840 <t33+24> 0x804890b <t33+227>: nop 0x804890c <t33+228>: lea 0x0(%esi,1),%esi 0x8048910 <t33+232>: add $0xfffffff8,%esp 0x8048913 <t33+235>: mov 0xfffffe9c(%ebp),%eax 0x8048919 <t33+241>: push %eax 0x804891a <t33+242>: push $0x80489d4 0x804891f <t33+247>: call 0x8048434 <printf> 0x8048924 <t33+252>: add $0x10,%esp 0x8048927 <t33+255>: mov 0xfffffe58(%ebp),%ebx 0x804892d <t33+261>: leave 0x804892e <t33+262>: ret 0x804892f <t33+263>: nop Have fun. If you need anymore information, please feel free to email. --------------------------------------- Received: (at 96099-done) by bugs.debian.org; 2 May 2001 23:18:40 +0000 >From [EMAIL PROTECTED] Wed May 02 18:18:40 2001 Return-path: <[EMAIL PROTECTED]> Received: from nevyn.res.cmu.edu (nevyn.them.org) [128.2.145.225] (mail) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 14v5tH-0000iv-00; Wed, 02 May 2001 18:18:39 -0500 Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 14v5t1-0004w4-00; Wed, 02 May 2001 19:18:23 -0400 Date: Wed, 2 May 2001 19:18:23 -0400 From: Daniel Jacobowitz <[EMAIL PROTECTED]> To: David Starner <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Bug#96099: gcc bug(s) Message-ID: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Wed, May 02, 2001 at 04:29:26PM -0500 Delivered-To: [EMAIL PROTECTED] On Wed, May 02, 2001 at 04:29:26PM -0500, David Starner wrote: > On Wed, May 02, 2001 at 12:47:56PM -0600, [EMAIL PROTECTED] wrote: > When I first looked at your code, I thought that you were wrong, > because x gets set to y, then y gets incremented, then arr[x][y] > is chosen. Then I realized that that's not right, and there is no > specified answer. You're modifying x and y in the same line where > you use x and y. That's nasal demon area, and the compiler can do > whatever it wants on this code and still be standards complaint. > > I don't think I can close bug, since I'm not one of the gcc > maintainers. But it's definetly closable. Thanks. You're quite right. -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team