[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- 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=gccview=revrev=123737 Log: 2007-04-12 Richard Guenther [EMAIL PROTECTED] 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
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- 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
--- 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=gccview=revrev=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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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, 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
--- 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
--- 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=13300action=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
--- 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
--- 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=13302action=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
--- 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
--- 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
--- 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 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: [0x0, +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 0x0(13), mask_lo_45(14)
+ # mask_lo_1 = PHI 0x0(13), 0x0(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 0x... and 0x0fff.... 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
--- 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 L; else goto L; - -L:; - mlo = 0x0; + 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=13209action=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
--- 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=13210action=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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
-- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-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
--- 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_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
--- 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
--- 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
