This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-2.95 19990623 64-bit PowerPC CSE bug
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: gcc-2.95 19990623 64-bit PowerPC CSE bug
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 24 Jun 1999 02:23:49 -0600
- cc: egcs-bugs at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <9906240511.AA46890@marc.watson.ibm.com>you write:
> In 64-bit mode, gcc-2.95 miscompiles the function "f" in
> gcc.c-torture/execute/divconst-2.c . Looking at the intermediate RTL
> dumps, a crucial negation is removed:
>
> -----divconst-2.c.jump-----
>
> (insn 16 14 17 (set (reg:DI 83)
> (ashiftrt:DI (reg:DI 86)
> (const_int 31 [0x1f]))) -1 (nil)
> (expr_list:REG_EQUAL (div:DI (reg/v:DI 82)
> (const_int -2147483648 [0x80000000]))
> (nil)))
>
> (insn 17 16 19 (set (reg:DI 83)
> (neg:DI (reg:DI 83))) -1 (nil)
> (expr_list:REG_EQUAL (div:DI (reg/v:DI 82)
> (const_int -2147483648 [0x80000000]))
> (nil)))
>
> (insn 19 17 20 (set (reg/i:DI 3 r3)
> (reg:DI 83)) -1 (nil)
> (nil))
>
[ ... ]
>
> Any idea what would make the backend think this transformation was
> correct?
The one thing that looks odd is insn 16 & insn 17 have identical REG_EQUAL
notes, even though the expressions that result from each insn are not
equal. This could be confusing CSE into thinking that insn 17 computes the
same value as insn 16.
jeff