[PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)

[Jakub Jelinek]

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

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.

	Jakub