On Fri, Aug 15, 2008 at 11:31 AM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/8/15 Daniel Berlin <[EMAIL PROTECTED]>:
>> On Fri, Aug 15, 2008 at 10:58 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>>> On Fri, Aug 15, 2008 at 8:06 AM, Manuel López-Ibáñez
>>> <[EMAIL PROTECTED]> wrote:
>>>> 2008/8/14 Daniel Berlin <[EMAIL PROTECTED]>:
>>>>> 1. You can't assume VUSE's are must-aliases.  The fact that there is a
>>>>> vuse for something does not imply it is must-used, it implies it is
>>>>> may-used.
>>>>>
>>>>> We do not differentiate may-use from must-use in our alias system. You
>>>>> can do some trivial must-use analysis if you like (by computing
>>>>> cardinality of points-to set as either single or multiple and
>>>>> propagating/meeting it in the right place).
>>>>>
>>>>> Must-use is actually quite rare.
>>>>
>>>> Then, is it impossible to distinguish the following testcase and the
>>>> one from my previous mail with the current infrastructure?
>>>
>>> If by current you mean "code that already exists", then yes :)
>>> You could write code to do further analysis, but with the existing
>>> code, it will not work.
>>
>> FWIW, it is actually worse than the cases you have posited so far.
>>
>> Consider the following simple case (which are different from yours in
>> that the conditionals are not dependent on maybe uninitialized
>> variables), where you will miss an obvious warning.
>>
>> extern int foo(int *);
>> extern int bar(int);
>> int main(int argc, char **argv)
>> {
>>  int a;
>>
>>  if (argc)
>>     foo (&a)
>> /* VUSE of a will be a phi node, but it still may be used uninitialized.  */
>>  bar(a);
>> }
>>
>>
>> Realistically, to get good results, you would have to track may-use vs
>> must-use and also propagate where the default def is being used when
>> the default_def is not from a parameter.
>>
>
> The problem in the original testcase is that the default def of
> variable 'c' is a VUSE in a statement that does not even use c.
>
It may-uses c, as we've been through.

>  # BLOCK 2 freq:10000
>  # PRED: ENTRY [100.0%]  (fallthru,exec)
>  [/home/manuel/src/trunk/gcc/builtins.c : 11095] # VUSE
> <cD.68618_34(D)> { cD.68618 }
>  D.68627_3 = validate_argD.45737 (s1D.68612_2(D), 10);
>
> Moreover, if you check fold_builtin_strchr in builtins.c, it is clear
> that there is no path along which c is used uninitialized.

This is not a default def.

cD.68618_34(D) is the default def.
if you look at default_def (c) it will be a NOP_EXPR statement.

Reply via email to