This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/86532] [9 Regression] Wrong code due to a wrong strlen folding starting with r262522


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

--- Comment #24 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Hope you don't mind, but may I suggest to do the comparison in unsigned
arithmetics, like:

      /* We don't know the starting offset, but we do know that the string
         has no internal zero bytes.  If the offset falls within the bounds
         of the string subtract the offset from the length of the string,
         and return that.  Otherwise the length is zero.  Take care to
         use SAVE_EXPR in case the OFFSET has side-effects.  */
      tree offsave = TREE_SIDE_EFFECTS (byteoff) ? save_expr (byteoff) :
byteoff;
      offsave = fold_convert (sizetype, offsave);
      tree condexp = fold_build2_loc (loc, LE_EXPR, boolean_type_node, offsave,
                                      size_int (len * eltsize));
      tree lenexp = size_diffop_loc (loc, size_int (len * eltsize), offsave);
      return fold_build3_loc (loc, COND_EXPR, ssizetype, condexp, lenexp,
                              build_zero_cst (ssizetype));


That would have the advantage, that all undefined cases including i>len and
i<0 return 0, instead of an unlimited value.  This should not have any
extra cost.

BTW: the line "tree offsave = ...;" is 81 chars long and could be split up.

I don't know how to emit a trap in the false path of COND_EXPR.
All examples I see, use gimple for that.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]