This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/82319] [8 Regression] ICE in generic_simplify_148, at generic-match.c:6436
- 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, 25 Sep 2017 10:36:32 +0000
- Subject: [Bug middle-end/82319] [8 Regression] ICE in generic_simplify_148, at generic-match.c:6436
- Auto-submitted: auto-generated
- References: <bug-82319-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82319
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Shouldn't
/* Optimize cases when CST is outside of ITYPE's range. */
(if (real_compare (LT_EXPR, cst, &imin))
{ constant_boolean_node (cmp == GT_EXPR || cmp == GE_EXPR || cmp ==
NE_EXPR,
type); })
(if (real_compare (GT_EXPR, cst, &imax))
{ constant_boolean_node (cmp == LT_EXPR || cmp == LE_EXPR || cmp ==
NE_EXPR,
type); })
catch that? Though, for those I think you really don't need
itype_fits_ftype_p,
if cst is not a NaN (for NaN and !exception_p it is the cmp == NE_EXPR, then
true, otherwise false, at least IEEE semantics, not sure if we support any
other, but if yes, we should be able to query it from the real struct), then
the above if you actually round imin and imax to the corresponding real type
away from zero at least should work always.