This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug testsuite/69586] [6 Regression] FAIL: gcc.dg/uninit-21.c for target defaulting to short enum
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 15 Feb 2016 14:04:52 +0000
- Subject: [Bug testsuite/69586] [6 Regression] FAIL: gcc.dg/uninit-21.c for target defaulting to short enum
- Auto-submitted: auto-generated
- References: <bug-69586-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
So first half of a patch is
Index: gcc/tree-vrp.c
===================================================================
--- gcc/tree-vrp.c (revision 233418)
+++ gcc/tree-vrp.c (working copy)
@@ -5449,7 +5466,7 @@ register_edge_assert_for_2 (tree name, e
cst2 = NULL_TREE;
if (rhs_code == BIT_AND_EXPR
|| (CONVERT_EXPR_CODE_P (rhs_code)
- && TREE_CODE (TREE_TYPE (val)) == INTEGER_TYPE
+ && INTEGRAL_TYPE_P (TREE_TYPE (val))
&& TYPE_UNSIGNED (TREE_TYPE (val))
&& TYPE_PRECISION (TREE_TYPE (gimple_assign_rhs1 (def_stmt)))
> prec))
but then BIT_AND handling in extract_range_from_binary_1 needs to be improved
for ~[0, 0] & [255, 255] as splitting into
[-INT_MIN, -1] & 255 ^ [1, INT_MAX] & 255
can never yield a good answer.
I guess the issue is that we arrive with ~[0, 0] from the
(unsigned char)_9 != 0
test in the first place which doesn't give us enough info to improve
_9 & 255