On 02/20/2018 05:14 PM, Jakub Jelinek wrote: > On Tue, Feb 20, 2018 at 04:59:12PM -0700, Martin Sebor wrote: >>> It would help if you explained why you think it is a good idea >>> ignoring the other phi arguments if you have one (or more) where you can >>> determine length. >> >> It's a heuristic that was meant just for the -Wformat-overflow >> warning. When making decisions that affect code generation it's >> obviously not correct to ignore the possibility that unknown >> arguments may be shorter than the minimum or longer than >> the maximum. The fuzzy argument was meant to differentiate >> between two got but I forgot about it when I added the fix >> for PR 83671. > > get_range_strlen (the 2 argument one) is right now called: > 3 times from builtins.c for -Wstringop-overflow > once from gimple-ssa-sprintf.c for -Wformat-overflow > once from tree-ssa-strlen.c for -Wstringop-truncation > once from gimple-fold.c for gimple_fold_builtin_strlen value ranges Presumably it's the last one that's causing problems and were we should focus our effort.
> > So, which of these do you want the heuristics for? All 3 warnings, > just one of them, something else? In the 2 patches I've posted last > all the 3 different warnings are treated the same (fuzzy == 2). > > Looking at strlenopt-40.c testcase, in the test you clearly rely on > fuzzy argument being set for the value ranges case > (gimple_fold_builtin_strlen), otherwise many of the > subtests would fail. Which tests specifically? I did a real quick scan and didn't see anything in there that depended on incorrect behavior for the call from gimple_fold_builtin_strlen. BUt it was a quick scan and I could have missed something. jeff