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.
# 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.
Cheers,
Manuel.
