Bug 31181 - invalid warning that a variable is being used before being initialized
invalid warning that a variable is being used before being initialized
Status: RESOLVED DUPLICATE of bug 17506
Product: gcc
Classification: Unclassified
Component: middle-end
4.1.2
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-15 03:07 UTC by ahs3
Modified: 2007-04-03 06:19 UTC (History)
7 users (show)

See Also:
Host: ia64-linux-gnu-gcc
Target: ia64-linux-gnu-gcc
Build: ia64-linux-gnu-gcc
Known to work:
Known to fail:
Last reconfirmed:


Attachments
code snippet showing the problem (408 bytes, text/plain)
2007-03-15 03:11 UTC, ahs3
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ahs3 2007-03-15 03:07:45 UTC
While compiling uClibc, I saw a warning and narrowed it down.  When I use this invocation of gcc 4.1.2 (on Debian sid):

$ gcc -c short_des.c -Wall -Os -fno-tree-dominator-opts

I get the following warning:

short_des.c: In function '__des_crypt':
short_des.c:7: warning: 'f' may be used uninitialized in this function

In the attached code snippet, there is no 'f' even defined in __des_crypt(), and the 'f' being referred to is in a function do_des() that is called from __des_crypt().  Further, the warning is incorrect even within do_des() -- it is being set before being used within a loop that will always execute at least 16 times.

This warning does not occur in 4.3.0, so it has been fixed since then; whether it makes sense to fix it in further 4.1 versions is not clear to me.  It's not critical, and the workaround is very straightforward (add an initialization to 'f', in this case).
Comment 1 ahs3 2007-03-15 03:11:54 UTC
Created attachment 13207 [details]
code snippet showing the problem

This file originally came from libcrypt/des.c from the uClibc project.  I cut out everything I could to try to narrow down the issue; you might be able to reduce it further.
Comment 2 Andrew Pinski 2007-04-03 06:19:45 UTC
>it is being set before being used within a loop that will always execute at least 16 times. 
And the compiler does not know it can be executed at least once as -Os -fno-tree-dominator-opts turns off jump threading and header loop copy (though I am thinking about a special loop header copy for -Os is needed for cases where the loop header goes conditionally down to nothing).

The reason why the warning is gone in 4.3.0 is because it is able to figure out in this case f will always be zero.

PR 17506 is the bug about the uninitialized warning being in the wrong place.

So I think I can close this as a dup of bug 17506

*** This bug has been marked as a duplicate of 17506 ***