FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian GCC

 
 
LinkBack Thread Tools
 
Old 01-01-2011, 01:34 PM
"Peter T. Breuer"
 
Default Bug#608550: closed by Aurelien Jarno (

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,RC VD_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.0HE_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.uc3 m.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-noarchrinting-3.2-ia32rinting-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--
>




--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201101011434.p01EY2sF014029@nbd.it.uc3m.es">http://lists.debian.org/201101011434.p01EY2sF014029@nbd.it.uc3m.es
 
Old 01-01-2011, 02:07 PM
Julien BLACHE
 
Default Bug#608550: closed by Aurelien Jarno (

"Peter T. Breuer" <ptb@inv.it.uc3m.es> wrote:

Hi,

>> * 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.

I think you're getting confused by the delay slot. If you take the delay
slot into account, you'll see that the code and Aurélien are both
correct.

JB.

--
Julien BLACHE - Debian & GNU/Linux Developer - <jblache@debian.org>

Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 871v4wy85g.fsf@sonic.technologeek.org">http://lists.debian.org/871v4wy85g.fsf@sonic.technologeek.org
 
Old 01-01-2011, 02:11 PM
Aurelien Jarno
 
Default Bug#608550: closed by Aurelien Jarno (

On Sat, Jan 01, 2011 at 03:34:02PM +0100, Peter T. Breuer wrote:
> 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):

Because MIPS uses delay slots. It's one of the basic you should know
before looking at MIPS assembly code.

--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110101151132.GN3615@hall.aurel32.net">http://lists.debian.org/20110101151132.GN3615@hall.aurel32.net
 

Thread Tools




All times are GMT. The time now is 09:16 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org