[cfe-commits] r159620 - in /cfe/trunk: lib/Analysis/UninitializedValues.cpp test/Sema/uninit-variables.c

[Richard Smith]

On Tue, Jul 3, 2012 at 1:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de>wrote:

> On Mon, Jul 02, 2012 at 11:23:05PM -0000, Richard Smith wrote:
> > Log:
> > -Wuninitialized: assume that an __attribute__((returns_twice)) function
> might
> > initialize any variable. This is extremely conservative, but is
> sufficient for
> > now.
>
> Can this be reduced to following both code paths if the function call is
> part of a conditional?


I'm not sure what you're suggesting; we do follow both code paths after a
conditional. If you mean that we should track whether the function returned
a nonzero value, and not apply this logic in that case, then I think that's
out of scope for this check, and belongs in the static analyzer (if
anywhere).


> When I analysed the newly triggered warnings for
> -Wuninitialized in NetBSD, setjmp usage was something like 50%
> questionable w.r.t. conditional initialisation, so getting this more
> strict or optional is definitely a good idea.


If we want to make this smarter, I think the way to approach it is to find
variable initializations which are reachable from the returns_twice call
(optionally only looking at ones where there is a function call
afterwards), and to assume that all relevant variables are initialized by
the setjmp call. But we would need to find an inexpensive way of computing
this information. Perhaps a reasonable tradeoff would be to compute a set
of variables which are initialized anywhere within the function, and to
assume that setjmp initializes them all.

It might also be valuable to separate the setjmp case (which needs this
special handling) from the fork case (which does not), but we don't
currently have attributes to track that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120703/0a29b2f7/attachment.html>