https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 14 Jan 2019, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 > > --- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #12) > > On Fri, 11 Jan 2019, msebor at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 > > > > > > --- Comment #11 from Martin Sebor <msebor at gcc dot gnu.org> --- > > > I understand what jump threading does but I don't know enough about how it > > > works to have a clear idea how viable marking up the created statements > > > would > > > be. > > > > Jump threading just makes existing paths explicit, thus path sensitive > > analysis would come up with similar answers. There may be cases where > > we could prove such paths are unreachable and fail to do so, but the > > cases where the path ends up in this kind of "undefined" builtin call > > do not count IMHO because it is exactly those cases we want to warn > > about - so we cannot really reason they cannot happen because of that. > > Sure, but the warnings we are talking about typically don't warn about calls > (etc.) that can overflow, but nothing is known about the value ranges of those > arguments. Because then we'd need to warn about void foo (char *x, char *y, > unsigned long z) { __builtin_strncpy (x, y, z); } which indeed can overflow if > user passes wrong arguments. We'd just warn all the time about that though > and > the warning wouldn't be useful at all. Well, the question is then whether you want to live with false negatives or false positives... I thought from all the attempts to prevent early folding that we rather want false positives. Otherwise just fold all undefined stuff to __builtin_trap().
