This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, tree-ssa] Avoid -Wuninitialized warning in try_unroll_loop_completely()
- From: Jeff Law <law at redhat dot com>
- To: Chung-Ju Wu <jasonwucj at gmail dot com>
- Cc: gcc patches <gcc-patches at gcc dot gnu dot org>, dnovillo at google dot com, amacleod at redhat dot com
- Date: Wed, 17 Apr 2013 14:23:22 -0600
- Subject: Re: [PATCH, tree-ssa] Avoid -Wuninitialized warning in try_unroll_loop_completely()
- References: <CADj25HPE6ZVONBykpxC2tE0pYOx28=j9H+5cpt8ds2=jma63Wg at mail dot gmail dot com> <516C0943 dot 5080400 at redhat dot com> <CADj25HOHjO54d6+fmdawjz+2j1VOn0aWarW3EAX03VFgCNcgrA at mail dot gmail dot com>
On 04/15/2013 08:35 PM, Chung-Ju Wu wrote:
Thanks for checking on this stuff. My preference would be to not add
the initialization unless we're currently seeing false positive warnings
with the trunk.
You are right.
After doing survey on http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
and reading related discussion thread, I realized it is a
complicated detection and this is a false positive case.
I was using gcc-4.6.3, which is provided by Ubuntu 12.04,
and the warning is displayed during the compilation process.
As I tried to build another native gcc by myself with
current main trunk and used it to compile tree-ssa-loop-ivcanon.c again,
there is no such warning at all.
(See attachment for my console output.)
So I am wondering if my patch is still valuable since
such false positive warning is already fixed on trunk.
Anytime we add a dummy initialization like this to avoid a false
positive, we run the risk of missing real bugs later if the nearby code
is changed in such a way as to expose an uninitialized use, which we'd
like to catch, but can't if we're inserted a dummy initialization.