This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/69537] [6 Regression] Incorrect -Wmaybe-uninitialized warning with enum variable
- 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: Thu, 28 Jan 2016 13:55:30 +0000
- Subject: [Bug middle-end/69537] [6 Regression] Incorrect -Wmaybe-uninitialized warning with enum variable
- Auto-submitted: auto-generated
- References: <bug-69537-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69537
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, so this is the check copied from fold-const.c:
(if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
and thus we reject the ENUM_TYPE here:
if (TREE_CODE (TREE_TYPE (arg0)) == INTEGER_TYPE
&& CONVERT_EXPR_P (arg0))
{
/* If we are widening one operand of an integer comparison,
see if the other operand is similarly being widened. Perhaps we
can do the comparison in the narrower type. */
tem = fold_widened_comparison (loc, code, type, arg0, arg1);
if (tem)
return tem;
/* Or if we are changing signedness. */
tem = fold_sign_changed_comparison (loc, code, type, arg0, arg1);
if (tem)
return tem;
}
not sure how this was optimized before. Note that we happily accepted
non-INTEGER_TYPE operand of the conversion.
When moving the code I didn't want to change the predicate to INTEGRAL_TYPE_P
but I guess this is what I am going to test now (without trying to track
down how exactly we got to bypass that back in time...).