https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100733
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think this is another -gstatement-frontiers issue.
Without -g, during folding we are folding a COND_EXPR with x != 0, 0 and 1
arguments, but with -g it has a STATEMENT_LIST with DEBUG_BEGIN_STMT and x != 0
And that one e.g. in fold_ternary_loc doesn't satisfy truth_value_p, so the
/* Convert A ? 0 : 1 to !A. This prefers the use of NOT_EXPR
over COND_EXPR in cases such as floating point comparisons. */
if (integer_zerop (op1)
&& code == COND_EXPR
&& integer_onep (op2)
&& !VECTOR_TYPE_P (type)
&& truth_value_p (TREE_CODE (arg0)))
return fold_convert_loc (loc, type,
invert_truthvalue_loc (loc, arg0));
folding doesn't happen. In the past, most of the -gstatement-frontiers related
-fdebug-compare bugfixes were about making sure we gimplify it the same (and we
still have some unresolved (almost unresolvable) ones). But this shows whole
new category of bugs, the folders aren't really prepared for it, guess neither
generic-match.c (or its callers) or fold-const.c.
E.g. fold_ternary_loc starts with
if (op0)
{
arg0 = op0;
STRIP_NOPS (arg0);
}
shouldn't we use expr_single in that code somehow? Like after the STRIP_NOPS
add
do
{
tree narg0 = expr_single (arg0);
if (narg0 == arg0)
break;
arg0 = narg0;
STRIP_NOPS (arg0);
}
while (1);
perhaps in some macro/inline fn?
Or reconsider the DEBUG_BEGIN_STMT stuff.
