This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/77826] [7 Regression] ICE in decompose, at wide-int.h:928 w/ -m64 -O2 and above
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 03 Oct 2016 14:07:38 +0000
- Subject: [Bug target/77826] [7 Regression] ICE in decompose, at wide-int.h:928 w/ -m64 -O2 and above
- Auto-submitted: auto-generated
- References: <bug-77826-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77826
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-10-03
CC| |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r240291.
I think the problem is either in the
/* (X | Y) ^ X -> Y & ~ X*/
(simplify
(bit_xor:c (convert? (bit_ior:c @0 @1)) (convert? @0))
(if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
(convert (bit_and @1 (bit_not @0)))))
simplifier or in the infrastructure.
_3 = *v0_14(D);
_4 = (long unsigned int) q2_11(D);
_5 = _3 | _4;
*v0_14(D) = _5;
_7 = (unsigned int) _5;
_9 = q2.0_1 ^ _7;
The xor is done in unsigned int type, while ior is done in unsigned long int
type, and evrp is trying to valueize q2_11(D) as 1. As it is valueized as 1
and operand_equal_p is true for 1U and 1UL, we seem to end up with @0 being 1U
(rather than 1UL), while @1 is unsigned long variable.
--- match.pd.jj 2016-09-29 22:53:14.000000000 +0200
+++ match.pd 2016-10-03 16:04:50.905185018 +0200
@@ -707,8 +707,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* (X | Y) ^ X -> Y & ~ X*/
(simplify
(bit_xor:c (convert? (bit_ior:c @0 @1)) (convert? @0))
- (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
- (convert (bit_and @1 (bit_not @0)))))
+ (if (tree_nop_conversion_p (type, TREE_TYPE (@1)))
+ (with { tree itype = TREE_TYPE (@1); }
+ (convert (bit_and @1 (bit_not (convert:itype @0)))))))
/* Convert ~X ^ ~Y to X ^ Y. */
(simplify
fixes the ICE, but I'm not sure if it is the right fix. Plus, there are
various other simplifications which use (convert? @[0-9]) together with the
same @[0-9] outside of the convert that could potentially have the same
problem.