Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478, take 2 and 3)

[Jeff Law <law@redhat.com>]

On 02/20/2018 02:34 PM, Jakub Jelinek wrote:
> On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote:
>> A safer and even more conservative alternative that should be
>> equivalent to your approach while avoiding the sprintf regressions
>> is to add another mode to the function and have it clear *minlen
>> as an option.  This lets the strlen code obtain the conservative
>> lower bound without compromising the sprintf warnings.
> 
> I fail to see what it would be good for to set *MINLEN to zero and
> *MAXLEN to all ones for the non-warning use cases, we simply don't know
> anything about it, both NULL_TREEs i.e. returning false is better.  I'm
> offering two alternate patches which use
> fuzzy == 0 for the previous !fuzzy, fuzzy == 1 for conservatively correct
> code that assumes strlen can't cross field/variable boundaries in
> compliant programs and fuzzy == 2 which does that + whatever the warning
> code wants.  Additionally, I've rewritten the COND_EXPR handling, so that
> it matches exactly the PHI handling.
> 
> The first patch doesn't change the 2 argument get_range_strlen and changes
> gimple_fold_builtin_strlen to use the 6 argument one, the second patch
> changes also the 2 argument get_range_strlen similarly to what you've done
> in your patch.
> 
> Tested on x86_64-linux and i686-linux, ok for trunk if it passes
> bootstrap/regtest?  Which one?
Just to be clear, the encapsulation proposal is a gcc-9 thingie.  I
don't think we need that to move forward.

jeff