[Bug tree-optimization/20134] New: 176.gcc miscompare with -m64 after DOM change

[Bug tree-optimization/20134] New: 176.gcc miscompare with -m64 after DOM change

[janis at gcc dot gnu dot org]

The SPEC CPU2000 test 176.gcc has been failing on powerpc64-*-linux-gnu
with "-m64 -O1" since this patch was added:
                                                                               
                
2004-10-23  Daniel Berlin  <dberlin@dberlin.org>
                                                                               
                
        * tree-ssa-dom.c (record_equality): Use loop depth to determine
        which way to record the equality as well.
        (loop_depth_of_name): New function.
                                                                               
                
The failure goes away if the patch is reverted from mainline sources.
                                                                               
                
The miscompare is due to function exact_log2_wide from toplev.c in
176.gcc, which returns 63 instead of 31 for the value -2147483648.
I'll attach a testcase with that function.

-- 
           Summary: 176.gcc miscompare with -m64 after DOM change
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: janis at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134

[Bug tree-optimization/20134] 176.gcc miscompare with -m64 after DOM change

[janis at gcc dot gnu dot org]

------- Additional Comments From janis at gcc dot gnu dot org  2005-02-22 00:13 -------
Created an attachment (id=8249)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8249&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134

Re: [Bug tree-optimization/20134] New: 176.gcc miscompare with -m64 after DOM change

[Daniel Berlin]

On Tue, 2005-02-22 at 00:12 +0000, janis at gcc dot gnu dot org wrote:
> The SPEC CPU2000 test 176.gcc has been failing on powerpc64-*-linux-gnu
> with "-m64 -O1" since this patch was added:
>                                                                                
>                 
> 2004-10-23  Daniel Berlin  <dberlin@dberlin.org>
>                                                                                
>                 
>         * tree-ssa-dom.c (record_equality): Use loop depth to determine
>         which way to record the equality as well.
>         (loop_depth_of_name): New function.
>                                                    

This can't be the real cause of the problem, however, it must just be
exposing the latent bug.
It just changes the direction we record the equality, so that we will
use one variable instead of another.
The code still believes both variables to be equal.
In other words, there is something in record_equality that isn't
correct, or some pass later on is now doing something wrong as a result.

Can you print out the values of x, y, and prev_x we are passing to
record_const_or_copy_1 in record_equality before and after the patch,
for that function?

[Bug tree-optimization/20134] 176.gcc miscompare with -m64 after DOM change

[dberlin at dberlin dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-02-22 00:19 -------
Subject: Re:  New: 176.gcc miscompare with
	-m64 after DOM change

On Tue, 2005-02-22 at 00:12 +0000, janis at gcc dot gnu dot org wrote:
> The SPEC CPU2000 test 176.gcc has been failing on powerpc64-*-linux-gnu
> with "-m64 -O1" since this patch was added:
>                                                                                
>                 
> 2004-10-23  Daniel Berlin  <dberlin@dberlin.org>
>                                                                                
>                 
>         * tree-ssa-dom.c (record_equality): Use loop depth to determine
>         which way to record the equality as well.
>         (loop_depth_of_name): New function.
>                                                    

This can't be the real cause of the problem, however, it must just be
exposing the latent bug.
It just changes the direction we record the equality, so that we will
use one variable instead of another.
The code still believes both variables to be equal.
In other words, there is something in record_equality that isn't
correct, or some pass later on is now doing something wrong as a result.

Can you print out the values of x, y, and prev_x we are passing to
record_const_or_copy_1 in record_equality before and after the patch,
for that function?





-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134

[Bug tree-optimization/20134] [4.0 Regression] 176.gcc miscompare with -m64 after DOM change

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
           Keywords|                            |wrong-code
            Summary|176.gcc miscompare with -m64|[4.0 Regression] 176.gcc
                   |after DOM change            |miscompare with -m64 after
                   |                            |DOM change
   Target Milestone|---                         |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134

[Bug rtl-optimization/20134] [4.0 Regression] 176.gcc miscompare with -m64 after DOM change

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-22 00:48 -------
This looks like a RTL bug, the 32bit and the 64 bit tree dumps are the same.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |rtl-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134

[Bug tree-optimization/20134] [4.0 Regression] 176.gcc miscompare with -m64 after DOM change

[janis at gcc dot gnu dot org]

------- Additional Comments From janis at gcc dot gnu dot org  2005-02-22 00:54 -------
I'm recovering from a cold and am fading fast, I'll get more information
tomorrow.  Another piece of information, though, is that the testcase
works if the modified test in record_equality also includes
"&& (loop_depth_of_name (y) != 0)".  (That's meant to be a clue, not a fix.)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|rtl-optimization            |tree-optimization
   Target Milestone|4.0.0                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134

[Bug rtl-optimization/20134] [4.0 Regression] 176.gcc miscompare with -m64 after DOM change

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-22 00:55 -------
Does this testcase fail for you if so can you run a regression hunter on it for the real patch:
/* This function gets the wrong answer (63 instead of 31) when compiled
   with "-m64 -O1" on powerpc64-linux.  */

extern void abort (void);

/* From 176.gcc in SPEC CPU2000.  */
int
exact_log2_wide (x)
     register unsigned int x;
{
  unsigned int x4;
  register int log;
  if (x == 0) goto L6; else goto L0;
L0:;
  if (x != (x & -x)) goto L6; else goto L8;
L17:;
  log = 0;
L3:;
  log = log + 1;
  x4 = x4 >> 1;
  if (x4 != 0) goto L3; else goto L18;
L6:;
  log = -1;
L18:;
  return log;
L8:;
  x4 = x >> 1;
  if (x4 != 0) goto L17; else goto L19;
L19:;
  log = 0;
  goto L18;
}

int
main ()
{
    if (exact_log2_wide ((int) -2147483648) != 31)
	abort ();
    return 0;
}

Please use -O1 -fno-tree-dominator-opts as we know this is the most optimial code anyways.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |rtl-optimization
   Target Milestone|---                         |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134

[Bug rtl-optimization/20134] [4.0 Regression] 176.gcc miscompare with -m64 after DOM change

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-22 01:15 -------
Ok, I see what is going on now.
This is a RTL optimization bug.
The following (in .combine) is being combined:
(insn 37 35 38 4 (set (reg:SI 131)
        (lshiftrt:SI (subreg/s/u:SI (reg/v:DI 122 [ x.4 ]) 4)
            (const_int 1 [0x1]))) -1 (nil)
    (expr_list:REG_DEAD (reg/v:DI 122 [ x.4 ])
        (nil)))

(insn 38 37 39 4 (set (reg/v:DI 122 [ x.4 ])
        (zero_extend:DI (reg:SI 131))) -1 (insn_list:REG_DEP_TRUE 37 (nil))
    (expr_list:REG_DEAD (reg:SI 131)
        (nil)))

(insn 39 38 40 4 (set (reg:CC 132)
        (compare:CC (reg/v:DI 122 [ x.4 ])
            (const_int 0 [0x0]))) -1 (insn_list:REG_DEP_TRUE 38 (nil))
    (nil))

Into:
(insn 39 38 40 4 (parallel [
            (set (reg:CC 132)
                (compare:CC (lshiftrt:DI (reg/v:DI 122 [ x.4 ])
                        (const_int 1 [0x1]))
                    (const_int 0 [0x0])))
            (set (reg/v:DI 122 [ x.4 ])
                (lshiftrt:DI (reg/v:DI 122 [ x.4 ])
                    (const_int 1 [0x1])))
        ]) 259 {*lshrdi3_internal3} (nil)
    (nil))

Which is wrong, see how we have DI mode here but we have SI mode before so now we are shifting all 
the way which is wrong.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-02-22 01:15:27
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134

[Bug rtl-optimization/20134] [4.0 Regression] combine messes up subreg/zero_extend/compare/lshift

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-02-22 17:03 -------
That's not a problem.  The SUBREG is SUBREG_PROMOTED_VAR_P and
SUBREG_PROMOTED_UNSIGNED_P, which is a promise that the upper 32 bits are all 0.

The problem is that when using the K&R style function definition, there is
no prototype for the function and so the caller expects
int exact_log2_wide (int);
while the callee is actually int exact_log2_wide (unsigned int);
It looks like int is passed sign extended and unsigned int zero extended,
so the functions disagree about what the upper 32 bits of the argument
should contain.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134

[Bug rtl-optimization/20134] [4.0 Regression] combine messes up subreg/zero_extend/compare/lshift

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-02-22 18:14 -------
The testcase is indeed invalid.  K&R definition can't serve as a prototype
and whether a 32-bit argument is on PPC64 sign or zero extended to 64-bit
depends on whether the argument is signed or unsigned.
So, either prototypes must be used, or the caller must match the type of the
arguments.

if (exact_log2_wide (0x80000000) != 31) abort ();
or
if (exact_log2_wide ((unsigned int) -2147483648) != 31) abort ();
work just fine.
On many 64-bit arches this testcase will work anyway, as arguments are e.g.
always sign extended to 64-bit (I believe Alpha is an example here) or zero
extended to 64-bit.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|wrong-code                  |
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134