This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -Wuninitialized issues
- From: Jeffrey A Law <law at redhat dot com>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 01 Nov 2005 11:02:13 -0700
- Subject: Re: -Wuninitialized issues
- References: <4365CA5E.3070401@codesourcery.com> <1130802583.19967.122.camel@localhost.localdomain> <200511011106.49922.dnovillo@redhat.com>
- Reply-to: law at redhat dot com
On Tue, 2005-11-01 at 11:06 -0500, Diego Novillo wrote:
> On Monday 31 October 2005 18:49, Jeffrey A Law wrote:
>
> > Thoughts?
> >
> I'm not sure this would buy you much better precision.
It's less about better precision as it is about catching those
cases which are hidden because of actions of the optimizers without
introducing more false positives, unless the user has explicitly
asked for them :-)
> I was tinkering with PR 18501 a few days ago.
It's worth noting that my change will catch 18501 -- without having
to twiddle the optimizers in any way shape or form.
Assembling functions:
bitmap_print_value_set
zz.c: In function 'bitmap_print_value_set':
zz.c:7: warning: 'first' may have been used uninitialized in this
function, but was later optimized away or proven always initialized
Again, all it's doing is running the "maybe uninitialized" test during
the early uninitialized warning pass and comparing the results to
the running the "maybe uninitialized" test during the late uninitialized
warning pass.
This little table summarizes the possibilities:
Marked Marked
Early Late
no no -> Variable is always initialized before its uses
no yes -> Optimization error, checking failure, abort
yes no -> Variable might have been used uninitialized, but
those uses were either deleted or some paths
through the CFG were unexecutable with the net
result being all uses in the optimized code were
initialized
yes yes -> Variable may be uninitialized before its uses
Jeff