gcc-2.95 19990623 64-bit PowerPC CSE bug

gcc-2.95 19990623 64-bit PowerPC CSE bug

[David Edelsohn]

	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))

-----divconst-2.c.cse-----

(insn 16 14 19 (set (reg:DI 83)
        (ashiftrt:DI (reg:DI 86)
            (const_int 31 [0x1f]))) 386 {ashrdi3+1} (nil)
    (expr_list:REG_EQUAL (div:DI (reg/v:DI 82)
            (const_int -2147483648 [0x80000000]))
        (nil)))

(insn 19 16 20 (set (reg/i:DI 3 r3)
        (reg:DI 83)) 448 {*movdi_64} (nil)
    (nil))

Any idea what would make the backend think this transformation was
correct? 

Thanks, David
>From kthomas@gwdg.de Wed Jun 23 22:16:00 1999
From: kthomas@gwdg.de (Philipp Thomas)
To: law@cygnus.com, egcs-bugs@egcs.cygnus.com
Subject: Re: egcs-1.1.2: gcc seems to use direcory "ld" as linker 
Date: Wed, 23 Jun 1999 22:16:00 -0000
Message-id: <377fb24a.44902203@mailer.gwdg.de>
References: <1393.930169367@upchuck.cygnus.com> <1393.930169367@upchuck.cygnus.com>
X-SW-Source: 1999-06/msg00772.html
Content-length: 461

On Wed, 23 Jun 1999 14:22:47 -0600, Jeffrey A Law <law@cygnus.com>
wrote:

>Take "." out of your path.  Or at least put it at the end of your path.  You're
>a wonderful candidate for a trojan horse right now.

Yep, major error to do so. But isn't it still an error that egcs
doesn't check whether it's a directory it found ? Speaking of which, I
now seem to remember that a fix for this went in, no ?



Philipp

-- 
Close the windows! The penguin is freezing.
>From guinan@bluebutton.com Thu Jun 24 00:44:00 1999
From: Jamie Guinan <guinan@bluebutton.com>
To: egcs-bugs@egcs.cygnus.com
Subject: Bug Report, egcs_ss_19990623 ARM
Date: Thu, 24 Jun 1999 00:44:00 -0000
Message-id: <Pine.LNX.3.96.990624032508.22703A-101000@newt.home.net>
X-SW-Source: 1999-06/msg00773.html
Content-length: 1109

system type:        
  ARM NetWinder
bootstrap compiler:
  $ gcc-2.8.1 -v
  Reading specs from /usr/lib/gcc-lib/arm-linuxelf/2.8.1/specs
  gcc version 2.8.1
egcs version:       
  egcs_ss_19990623 (cvs)
configure options:  
  $ CC=gcc-2.8.1 ../egcs-cvs/egcs/configure \
    --prefix=$BASE --host=arm-linux  --enable-languages="c++"


I reported this bug a while ago, but since its still there
I figured I'd report it again.


$ /usr/local/egcs/egcs_ss_19990623/bin/gcc -O -g -Wall -c gtkfunc3.c

 gtkfunc3.c: In function `gtk_button_size_allocate':gtkfunc3.c:5202:
 Internal compiler error in `purge_addressof_1', at function.c:3172
 Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.See
 <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

This error occurs with optimization levels -O and -O2 but does not occur
with -O3, -O4, etc.

gtkfunc3.c (attached) is derived from GTK's gtkbutton.c, preprocessed 
and stripped down as much as I could.  Please excuse all the
junk in it, there is only one function left down at the end
that is causing function.c to abort().

-Jamie Guinan

Re: gcc-2.95 19990623 64-bit PowerPC CSE bug

[Jeffrey A Law]

  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

Re: gcc-2.95 19990623 64-bit PowerPC CSE bug

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> The one thing that looks odd is insn 16 & insn 17 have identical REG_EQUAL
Jeff> notes, even though the expressions that result from each insn are not
Jeff> equal.  This could be confusing CSE into thinking that insn 17 computes the
Jeff> same value as insn 16.

	The identical REG_EQUAL notes are in the initial .rtl file.  I do
not know this area of the compiler very well to know how these notes
decisions are made.  This feels like a miscomputation of the REG_EQUAL
information because the host is 32-bit and the target is 64-bit confusing
sign information.

David

Re: gcc-2.95 19990623 64-bit PowerPC CSE bug

[Jeffrey A Law]

  In message < 9906260236.AA27458@marc.watson.ibm.com >you write:
  > 	The identical REG_EQUAL notes are in the initial .rtl file.
Bummer.  They're usually a lot more difficult to track down when they appear
in the initial rtl dump file.

  > I do not know this area of the compiler very well to know how these notes
  > decisions are made.
Likewise.  Though I can guess they're coming from expand_divmod or one of its
subroutines.  You could probably start working forward from that routine.

jeff

Re: gcc-2.95 19990623 64-bit PowerPC CSE bug

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> Though I can guess they're coming from expand_divmod or one of its
Jeff> subroutines.  You could probably start working forward from that routine.

	What appears to be happening is expand_divmod is attaching an
ambiguous reg_note.  The calculation in question is

	x / (-0x7fffffffL - 1L)

which equals

	x / (-0x80000000L) .

Note the calculation is for a 64-bit target where long is 64-bits meaning
that the calculation is in DImode.

The divisor, d = INTVAL (op1), is a HOST_WIDE_INT.  expand_divmod() also
calculates the absolute value of the divisor, abs_d, into an unsigned
HOST_WIDE_INT.  When the TRUNC_DIV signed case creates the preliminary
instruction sequence and reg_note it performs the following:

                    /* We have computed OP0 / abs(OP1).  If OP1 is negative, negate
                       the quotient.  */
                    if (d < 0)
                      {
                        insn = get_last_insn ();
                        if (insn != last
                            && (set = single_set (insn)) != 0
                            && SET_DEST (set) == quotient)
                          set_unique_reg_note (insn,
                                               REG_EQUAL,
                                               gen_rtx_DIV (compute_mode,
                                                            op0,
                                                            GEN_INT (abs_d)));

                        quotient = expand_unop (compute_mode, neg_optab,
                                                quotient, quotient, 0);
                      }

Note that it is attaching a REG_EQUAL note of GEN_INT (abs_d).  Then at
the end of the TRUNC_DIV signed case creating the final sequence and
reg_note, the following action is performed:

                insn = get_last_insn ();
                if (insn != last
                    && (set = single_set (insn)) != 0
                    && SET_DEST (set) == quotient)
                  set_unique_reg_note (insn,
                                       REG_EQUAL,
                                       gen_rtx_DIV (compute_mode, op0, op1));

where op1 is the original signed constant divisor.  The reg_note is
represented by a CONST_INT, so the bit-pattern appearance of abs_d and d
are identical on a 32-bit host.  Attaching a REG_EQUAL reg_note is fine,
as long as the representation of the divisor and the absolute value of the
divisor are not identical, as they are in this case.

	GCC does not have an unsigned version of reg_notes and the values
implicitly are signed.  I believe that the test for attaching the second
reg_note is correct, but the test for the first reg_note needs an
additional step.  What is the correct and robust way of testing that the
signed and unsigned representations do not collide?  Schematically, the
following is necessary:

                        if (insn != last
                            && (set = single_set (insn)) != 0
                            && SET_DEST (set) == quotient
			    && d != abs_d)

Thanks, David

Re: gcc-2.95 19990623 64-bit PowerPC CSE bug

[David Edelsohn]

	I realized that the failure range is larger than I mentioned: it
is any time abs_d will not fit within a const_int.  So the additional test
should be

	&& abs_d < (1 << (HOST_BITS_PER_WIDE_INT - 1))

David