[Bug tree-optimization/31169] New: Bootstrap comparison error at revision 122821

[Bug tree-optimization/31169] New: Bootstrap comparison error at revision 122821

[danglin at gcc dot gnu dot org]

make[3]: Leaving directory `/test/gnu/gcc/objdir'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./build/genautomata.o differs
./pointer-set.o differs
./cfgexpand.o differs
./cfglayout.o differs
./builtins.o differs
./cfgloopanal.o differs
./cfgloopmanip.o differs
./cse.o differs
./cselib.o differs
./combine.o differs
./df-core.o differs
./df-scan.o differs
./gcse.o differs
./gimplify.o differs
./global.o differs
./graph.o differs
./jump.o differs
./lambda-mat.o differs
./langhooks.o differs
./lambda-code.o differs
./loop-invariant.o differs
./lower-subreg.o differs
./omega.o differs
./postreload.o differs
./real.o differs
./recog.o differs
./regmove.o differs
./regclass.o differs
./regrename.o differs
./reload.o differs
./reload1.o differs
./rtlanal.o differs
./see.o differs
./sched-rgn.o differs
./simplify-rtx.o differs
./stmt.o differs
./struct-equiv.o differs
./tree-complex.o differs
./tree-cfg.o differs
./tree-data-ref.o differs
./tree-eh.o differs
./tree-pretty-print.o differs
./tree-ssa-coalesce.o differs
./tree-ssa-dom.o differs
./tree-ssa-live.o differs
./tree-ssa-loop-im.o differs
./tree-ssa-loop-niter.o differs
./tree-ssa-loop-ivopts.o differs
./tree-ssa-phiopt.o differs
./tree-ssa-pre.o differs
./tree-ssa.o differs
./tree-vect-analyze.o differs
./tree-vectorizer.o differs
./tree-vect-transform.o differs
./cgraphunit.o differs
./gccspec.o differs
./gcc.o differs
./c-decl.o differs
./final.o differs
./modulo-sched.o differs
./passes.o differs
./ipa-inline.o differs
./gcov.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/test/gnu/gcc/objdir'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/test/gnu/gcc/objdir'

-bash-2.05b$ ./xgcc -B./ -v
Reading specs from ./specs
Target: hppa2.0w-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as
--enable-shared --disable-nls --with-local-prefix=/opt/gnu
--prefix=/opt/gnu/gcc/gcc-4.3.0 --enable-debug=no --enable-threads=posix
--with-mpfr=/opt/gnu/gcc/gcc-4.3.0 --with-gmp=/opt/gnu/gcc/gcc-4.3.0
--disable-libmudflap --enable-languages=c
Thread model: posix
gcc version 4.3.0 20070311 (experimental)


-- 
           Summary: Bootstrap comparison error at revision 122821
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa*-*-* (32-bit)
  GCC host triplet: hppa*-*-* (32-bit)
GCC target triplet: hppa*-*-* (32-bit)


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[sje at cup dot hp dot com]

-- 

sje at cup dot hp dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-03-14 20:03:38
               date|                            |


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2007-03-14 20:53 -------
--- ChangeLog   (revision 122820)
+++ ChangeLog   (revision 122821)
@@ -1,3 +1,12 @@
+2007-03-11  Richard Guenther  <rguenther@suse.de>
+
+       PR tree-optimization/31115
+       * tree-vrp.c (extract_range_from_binary_expr): Make sure
+       the shift count is positive and non-anti-range for RSHIFT_EXPR.
+       A shift count of zero is not special as with *_DIV_EXPR.
+       (vrp_int_const_binop): Handle RSHIFT_EXPR for determining overflow
+       direction.
+

oh well.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[daney at gcc dot gnu dot org]

------- Comment #2 from daney at gcc dot gnu dot org  2007-03-14 22:34 -------
http://gcc.gnu.org/ml/gcc/2007-03/msg00521.html may be the same problem.  I
will try to test on both sides of 122821 to try to confirm.


-- 

daney at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daney at gcc dot gnu dot org


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[sje at cup dot hp dot com]

------- Comment #3 from sje at cup dot hp dot com  2007-03-15 00:19 -------
My attempt to add an attachment failed (mail to dberlin has been sent) so here
is a cut down code segment from genautomata.c that generates different assembly
language when compiled with the PA stage1 compiler than it does with the PA
stage2 compiler.



enum regexp_mode
{
  rm_unit,
  rm_reserv,
  rm_nothing,
  rm_sequence,
  rm_repeat,
  rm_allof,
  rm_oneof
};

struct regexp;
typedef struct regexp *regexp_t;

struct oneof_regexp
{
  int regexps_num;
  regexp_t regexps [1];
};

struct regexp
{
  enum regexp_mode mode;
  int pos;
  union
  {
    struct oneof_regexp oneof;
  } regexp;
};

void
process_alts_for_forming_states (regexp_t regexp)
{
  int i = 1;
      for (i = regexp->regexp.oneof.regexps_num - 1; i >= 0; i--)
        process_alts_for_forming_states (__extension__ (({ struct regexp *const
_regexp = (regexp); if (_regexp->mode != rm_oneof) abort ();
&(_regexp)->regexp.
oneof; }))->regexps [i]);
}


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2007-03-15 09:46 -------
Now find the file that was miscompiled to produce the differing assembly...
(at which point do the dumps start to look different, then exchange affected
object files for the stage1 variant and see if the difference vanishes)


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[steven at gcc dot gnu dot org]

------- Comment #5 from steven at gcc dot gnu dot org  2007-03-15 16:45 -------
Just to make sure: Did revision 122820 bootstrap without problems? I.e. is it
certain that the patch for r122821 caused the bootstrap comparison failure?


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[sje at cup dot hp dot com]

------- Comment #6 from sje at cup dot hp dot com  2007-03-15 16:52 -------
Yes, I did a successful bootstrap on PA with 122820, updated to 122821, did a
new bootstrap (after removing the object directory) and got the comparision
failure.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[sje at cup dot hp dot com]

------- Comment #7 from sje at cup dot hp dot com  2007-03-15 16:56 -------
Created an attachment (id=13209)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13209&action=view)
output of stage1 compiler from ivopts


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[sje at cup dot hp dot com]

------- Comment #8 from sje at cup dot hp dot com  2007-03-15 16:56 -------
Created an attachment (id=13210)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13210&action=view)
output of stage2 compiler from ivopts


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[sje at cup dot hp dot com]

------- Comment #9 from sje at cup dot hp dot com  2007-03-15 16:58 -------
I created two attachments, one is the output of ivopts from the stage1 compiler
and the other is from the stage2 compiler.  This is the first place the two
compilers divirge in their output when compiling the test case in comment #3.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2007-03-15 17:19 -------
Now what is interesting despite of being wrong or not is that we use an
index only for the MEM ref:

<L11>:;
  D.1641_16 = D.1589_4 + -1;
  D.1642_15 = &regexp_3(D)->regexp.oneof.regexps[D.1641_16];
  ivtmp___31_21 = (long unsigned int) D.1642_15;

  # ivtmp___31_1 = PHI <ivtmp___31_12(5), ivtmp___31_21(7)>
  # i_18 = PHI <i_11(5), i_5(7)>
<L2>:;
  D.1592_10 = MEM[index: ivtmp___31_1];
  process_alts_for_forming_states (D.1592_10);
  i_11 = i_18 + -1;
  if (i_11 >= 0) goto <L0>; else goto <L4>;

the stage2 compiler then derives a loop trip count based on the size of
the regexp->regexp.oneof.regexps[] array it seems (a size of 3 actually)
and replaces the induction variable by the MEM index.

This doesn't look like a wrong transformation, but I fail to see how
this could be different from the stage1 and stage2 compiler.

Zdenek, are we supposed to get a index-only mem-ref?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rakdver at gcc dot gnu dot
                   |                            |org


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2007-03-15 17:28 -------
Note that either SCEV or ivopts derives a loop trip count of 1 wrongly out of
the [1] sized array as it is a tail array.  Why this happens in stage2 and not
stage1 is of course a mystery if not (what is probably the case)
tree-scalar-evolution.c, tree-chrec.c or tree-ssa-loop-ivopts.c is miscompiled.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2007-03-15 17:57 -------
It would be interesting to know why tree-ssa-loop-niter.c:array_at_struct_end_p
()
returns a different value for the stage1/stage2 compiler.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[sje at cup dot hp dot com]

------- Comment #13 from sje at cup dot hp dot com  2007-03-15 19:26 -------
With respect to comment #12.  It looks like array_at_struct_end_p is returning
true in both compilers.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca  2007-03-15 20:59 -------
Subject: Re:  Bootstrap comparison error at revision 122821g

> Just to make sure: Did revision 122820 bootstrap without problems? I.e. is it
> certain that the patch for r122821 caused the bootstrap comparison failure?

Yes, I did a regression search.  See
http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg00674.html
for r122820 linux results.  I did a full bootstrap of C with r122820 on
hppa2.0w-hp-hpux11.11.  Didn't run testsuite.

The same error occurs on both hpux and linux.

Removal of the middle hunk of Richard's change does not fix the problem.
I had thought the issue might be related to negative ashifts.

Dave


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2007-03-15 21:06 -------
Did you try reverting the last hunk:

@@ -1816,7 +1833,8 @@
         the new range.  */

       /* Divisions by zero result in a VARYING value.  */
-      if (code != MULT_EXPR
+      if ((code != MULT_EXPR
+          && code != RSHIFT_EXPR)
          && (vr0.type == VR_ANTI_RANGE || range_includes_zero_p (&vr1)))
        {
          set_value_range_to_varying (vr);

that should be the only one that increases the amount of optimization done.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca  2007-03-15 21:12 -------
Subject: Re:  Bootstrap comparison error at revision 122821

> Did you try reverting the last hunk:

No.  I'll give it a try shortly.

Dave


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca  2007-03-16 02:07 -------
Subject: Re:  Bootstrap comparison error at revision 122821

> Did you try reverting the last hunk:
> 
> @@ -1816,7 +1833,8 @@
>          the new range.  */
> 
>        /* Divisions by zero result in a VARYING value.  */
> -      if (code != MULT_EXPR
> +      if ((code != MULT_EXPR
> +          && code != RSHIFT_EXPR)
>           && (vr0.type == VR_ANTI_RANGE || range_includes_zero_p (&vr1)))
>         {
>           set_value_range_to_varying (vr);

FWIW, this is the hunk that introduced the failure.

Dave


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2007-03-16 09:25 -------
Gah, let's analyze the effect of this change.  First, with

  /* Refuse to operate on VARYING ranges, ranges of different kinds
     and symbolic ranges.  As an exception, we allow BIT_AND_EXPR
     because we may be able to derive a useful range even if one of
     the operands is VR_VARYING or symbolic range.  TODO, we may be
     able to derive anti-ranges in some cases.  */
  if (code != BIT_AND_EXPR
      && code != TRUTH_AND_EXPR
      && code != TRUTH_OR_EXPR
      && (vr0.type == VR_VARYING
          || vr1.type == VR_VARYING
          || vr0.type != vr1.type
          || symbolic_range_p (&vr0)
          || symbolic_range_p (&vr1)))
    {
      set_value_range_to_varying (vr);
      return;
    }

...

      /* If we have a RSHIFT_EXPR with a possibly negative shift
         count or an anti-range shift count drop to VR_VARYING.
         We currently cannot handle the overflow cases correctly.  */
      if (code == RSHIFT_EXPR
          && (vr1.type == VR_ANTI_RANGE
              || !vrp_expr_computes_nonnegative (op1, &sop)))
        {
          set_value_range_to_varying (vr);
          return;
        }

we make sure neither vr0 nor vr1 are anti-ranges and vr1 is >= 0.

Now, the hunk above changes us to not reject ranges that include zero for
the shift count.  (This makes it possible to handle unsigned half-ranges
[0, n])

If the count is actually zero, we can end up doing x << 0 (a left shift of
zero).  Does hppa handle this correctly?  Does it, for

int foo (unsigned int i)
{
  int j = 12048173;
  if (i < 32)
    {
      j = j >> i;
      if (j > 0)
        return 0;
    }
  return 1;
}

correctly have a value range of [0, 12048173] for j_5?  (look at 055t.vrp1
dump)

Obviously I fail to see how this can cause a miscompilation...


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca  2007-03-16 14:43 -------
Subject: Re:  Bootstrap comparison error at revision 122821

> If the count is actually zero, we can end up doing x << 0 (a left shift of
> zero).  Does hppa handle this correctly?  Does it, for

The hardware doesn't support a left shift of zero, so at the moment
the expanders and patterns require that the shift length be greater
than zero.  I recently fixed a bug in this area.  Should copies be
generated for this case?

Dave


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca  2007-03-17 13:44 -------
Subject: Re:  Bootstrap comparison error at revision 122821

> int foo (unsigned int i)
> {
>   int j = 12048173;
>   if (i < 32)
>     {
>       j = j >> i;
>       if (j > 0)
>         return 0;
>     }
>   return 1;
> }
> 
> correctly have a value range of [0, 12048173] for j_5?  (look at 055t.vrp1
> dump)

With the third hunk removed, I see
j_5: VARYING

I'll recheck with the third hunk.

Dave


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[ghazi at gcc dot gnu dot org]

------- Comment #21 from ghazi at gcc dot gnu dot org  2007-03-17 14:12 -------
I get similar "make compare" errors on sparc-sun-solaris2.10.  Reverting the
bit from comment#15 fixes it.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #22 from dave at hiauly1 dot hia dot nrc dot ca  2007-03-17 18:03 -------
Subject: Re:  Bootstrap comparison error at revision 122821

> I'll recheck with the third hunk.
j_5: [0, 12048173]  EQUIVALENCES: { } (0 elements)

There isn't any difference in the code generated with and without
the third hunk.  Also, stage1 through stage3 with hunk generate the
same code at -O2.  As far as I can tell, the code is correct in all
cases.

> > If the count is actually zero, we can end up doing x << 0 (a left shift of
> > zero).  Does hppa handle this correctly?  Does it, for

> The hardware doesn't support a left shift of zero, so at the moment
> the expanders and patterns require that the shift length be greater
> than zero.

Sorry, the above statement is wrong.  What the hardware doesn't support
is zero length deposits.  Deposit instructions are used for shifts.
In the case of an ashift with a CONST_INT shift amount x, the deposit
length is 32 - (INTVAL (x) & 31).  So, the deposit length is [1, 32].

Dave


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[daney at gcc dot gnu dot org]

------- Comment #23 from daney at gcc dot gnu dot org  2007-03-18 01:55 -------
Reverting the hunk mentioned in comment #15 also allows mipsel-linux to
bootstrap.

I bootstrapped R122924 which failed in the stage2 stage3 compare.  I then
reverted said hunk, and re-bootstrapped successfully.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca  2007-03-19 00:08 -------
Subject: Re:  Bootstrap comparison error at revision 122821

> <L11>:;
>   D.1641_16 = D.1589_4 + -1;
>   D.1642_15 = &regexp_3(D)->regexp.oneof.regexps[D.1641_16];
>   ivtmp___31_21 = (long unsigned int) D.1642_15;
> 
>   # ivtmp___31_1 = PHI <ivtmp___31_12(5), ivtmp___31_21(7)>
>   # i_18 = PHI <i_11(5), i_5(7)>
> <L2>:;
>   D.1592_10 = MEM[index: ivtmp___31_1];
>   process_alts_for_forming_states (D.1592_10);
>   i_11 = i_18 + -1;
>   if (i_11 >= 0) goto <L0>; else goto <L4>;
> 
> the stage2 compiler then derives a loop trip count based on the size of
> the regexp->regexp.oneof.regexps[] array it seems (a size of 3 actually)
> and replaces the induction variable by the MEM index.
> 
> This doesn't look like a wrong transformation, but I fail to see how
> this could be different from the stage1 and stage2 compiler.
> 
> Zdenek, are we supposed to get a index-only mem-ref?

I've reviewed Steve's findings and concur.

The index-only mem-ref seemed wierd, so I checked whether it is
generated with the third hunk reverted.  It is still present with
the hunk reverted, so I don't think this is the cause of the problem.

Dave


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #25 from rguenth at gcc dot gnu dot org  2007-03-19 09:55 -------
Well, so unless somebody has a testcase that is miscompiled (preferably at the
tree level ;)) and that I can investigate with a cross compiler I cannot do
anything here :/


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #26 from rguenth at gcc dot gnu dot org  2007-03-19 11:07 -------
Btw, did you compare testsuite results from a non-bootstrapped patched vs.
unpatched tree?


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[sje at cup dot hp dot com]

------- Comment #27 from sje at cup dot hp dot com  2007-03-19 16:11 -------
I did a non-bootstrap build and test on hppa1.1-hp-hpux11.11 over the weekend
(C only) and I got two failures that I don't normally see, builtin-pow-mpfr-1.c
and builtin-sin-mpfr-1.c.  I am not certain these failures are related to this
defect but I will investigate some more.  The pow test is failing some tree
dump scans and sin is failing with link_error() undefined.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[ghazi at gcc dot gnu dot org]

------- Comment #28 from ghazi at gcc dot gnu dot org  2007-03-19 16:41 -------
(In reply to comment #27)
> I did a non-bootstrap build and test on hppa1.1-hp-hpux11.11 over the weekend
> (C only) and I got two failures that I don't normally see, builtin-pow-mpfr-1.c
> and builtin-sin-mpfr-1.c.  I am not certain these failures are related to this
> defect but I will investigate some more.  The pow test is failing some tree
> dump scans and sin is failing with link_error() undefined.

Those testcases should only fail if your MPFR is too old (i.e. something less
than version 2.2.1).  So I don't think they are related to this defect either.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[sje at cup dot hp dot com]

------- Comment #29 from sje at cup dot hp dot com  2007-03-19 22:41 -------
In reply to comment #28:  I suspected as much but it is interesting that I have
a new gmp/mpfr.  If I build bootstrap the resulting compiler passes these
tests.  If I build non-bootstrap the resulting compiler does not pass these
tests.  I guess that is because the compiler I am starting with wasn't built
with the new gmp/mpfr.  But this has nothing to do with this bug report.  I
have two non-bootstrap compilers now (with and without the patch), I will try
expanding my testing to include C++ and Fortran and see if that finds a test
difference.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[sje at cup dot hp dot com]

------- Comment #30 from sje at cup dot hp dot com  2007-03-20 21:13 -------
I tried the C++ and Fortran tests (in addition to C) with version 122821 using
a non-boostrapped compiler but I got no new failures.  It looks like the only
failing test case we have is the compiler itself.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #31 from dave at hiauly1 dot hia dot nrc dot ca  2007-03-28 00:58 -------
Subject: Re:  Bootstrap comparison error at revision 122821

>       /* If we have a RSHIFT_EXPR with a possibly negative shift
>          count or an anti-range shift count drop to VR_VARYING.
>          We currently cannot handle the overflow cases correctly.  */
>       if (code == RSHIFT_EXPR
>           && (vr1.type == VR_ANTI_RANGE
>               || !vrp_expr_computes_nonnegative (op1, &sop)))
>         {
>           set_value_range_to_varying (vr);
>           return;
>         }
> 
> we make sure neither vr0 nor vr1 are anti-ranges and vr1 is >= 0.

Don't see the check to make sure vr0 isn't an anti-range.  It
was eliminated by the hunk 3 change.

Dave


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #32 from rguenth at gcc dot gnu dot org  2007-03-28 08:52 -------
There is

  /* Refuse to operate on VARYING ranges, ranges of different kinds
     and symbolic ranges.  As an exception, we allow BIT_AND_EXPR
     because we may be able to derive a useful range even if one of
     the operands is VR_VARYING or symbolic range.  TODO, we may be
     able to derive anti-ranges in some cases.  */  
  if (code != BIT_AND_EXPR
      && code != TRUTH_AND_EXPR
      && code != TRUTH_OR_EXPR
      && (vr0.type == VR_VARYING
          || vr1.type == VR_VARYING
          || vr0.type != vr1.type
          || symbolic_range_p (&vr0)
          || symbolic_range_p (&vr1)))
    {
      set_value_range_to_varying (vr);
      return;
    }

which sets the value range to varying if vr0.type != vr1.type, so if
vr1.type is not an anti-range, then vr0.type isn't either.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rth at gcc dot gnu dot org]

------- Comment #33 from rth at gcc dot gnu dot org  2007-03-29 17:30 -------
I've been trying to track down this same failure on Alpha.  I can reproduce
that
reverting the third hunk allows the bootstrap to complete.  Finding what has
got
miscompiled has been very difficult.  Only two files compile differently:
fold-const.c and tree.c.

Unfortunately, a function early in fold-const.c gets compiled differently 
legitimately -- sign_bit_p actually benefits from the optimization -- and
all the functions after that differ in decl_uid numbers, which completely
obscures the rest of the changes.

I'll keep searching...


-- 

rth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-03-14 20:03:38         |2007-03-29 17:30:45
               date|                            |


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rth at gcc dot gnu dot org]

------- Comment #34 from rth at gcc dot gnu dot org  2007-03-29 18:13 -------
Actually, on second thought, I don't think the sign_bit_p change is legit:

 Value ranges after VRP:

-mask_lo_1: [0, +INF]  EQUIVALENCES: { } (0 elements)
+mask_lo_1: [0x0ffffffffffffffff, +INF]  EQUIVALENCES: { } (0 elements)
 lo_2: [0, +INF]  EQUIVALENCES: { } (0 elements)
 mask_hi_3: VARYING
 hi_4: VARYING
@@ -8971,7 +8971,7 @@ mask_hi_38: VARYING
 D.30338_41: [-1, 63]  EQUIVALENCES: { } (0 elements)
 lo_42: [0, +INF]  EQUIVALENCES: { } (0 elements)
 D.30339_44: [0, 64]  EQUIVALENCES: { } (0 elements)
-mask_lo_45: [0, +INF]  EQUIVALENCES: { } (0 elements)
+mask_lo_45: [0x0ffffffffffffffff, +INF]  EQUIVALENCES: { } (0 elements)
 D.30340_47: [22, 22]  EQUIVALENCES: { D.30324_17 D.30324_96 } (2 elements)
 D.30341_49: VARYING
 D.30342_50: VARYING
@@ -9211,7 +9211,7 @@ sign_bit_p (exp, val)
   # hi_4 = PHI <hi_34(13), 0(14)>
   # mask_hi_3 = PHI <mask_hi_38(13), 0(14)>
   # lo_2 = PHI <0(13), lo_42(14)>
-  # mask_lo_1 = PHI <0x0ffffffffffffffff(13), mask_lo_45(14)>
+  # mask_lo_1 = PHI <0x0ffffffffffffffff(13), 0x0ffffffffffffffff(14)>
 <L13>:;
   D.30340_47 = 22;
   D.30341_49 = val_102(D)->int_cst.int_cst.high;
@@ -9221,7 +9221,7 @@ sign_bit_p (exp, val)
 <L16>:;
   D.30343_52 = 22;
   D.30344_54 = val_102(D)->int_cst.int_cst.low;
-  D.30345_55 = D.30344_54 & mask_lo_1;
+  D.30345_55 = D.30344_54;
   if (D.30345_55 == lo_2) goto <L42>; else goto <L20>;

 <L20>:;

The VRP change for mask_lo_1 is correct; the two values that the variable
can obtain are 0xffff...ffff and 0x0fff...ffff.  But removing the BIT_AND
is incorrect, afaics.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rth at gcc dot gnu dot org]

------- Comment #35 from rth at gcc dot gnu dot org  2007-03-29 18:21 -------
With some sed help, one can see that fold_binary is completely ruined:

-  mhi = 0x0ffffffffffffffff >> 128 - width;
-  if ((~(hi2 | hi1) & mhi) == 0) goto <L>; else goto <L>;
-
-<L>:;
-  mlo = 0x0ffffffffffffffff;
+  mhi = 0;
   goto <bb > (<L>);

Incorrect folding is surely what causes ivopts to do bad things, and bad
loop opts is the visible miscompilation problem in stage3.  Probably you
can extract sign_bit_p from any target's preprocessing and debug the 
problem.  If that's not true, I can go back and do it.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #36 from rguenth at gcc dot gnu dot org  2007-03-30 09:18 -------
Thanks for the analysis!  This should help.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #37 from rguenth at gcc dot gnu dot org  2007-03-30 10:01 -------
The (target) difference seems to be that I get (on x86_64)

  mask_lo_45 = 0x0ffffffffffffffff >> D.33492_44;

with a value range of [0,64] for D.33492_44 and a resulting value range of
[0, +INF] for mask_lo_45, not [+INF, +INF] (which is wrong).

Note that I get the same correct behavior iff changing HWI to 32/64bits and
using -m32.  This is the testcase I'm looking at:

#define HOST_WIDE_INT long
#define HOST_BITS_PER_WIDE_INT (8*8)

int
sign_bit_p (int width, HOST_WIDE_INT val_hi, unsigned HOST_WIDE_INT val_lo)
{
  unsigned HOST_WIDE_INT mask_lo, lo;
  HOST_WIDE_INT mask_hi, hi;

  if (width > HOST_BITS_PER_WIDE_INT)
    {
      hi = (unsigned HOST_WIDE_INT) 1 << (width - HOST_BITS_PER_WIDE_INT - 1);
      lo = 0;

      mask_hi = ((unsigned HOST_WIDE_INT) -1
                 >> (2 * HOST_BITS_PER_WIDE_INT - width));
      mask_lo = -1;
    }
  else
    {
      hi = 0;
      lo = (unsigned HOST_WIDE_INT) 1 << (width - 1);

      mask_hi = 0;
      mask_lo = ((unsigned HOST_WIDE_INT) -1
                 >> (HOST_BITS_PER_WIDE_INT - width));
    }

  if ((val_hi & mask_hi) == hi
      && (val_lo & mask_lo) == lo)
    return 1;

  return 0;
}

can you confirm that this one is miscompiled?  I'll try to build a cross
compiler now.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #38 from rguenth at gcc dot gnu dot org  2007-03-30 10:15 -------
Ok, got it now - the crucial point is where width comes from:

#define HOST_WIDE_INT long
#define HOST_BITS_PER_WIDE_INT (4*8)

struct tree_type
{
  unsigned int precision : 9;
};

int
sign_bit_p (struct tree_type *t, HOST_WIDE_INT val_hi, unsigned HOST_WIDE_INT
val_lo)
{
  unsigned HOST_WIDE_INT mask_lo, lo;
  HOST_WIDE_INT mask_hi, hi;
  int width = t->precision;


(... continuing as the last testcase)


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #39 from rguenth at gcc dot gnu dot org  2007-03-30 10:47 -------
Created an attachment (id=13300)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13300&action=view)
patch

The problem is that we in rshift_double() do

  if (SHIFT_COUNT_TRUNCATED)
    count %= prec;

which for a count == 32 yields count == 0 and a wrong value (even if we special
case the value of 32 below as it is undefined by the standard).

I don't see why we should care about SHIFT_COUNT_TRUNCATED during folding of
constants at all, in fact, it looks completely bogus.

I'd appreciate if you could test this patch for any side-effects (otherwise
it looks obvious).


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rth at gcc dot gnu dot org]

------- Comment #40 from rth at gcc dot gnu dot org  2007-03-30 16:14 -------
The reason we do that is to match the way the arithmetic would be performed
on the host as much as possible.  This could be important if someother part
of the compiler already relied on SHIFT_COUNT_TRUNCATED to eliminate a 
masking operation on the shift count, or somesuch.

I don't think this is obvious at all.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rth at gcc dot gnu dot org]

------- Comment #41 from rth at gcc dot gnu dot org  2007-03-30 17:30 -------
Created an attachment (id=13302)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13302&action=view)
alternate patch

I'm inclined to take this approach to the problem.  Note that the result
range we get from this is [1,+INF] instead of [0,+INF], which is in fact
more correct as far as it goes.

Bootstrapping it now...


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #42 from dave at hiauly1 dot hia dot nrc dot ca  2007-03-31 01:17 -------
Subject: Re:  Bootstrap comparison error at revision 122821

+                 /* We know that the range of input values covers the entire
+                    shift space.  Reduce to canonical [0,width-1].  */
+                 vr1.min = build_int_cst (TREE_TYPE (vr1.min), 0);
+                 vr1.max = build_int_cst (TREE_TYPE (vr1.max), prec - 1);

Wouldn't it be slightly better to just call range_includes_zero_p (&vr1)
and return at this point?

Dave


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #43 from rguenth at gcc dot gnu dot org  2007-03-31 11:27 -------
I would have unconditionally set the maximum of the shift value range to
prec-1.  I guess reverting the last hunk with range_includes_zero_p was
accidential?


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #44 from dave at hiauly1 dot hia dot nrc dot ca  2007-03-31 15:10 -------
Subject: Re:  Bootstrap comparison error at revision 122821

> Wouldn't it be slightly better to just call range_includes_zero_p (&vr1)
> and return at this point?

Forget that, I didn't notice the "else" added to last hunk.

Dave


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #45 from rguenth at gcc dot gnu dot org  2007-03-31 15:13 -------
doh, me neither.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #46 from dave at hiauly1 dot hia dot nrc dot ca  2007-03-31 15:38 -------
Subject: Re:  Bootstrap comparison error at revision 122821

> ------- Comment #45 from rguenth at gcc dot gnu dot org  2007-03-31 15:13 -------
> doh, me neither.

I just started a build with your patch.  Boostrap completes successfully
with r~'s patch.  Check is in progress.

Dave


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[daney at gcc dot gnu dot org]

------- Comment #47 from daney at gcc dot gnu dot org  2007-04-01 08:29 -------
With RTH's "alternate patch" applied, I can now bootstrap mipsel-linux

The test results are here:
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00036.html

And are substancially similar to what I was getting before the breakage hit.


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rth at gcc dot gnu dot org]

------- Comment #48 from rth at gcc dot gnu dot org  2007-04-01 19:17 -------
Subject: Bug 31169

Author: rth
Date: Sun Apr  1 19:17:38 2007
New Revision: 123405

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123405
Log:
        PR tree-optimization/31169 
        * tree-vrp.c (extract_range_from_binary_expr) <RSHIFT_EXPR>: Drop
        to varying if the range is outside [0,  prec-1].

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vrp.c


-- 


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rth at gcc dot gnu dot org]

------- Comment #49 from rth at gcc dot gnu dot org  2007-04-01 19:26 -------
Fixed.


-- 

rth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

[rguenth at gcc dot gnu dot org]

------- Comment #50 from rguenth at gcc dot gnu dot org  2007-04-12 10:20 -------
Subject: Bug 31169

Author: rguenth
Date: Thu Apr 12 10:20:42 2007
New Revision: 123737

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123737
Log:
2007-04-12  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/31169
        * gcc.c-torture/execute/pr31169.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/pr31169.c
Modified:
    trunk/gcc/testsuite/ChangeLog


-- 


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