This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)
On February 21, 2018 4:25:14 AM GMT+01:00, Jeff Law <law@redhat.com> wrote:
>On 02/20/2018 04:59 PM, 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.
>>
>> For GCC 8 I don't have a preference for how to fix this as long
>> as it doesn't regress the warning tests.
>>
>> I think the ultimate solution (for GCC 9) may be to either
>> disable the heuristic for code generation purposes (e.g., via
>> another argument/flag) or provide a pointer argument to indicate
>> to the caller that the minimum is based on known strings, and that
>> the real minimum may be zero.
>I'm still getting refamiliar with this code. But one thing that jumps
>out immediately is how much this reminds me of the discussion we had
>around 77608 -- where I argued that returning something that was not
>conservatively correct was just asking for long term problems.
>
>I realize we're talking about different routines, but the concerns are
>the same -- when we return something that is not conservatively correct
>it's easy for someone to mistakenly use those results for code
>generation purposes.
>
>The fuzzy stuff is in there to reduce the false positive rates and
>we're
>not *supposed* to be using fuzzy results for code generation purposes,
>but as I argued in 77608, it's easy to miss.
>
>I'll reiterate my desire to make this kind of mistake harder to make.
Can you simply provide that interface via a separately named API rather than overloading one that is also supposed to be used by optimization?
Richard.
>Jeff