I'm getting a failure on
./gcc/testsuite/c-c++-common/asan/strncpy-overflow-1.c with the latest
patch. Unsure if it's related; we're not doing any pointer arithmetic
there.
I'll test it again on trunk without the patch and see what happens.
-Manish
On Thu, Jun 30, 2016 at 7:18 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Thu, Jun 30, 2016 at 3:38 PM, Marc Glisse <marc.gli...@inria.fr> wrote:
>> On Thu, 30 Jun 2016, Manish Goregaokar wrote:
>>
>>> Alright, the following patch was tested and it works
>>>
>>> diff --git a/gcc/fold-const.c b/gcc/fold-const.c
>>> index 3b9500d..0d82018 100644
>>> --- a/gcc/fold-const.c
>>> +++ b/gcc/fold-const.c
>>> @@ -13199,6 +13199,9 @@ tree_binary_nonzero_warnv_p (enum tree_code code,
>>> switch (code)
>>> {
>>> case POINTER_PLUS_EXPR:
>>> + return flag_delete_null_pointer_checks
>>> + && (tree_expr_nonzero_warnv_p (op0, strict_overflow_p)
>>> + || tree_expr_nonzero_warnv_p (op1, strict_overflow_p));
>>> case PLUS_EXPR:
>>> if (ANY_INTEGRAL_TYPE_P (type) && TYPE_OVERFLOW_UNDEFINED (type))
>>> {
>>
>>
>> So, what prevents us from deciding that p+(0-p) is nonzero when p is? Not
>> sure if it is strictly legal in all languages, but I wouldn't be surprised
>> if there was at least one language where optimizations could lead to such
>> expressions.
>>
>> I think this is an exciting optimization, but I was always too scared to try
>> anything like this.
>
> ;)
>
> points-to analysis already has the constraint that POINTER_PLUS_EXPR cannot
> leave the object op0 points to. Of course currently nothing uses the
> fact whether
> points-to computes pointed-to as nothing (aka NULL) - so the argument
> may be moot.
>
> Anyway, one of my points to the original patch was that POINTER_PLUS_EXPR
> handling should be clearly separate from PLUS_EXPR and that we have
> flag_delete_null_pointer_checks to allow targest to declare that 0 is a valid
> object pointer (and thus you can do 4 + -4 and reach NULL).
>
> Richard.
>
>> --
>> Marc Glisse
