[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#608550: closed by Aurelien Jarno <aurelien@aurel32.net> (Re:



Hi ... (disagree, for flaw in reasoning about bne).

"Also sprach Debian Bug Tracking System:"
> > With compile options
> > 
> >     -O0 -static -DMIPS -mips1 -mabi=32 -msoft-float -mno-memcpy
> > 
> > gcc produces incorrect code for division (and I suppose, %) from C.
> > 
> > Test code can be simply:
> > 
> >     
> > main() {
> >     int a,b,c;
> >     c = a/b;
> > }
> > 
> > compile to assembler with above flags. Read, or compile to object code
> > and disassemble. The eyes-on read shows:
> > 
> >         bne     $3,$0,1f           #!!! ergh! Should be beq
> >         div     $0,$2,$3
> >         break   7
> > 1:
> >         mflo    $2
> > 
> > The divide is protected by a "branch around the divide if the denominator
> > is NOT equal to zero". It should be "IS equal to zero". 
> 
> I strongly disagree, the code is correct:
> 
> * if v1 is equal to 0, the following sequence is executed:
>   bne     $3,$0,1f
>   div     $0,$2,$3
>   break   7

Yes. The branch fails, and falls through to the division, which (fails
and) traps in the break following.

> 
>   In short a division by 0 will trap.

Amen.

> * if v1 is different than 0, the following sequence is executed:
>   bne     $3,$0,1f

OK.

>   div     $0,$2,$3

Uh uh.

Why do you think so? The branch IS taken, and jumps forward. OK .. so 
that depends on whatever "1f" means in this dialect. I interpreted it
as "jump _forward_ to the label '1' which precedes the following mflo).
I can see no other reasonable interpretation ("1f" as hex would not be
divisible by 4), and the machine code bears me out.  I quoted it
earlier, and here it is again (obtained via objdump of the .o code):

   (main)
    1c:   14600002        bnez    v1,28 <main+0x28> (File Offset: 0x68)
    20:   0043001a        div     zero,v0,v1
    24:   0007000d        break   0x7
    28:   00001012        mflo    v0

The branch is to the mflo following the break.

So, I cannot agree.


>   mflo    $2
>  
>   The quotient now in v0.

Ufortunately, the conclusion is invalidated by the earlier step.

> 
> As the generated code is correct, I am closing the bug.

But unfortunately it does not appear to be correct, so you are NOT
perhaps closing the bug :-).

Regards

> -- 
> Aurelien Jarno	                        GPG: 1024D/F1BCDB73
> aurelien@aurel32.net                 http://www.aurel32.net
> 
> 
> ------------=_1293889881-27189-1
> Content-Type: message/rfc822
> Content-Disposition: inline
> Content-Transfer-Encoding: 7bit
> 
> Received: (at submit) by bugs.debian.org; 1 Jan 2011 12:00:07 +0000
> X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02
> 	(2008-06-10) on busoni.debian.org
> X-Spam-Level: 
> X-Spam-Bayes: score:0.0000 Tokens: new, 35; hammy, 148; neutral, 189; spammy,
> 	3. spammytokens:1.000-1--excise, 0.997-1--peephole, 0.993-1--eyeson
> 	hammytokens:0.000-+--H*M:reportbug, 0.000-+--H*MI:reportbug,
> 	0.000-+--H*x:reportbug, 0.000-+--H*UA:reportbug, 0.000-+--H*x:4.12.6
> X-Spam-Status: No, score=-8.2 required=4.0 tests=AWL,BAYES_00,FOURLA,
> 	HAS_PACKAGE,MONEY,MURPHY_DRUGS_REL8,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_NONE,
> 	SPF_SOFTFAIL,STOCKLIKE,XMAILER_REPORTBUG autolearn=ham
> 	version=3.2.5-bugs.debian.org_2005_01_02
> Return-path: <ptb@inv.it.uc3m.es>
> Received: from [85.48.160.4] (helo=barney.it.uc3m.es)
> 	by busoni.debian.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
> 	(Exim 4.69)
> 	(envelope-from <ptb@inv.it.uc3m.es>)
> 	id 1PZ07y-0000cq-8a
> 	for submit@bugs.debian.org; Sat, 01 Jan 2011 12:00:06 +0000
> Received: (from ptb@localhost)
> 	by barney.it.uc3m.es (8.14.4/8.14.4/Submit) id p01Bjngq029823;
> 	Sat, 1 Jan 2011 12:45:49 +0100
> X-Authentication-Warning: barney.it.uc3m.es: ptb set sender to ptb@inv.it.uc3m.es using -f
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> From: "Peter T. Breuer" <ptb@inv.it.uc3m.es>
> To: Debian Bug Tracking System <submit@bugs.debian.org>
> Subject: gcc-4.3-mips-linux-gnu: gcc produces incorrect assembler for a/b - it
>  doesn't do anything.
> Message-ID: <20110101114549.29139.5081.reportbug@barney.it.uc3m.es>
> X-Mailer: reportbug 4.12.6
> Date: Sat, 01 Jan 2011 12:45:49 +0100
> X-Greylist: delayed 847 seconds by postgrey-1.31 at busoni; Sat, 01 Jan 2011 12:00:06 UTC
> Delivered-To: submit@bugs.debian.org
> 
> Package: gcc-4.3-mips-linux-gnu
> Version: 4.3.5-4
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
> 
> 
> With compile options
> 
>     -O0 -static -DMIPS -mips1 -mabi=32 -msoft-float -mno-memcpy
> 
> gcc produces incorrect code for division (and I suppose, %) from C.
> 
> Test code can be simply:
> 
>     
> main() {
>     int a,b,c;
>     c = a/b;
> }
> 
> compile to assembler with above flags. Read, or compile to object code
> and disassemble. The eyes-on read shows:
> 
>         bne     $3,$0,1f           #!!! ergh! Should be beq
>         div     $0,$2,$3
>         break   7
> 1:
>         mflo    $2
> 
> The divide is protected by a "branch around the divide if the denominator
> is NOT equal to zero". It should be "IS equal to zero". 
> 
> Checking the disassembly of the object code shows:
> 
>   1c:   14600002        bnez    v1,28 <main+0x28> (File Offset: 0x68)
>   20:   0043001a        div     zero,v0,v1
>   24:   0007000d        break   0x7
>   28:   00001012        mflo    v0
> 
> which is as indicated by the assembler source.
> 
> No, the problem does not go away if the result from the division
> is used in the source code. I haven't tested with optimization but
> I see no reason to suppose that peephole optimization filters
> after the generation will patch this up (except where they excise it).
> 
> 
> 
> 
> -- System Information:
> LSB Version:	core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:cxx-3.0-ia32:cxx-3.0-noarch:cxx-3.1-ia32:cxx-3.1-noarch:cxx-3.2-ia32:cxx-3.2-noarch:desktop-3.1-ia32:desktop-3.1-noarch:desktop-3.2-ia32:desktop-3.2-noarch:graphics-2.0-ia32:graphics-2.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:graphics-3.1-ia32:graphics-3.1-noarch:graphics-3.2-ia32:graphics-3.2-noarch:languages-3.2-ia32:languages-3.2-noarch:multimedia-3.2-ia32:multimedia-3.2-noarch:printing-3.2-ia32:printing-3.2-noarch:qt4-3.1-ia32:qt4-3.1-noarch
> Distributor ID:	Ubuntu NO It's NOT! SOmebody please tell me where that is!
> Description:	Ubuntu 8.04.1 NYAAAA! No it's not. This is Debian Unstable.
> Release:	8.04 Nix.
> Codename:	hardyArchitecture: i386 (i686) Nonsense. Where that come from?
> 
> Kernel: Linux 2.6.31.2-SMP (SMP w/1 CPU core; PREEMPT)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages gcc-4.3-mips-linux-gnu depends on:
> ii  binutils-mips-linux-gnu       2.20.1-15  The GNU binary utilities, for mips
> ii  cpp-4.3-mips-linux-gnu        4.3.5-4    The GNU C preprocessor
> ii  gcc-4.3-mips-linux-gnu-base   4.3.5-4    The GNU Compiler Collection (base 
> ii  libc6                         2.11.2-7   Embedded GNU C Library: Shared lib
> ii  libgcc1-mips-cross            1:4.4.5-10 GCC support library (for cross-com
> ii  libgomp1                      4.4.5-10   GCC OpenMP (GOMP) support library
> 
> Versions of packages gcc-4.3-mips-linux-gnu recommends:
> ii  libc6-dev-mips-cross          2.11.2-2   Embedded GNU C Library: Developmen
> 
> Versions of packages gcc-4.3-mips-linux-gnu suggests:
> pn  gcc-4.3-doc                   <none>     (no description available)
> pn  gcc-4.3-locales               <none>     (no description available)
> pn  gcc-4.3-multilib-mips-linux-g <none>     (no description available)
> pn  libgcc1-dbg-mips-cross        <none>     (no description available)
> pn  libgomp1-dbg-mips-cross       <none>     (no description available)
> pn  libmudflap0-4.3-dev-mips-cros <none>     (no description available)
> pn  libmudflap0-dbg-mips-cross    <none>     (no description available)
> 
> -- no debconf information
> 
> 
> 
> ------------=_1293889881-27189-1--
> 




Reply to: