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

Bug#608550: marked as done (gcc-4.3-mips-linux-gnu: gcc produces incorrect assembler for a/b - it doesn't do anything.)



Your message dated Sat, 1 Jan 2011 14:27:43 +0100
with message-id <20110101132743.GK3615@hall.aurel32.net>
and subject line Re: Bug#608550: gcc-4.3-mips-linux-gnu: gcc produces incorrect assembler for a/b - it doesn't do anything.
has caused the Debian Bug report #608550,
regarding gcc-4.3-mips-linux-gnu: gcc produces incorrect assembler for a/b - it doesn't do anything.
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
608550: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608550
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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



--- End Message ---
--- Begin Message ---
On Sat, Jan 01, 2011 at 12:45:49PM +0100, Peter T. Breuer wrote:
> Package: gcc-4.3-mips-linux-gnu

Where this package comes from? It is not in the debian archive.

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

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

  In short a division by 0 will trap.

* if v1 is different than 0, the following sequence is executed:
  bne     $3,$0,1f
  div     $0,$2,$3
  mflo    $2
 
  The quotient now in v0.

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

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


--- End Message ---

Reply to: