On 9/15/18 2:43 AM, Bernd Edlinger wrote:
> Hi,
> 
> this is an update on my strlen range patch (V7).  Again re-based and
> retested to current trunk.
> 
> I am aware that Martin wants to re-factor the interface of get_range_strlen
> and have no objections against, but I'd suggest that to be a follow-up patch.
> 
> I might suggest to rename one of the two get_range_strlen functions at the
> same time as it is rather confusing to have to count the parameters in order
> to tell which function is meant.
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 
> 
> changelog-range-strlen-v7.txt
> 
> gcc:
> 2018-08-26  Bernd Edlinger  <bernd.edlin...@hotmail.de>
> 
>       * gimple-fold.c (looks_like_a_char_array_without_typecast_p): New
>       helper function for strlen range estimations.
>       (get_range_strlen): Use looks_like_a_char_array_without_typecast_p
>       for warnings, but use GIMPLE semantics otherwise.
>       * tree-ssa-strlen.c (maybe_set_strlen_range): Use GIMPLE semantics.
>       (get_min_string_length): Avoid not NUL terminated string literals.
The introduction of looks_like_a_char_array_without_typecast_p is
probably a good thing.  Too  much code is already implemented inline
within get_range_strlen.

It looks like you added handling of ARRAY_RANGE_REF.  I don't know how
often they come up in practice, but handling it seems like a reasonable
extension to what we're doing.  Bonus points if it's triggering with any
kind of consistency.

I actually prefer Martin's unification of type/fuzzy into a single
enumeration to describe the desired behavior.  Doing it with two args
where some values are mutually exclusive is just asking for trouble.
Though I like that you called out the values that are mutually exclusive.

I definitely want to look at how your patch and Martin's differ on the
handling of flexible array members -- clearly we must avoid setting a
range in that case.  I'm surprised this didn't trigger a failure in the
testsuite though.  Martin's work in this space did.

The bugfix in get_min_string_length looks like it probably stands on its
own.

I'm still evaluating the two approaches...

jeff

Reply via email to