--- 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 <[EMAIL PROTECTED]>
--- 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
--- 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_ra
--- 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 befor
--- 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
--- 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
--- 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" a
--- 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=3116
--- 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].
--- 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
--- 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 eliminat
--- 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 fo
--- 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
--- 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 = 0x0 >> 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, no
--- 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
--- 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 = 0x0 >> 128 - width;
- if ((~(hi2 | hi1) & mhi) == 0) goto ; else goto ;
-
-:;
- mlo = 0x0;
+ mhi = 0;
--- 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: [0x0, +INF] EQUIVALENCES: { } (0 e
--- 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 comp
--- 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
--- 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.
> W
--- 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:
--- 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 p
--- 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
--- 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
--- 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
--- 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_b
--- 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
> :;
> D.1641_16 = D.1589_4 + -1;
> D.1642_15 = ®exp_3(D)->regexp.oneof.regexps[D.1641_16];
> ivtmp___31_21 = (long unsigned int) D.1642_15
--- 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.
--
--- 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
--- 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
--- 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;
> }
>
--- 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 hardwa
--- 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
--- 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 VARY
--- 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
--- 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
+
--- 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 compar
--- 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
--- 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
--- 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 th
--- 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:
:;
D.1641_16 = D.1589_4 + -1;
D.1642_15 = ®exp_3(D)->regexp.oneof.regexps[D.1641_16];
ivtmp___31_21 = (long
--- 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 #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
--- 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
--- 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
--- 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
--- 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 v
--- 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 doe
--- 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
--- 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 <[EMAIL PROTECTED]>
+
+ PR tree-optimization/31115
+ * tree-vrp.c (extract_range_from_bi
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|
51 matches
Mail list logo
