🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.gcc.bug
Article #6088

(no subject given!)

#6088
From: news
Date: Fri, 20 Dec 1996 00:00
78 lines
2850 bytes
Newsgroups: gnu.gcc.bug
Path: kkojima
From: kkojima@kk.info.kanagawa-u.ac.jp (Kazumoto Kojima)
Subject: 32-bit host/64-bit target problem
Message-ID: <KKOJIMA.96Dec20160916@mermaid.kk.info.kanagawa-u.ac.jp>
Followup-To: gnu.gcc.bug
Lines: 66
Sender: news@educ.info.kanagawa-u.ac.jp
Organization: Faculty of Science , Kanagawa Univ., Kanagawa, Japan.
Distribution: gnu.gcc
Date: Fri, 20 Dec 1996 07:09:16 GMT

Hi,
I met 2 bugs in optimization routines for 32-bit host/64-bit target.
These may be reported already.

gcc version: 2.7.2
Host configuratuin: mips-p40-bsd (unofficial but for mips using a.out)
Target configuration: mips-gnu (mips using ELF)
gcc option: -O -mips3 -mint64 -S

(1) The line

	(bar == 2)? 3: 2

(where bar is unsigend int) is compiled as:

        ld      $2,bar
        #nop
        xori    $2,$2,0x0002
        sltu    $2,$2,1
        dsll    $2,$2,32
        dsra    $2,$2,32
        dsll    $2,$2,32
        dsrl    $2,$2,32
        dsubu   $2,$0,$2
        dli     $3,0xffffffff00000003
        and     $2,$2,$3

(Shift instructions are not required but not wrong.) 
The last 2 lines are wrong.  I think this comes from combine.c line 6536:

  if (pos < 0 || pos + len > GET_MODE_BITSIZE (GET_MODE (dest))
      || (GET_MODE_BITSIZE (GET_MODE (other)) <= HOST_BITS_PER_WIDE_INT
          && (c1 & nonzero_bits (other, GET_MODE (other))) != 0))
    return x;

and the condition
	 (GET_MODE_BITSIZE (GET_MODE (other)) <= HOST_BITS_PER_WIDE_INT
          && (c1 & nonzero_bits (other, GET_MODE (other))) != 0)
looks like a reverse testing.

(2) The second one may be more general. The lines

	bar = 0xc00000ff00000000;
	bar - (unsigned) 0x80000000

are compiled as:

        dli     $3,0xc00000ff00000000
        sd      $3,bar
        dli     $2,-2147483648                  # 0x80000000
        dsubu   $2,$3,$2

The result should be 0xc00000fe80000000 but one gets the wrong result
0xc00000ff80000000.
In gcc optimizataion, there are some codes which handle 0x80000000
as const_int and also handles -0x80000000 as so. I think these generate
the bugs like above.
I adds the tests like !(INTVAL (x) && INTVAL (x) == - INTVAL (x)) to some
files for optimizations to avoid this problem, though there must be more
smart solutions.

	kaz
_____
Kazumoto Kojima
kkojima@info.kanagawa-u.ac.jp
Technical Details
Message-ID: <9612200710.AA10556@heather.educ.info.kanagawa-u.ac.jp>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 113d02,e6002ebe0e0b5216,start
X-Google-Attributes: gid113d02,public
From: news@educ.info.kanagawa-u.ac.jp
Subject: (no subject given!)
Date: 1996/12/20
Message-ID: <9612200710.AA10556@heather.educ.info.kanagawa-u.ac.jp>
X-Deja-AN: 205047525
sender: bug-gcc-request@prep.ai.mit.edu
x-gateway: relay3.UU.NET from bug-gcc to gnu.gcc.bug; Fri, 20 Dec 1996 02:11:14 EST
newsgroups: gnu.gcc.bug