[Bug tree-optimization/113210] [14 Regression] ICE: tree check: expected integer_cst, have cond_expr in get_len, at tree.h:6481

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113210

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Or maybe just a bug in the PLUS_EXPR folding?
The code sets NITERSM1 to
(short unsigned int) (a.0_1 + 255) + 1 > 256 ? ~(short unsigned int) (a.0_1 +
255) : 0
and then fold_build2s PLUS_EXPR of that and 1 and somehow it folds to 1, that
doesn't sound right to me.
Now, when folding the + 1 addition just with the second operand, i.e.
~(short unsigned int) (a.0_1 + 255)
it correctly folds into
-(short unsigned int) (a.0_1 + 255)
and obviously the second one to 1.
There is also the
/* (X + 1) > Y ? -X : 1 simplifies to X >= Y ? -X : 1 when
   X is unsigned, as when X + 1 overflows, X is -1, so -X == 1.  */
(simplify
 (cond (gt (plus @0 integer_onep) @1) (negate @0) integer_onep@2)
 (if (TYPE_UNSIGNED (type))
  (cond (ge @0 @1) (negate @0) @2)))
match.pd rule, but that I'd think should just fold the whole thing to:
(short unsigned int) (a.0_1 + 255) >= 256 ? -(short unsigned int) (a.0_1 + 255)
: 1

Though, a.0_1 is unsigned char, so (short unsigned int) (a.0_1 + 255) + 1 > 256
is actually never true.
So guess the folding is correct.