-Wuninitialized

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

-Wuninitialized

Ted Kremenek
I am soliciting opinions about what to do about -Wuninitialied.  Clang currently doesn't implement it.  It does, however, have:

(1) A simple flow-sensitive uninitialized values dataflow analysis in libAnalysis (currently usable as part of the static analyzer)

(2) Path-sensitive checking for uninitialized values in the static analyzer.  This is far more precise than what GCC does at -Wuninitialized.

I have heard numerous requests for -Wuninitialized, and other requests to have it run even at -O0 (which gcc does not do since -Wuninitialized is implemented as part of the optimizer).  The question is that given (2) should we implement -Wuninitialized at all?  If so, does (1) seem like a reasonable solution?

More details about (1):

(a) Not heavily performance optimized, but it that can be done over time

(b) Doesn't check field values; does a simple flow-sensitive analysis of variables within a function

(c) Sometimes GCC gets some amount of inter-procedural analysis with -Wuninitialized because of the inliner.  This is something we wouldn't consider doing in Clang.  For true inter-procedural uninitialized values checking, I prefer that to be (one day) in the static analyzer.

Thoughts?  Should we hook -Wuninitialized up to (1)?
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -Wuninitialized

Chris Lattner

On Mar 9, 2010, at 2:33 PM, Ted Kremenek wrote:

> I am soliciting opinions about what to do about -Wuninitialied.  Clang currently doesn't implement it.  It does, however, have:
>
> (1) A simple flow-sensitive uninitialized values dataflow analysis in libAnalysis (currently usable as part of the static analyzer)
>
> (2) Path-sensitive checking for uninitialized values in the static analyzer.  This is far more precise than what GCC does at -Wuninitialized.
>
> I have heard numerous requests for -Wuninitialized, and other requests to have it run even at -O0 (which gcc does not do since -Wuninitialized is implemented as part of the optimizer).  The question is that given (2) should we implement -Wuninitialized at all?  If so, does (1) seem like a reasonable solution?
>
> More details about (1):
>
> (a) Not heavily performance optimized, but it that can be done over time
>
> (b) Doesn't check field values; does a simple flow-sensitive analysis of variables within a function
>
> (c) Sometimes GCC gets some amount of inter-procedural analysis with -Wuninitialized because of the inliner.  This is something we wouldn't consider doing in Clang.  For true inter-procedural uninitialized values checking, I prefer that to be (one day) in the static analyzer.


I think that #1 could be very useful, particularly if it runs fast.  To me, it is more important that it behave predictably and catch the obvious cases than it is for it to be super tricky and catch uses in inlined functions etc like GCC tries to do.

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -Wuninitialized

Daniel Dunbar
On Tue, Mar 9, 2010 at 2:39 PM, Chris Lattner <[hidden email]> wrote:

>
> On Mar 9, 2010, at 2:33 PM, Ted Kremenek wrote:
>
>> I am soliciting opinions about what to do about -Wuninitialied.  Clang currently doesn't implement it.  It does, however, have:
>>
>> (1) A simple flow-sensitive uninitialized values dataflow analysis in libAnalysis (currently usable as part of the static analyzer)
>>
>> (2) Path-sensitive checking for uninitialized values in the static analyzer.  This is far more precise than what GCC does at -Wuninitialized.
>>
>> I have heard numerous requests for -Wuninitialized, and other requests to have it run even at -O0 (which gcc does not do since -Wuninitialized is implemented as part of the optimizer).  The question is that given (2) should we implement -Wuninitialized at all?  If so, does (1) seem like a reasonable solution?
>>
>> More details about (1):
>>
>> (a) Not heavily performance optimized, but it that can be done over time
>>
>> (b) Doesn't check field values; does a simple flow-sensitive analysis of variables within a function
>>
>> (c) Sometimes GCC gets some amount of inter-procedural analysis with -Wuninitialized because of the inliner.  This is something we wouldn't consider doing in Clang.  For true inter-procedural uninitialized values checking, I prefer that to be (one day) in the static analyzer.
>
>
> I think that #1 could be very useful, particularly if it runs fast.  To me, it is more important that it behave predictably and catch the obvious cases than it is for it to be super tricky and catch uses in inlined functions etc like GCC tries to do.

Yes. IMHO, the compiler should
  (1) definitely support -Wuninitialized, at -O0 (I have heard from
numerous developers who compile at -O1 for this sole reason)
  (2) the implementation should be deterministic, and easily
explainable. That is, it should be easy to predict when writing code
whether the developer needs to explicitly initialize something because
it is a "tricky" case. Something along the lines of, all uses should
be statically dominated by a def or an escape, along all paths. This
is relatively cheap to compute, given the other existing
infrastructure.

Things like checking field values I see as value add.

 - Daniel

>
> -Chris
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -Wuninitialized

Douglas Gregor
In reply to this post by Chris Lattner

On Mar 9, 2010, at 2:39 PM, Chris Lattner wrote:

>
> On Mar 9, 2010, at 2:33 PM, Ted Kremenek wrote:
>
>> I am soliciting opinions about what to do about -Wuninitialied.  Clang currently doesn't implement it.  It does, however, have:
>>
>> (1) A simple flow-sensitive uninitialized values dataflow analysis in libAnalysis (currently usable as part of the static analyzer)
>>
>> (2) Path-sensitive checking for uninitialized values in the static analyzer.  This is far more precise than what GCC does at -Wuninitialized.
>>
>> I have heard numerous requests for -Wuninitialized, and other requests to have it run even at -O0 (which gcc does not do since -Wuninitialized is implemented as part of the optimizer).  The question is that given (2) should we implement -Wuninitialized at all?  If so, does (1) seem like a reasonable solution?
>>
>> More details about (1):
>>
>> (a) Not heavily performance optimized, but it that can be done over time
>>
>> (b) Doesn't check field values; does a simple flow-sensitive analysis of variables within a function
>>
>> (c) Sometimes GCC gets some amount of inter-procedural analysis with -Wuninitialized because of the inliner.  This is something we wouldn't consider doing in Clang.  For true inter-procedural uninitialized values checking, I prefer that to be (one day) in the static analyzer.
>
>
> I think that #1 could be very useful, particularly if it runs fast.  To me, it is more important that it behave predictably and catch the obvious cases than it is for it to be super tricky and catch uses in inlined functions etc like GCC tries to do.

+1

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev