https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
--- Comment #8 from Marek Polacek ---
I wonder if I could just
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -3401,14 +3401,14 @@ operand_equal_for_comparison_p (tree arg0, tree arg1,
tree other)
primarg1 = get_narrower (arg1, &unsignedp1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
--- Comment #7 from Marek Polacek ---
Yes, it's in operand_equal_for_comparison_p, and that would also explain why it
started with r125012. I didn't update the BZ when I found this out. I hope to
look into this more this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
--- Comment #5 from d25fe0be@ ---
Oops, sorry, I read the 2nd and the 3rd operand of the conditional operator in
wrong order.
A silly mistake..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
--- Comment #4 from d25fe0be@ ---
Per n4659 7.8/[conv.integral]:
```
If the destination type is signed, the value is unchanged if it can be
represented in the destination type;
otherwise, the value is implementation-defined.
```
Isn't `(char)xx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
--- Comment #3 from Marek Polacek ---
Ugh, I believe fold_cond_expr_with_comparison does Very Bad stuff: it sees
A == 0 ? A : 0 and thinks that it can be optimized to 0, btu it can't, in this
case we have
(signed char) xxx == 0 ? (unsigned long l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
--- Comment #2 from Marek Polacek ---
Probably started with r125012.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
