[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #21 from thutt at vmware dot com 2010-09-03 13:07 --- (In reply to comment #8) Is 'coverity' a compiler? I don't think so. Coverity is not a tool that generates code, but it does perform all the syntactic semantic analysis that a code-generating compiler will. Then, it goes beyond that with further static analysis. Do you have actual examples of *compilers* which, everything taken into account, decided to make sure this case is worth warning? That's the worst argument I've read in a long time. Do we need proof that another compiler does something before the gcc team will take it up now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #22 from manu at gcc dot gnu dot org 2010-09-03 14:06 --- (In reply to comment #21) (In reply to comment #8) Is 'coverity' a compiler? I don't think so. Coverity is not a tool that generates code, but it does perform all the syntactic semantic analysis that a code-generating compiler will. Then, it goes beyond that with further static analysis. GCC is not designed to be used as a static analysis tool. This doesn't mean it wouldn't be interesting to be able to reuse GCC analysis modules for doing that. Other compilers have shown that it is possible and a desirable feature [*]. However, GCC is not designed to be reusable, there is none working on a similar thing for GCC, and no sign that any existing GCC developer will start working on it in the near future. Unless someone new starts working on this, don't expect anything similar from GCC. [*] http://clang-analyzer.llvm.org/ Do you have actual examples of *compilers* which, everything taken into account, decided to make sure this case is worth warning? That's the worst argument I've read in a long time. Do we need proof that another compiler does something before the gcc team will take it up now? There is more work to do in GCC than people willing (or being paid) to do it, so if there is some indication that some feature may be impossible or too expensive to implement, existing GCC developers will probably focus their efforts on something else more feasible. If you can show that another compiler is able to do it in an efficient way, that shows that it is feasible. As far as I know, GCC has always been a very conservative compiler in terms of features, not a source of innovation. So yes, showing a working implementation seems to be a necessary condition (but not a sufficient one). In fact, it is common practice to check what other compilers do in order to verify a bug, and it is useful information in bug reports. I am sorry for this flamewar. I hope I clarified all the issues and the wiki [**] contains a more detailed discussion about the technical issues related to uninitialized warnings in case anyone is willing to help to solve them. [**] http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #19 from tadhunt at gmail dot com 2010-09-02 16:01 ---
This flamewar in the comments is hilarious.
To all concerned, here is a much simpler example. This does appear to be a
regression. I apologize that I cannot help fix it, as it's a really useful
feature that helps catch bugs. Hat's off to you folks working hard on gcc.
int
main(void)
{
int len, i;
for(i = 0; i 5; i++) {
printf(%d\n, len);// no warning!
len = 10;
}
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #20 from manu at gcc dot gnu dot org 2010-09-02 23:10 --- The first testcase and the second are different issues. Both of them are old, known and reported in bugzilla. None of them are trivial to fix. GCC developers would wish to make our compiler as powerful as to solve the halting problem in less than a blink. Unfortunately, time, money, and contributors willing to work on this particular problem are scarce. If you can help in some way, please do so. Otherwise, thanks for the report anyway. *** This bug has been marked as a duplicate of 18501 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-27 14:00 --- No attachment. Moreover, please try also a more recent release, in the 4.4.x series. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Version|unknown |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #2 from tstdenis at elliptictech dot com 2010-01-27 14:01
---
Here's the file [I'm getting an internal error when submitting a file]
---warning.c---
#define NULL ((void *)0)
#define OK 0
typedef struct { void *a; } state;
int init(int, state *);
int done(unsigned char *, unsigned long *, state *);
int function(unsigned char *param5, unsigned long param6)
{
state st;
unsigned char dig[128];
unsigned long y, outpos, diglen;
int err;
outpos = 0;
err= OK;
while (err == OK outpos param6) {
err = init(0, st);
if (err == OK) {
diglen = sizeof(dig);
err = done(dig, diglen, st);
}
for (y = 0; y diglen outpos param6; y++) {
param5[outpos++] = dig[y];
}
}
return err;
}
--
tstdenis at elliptictech dot com changed:
What|Removed |Added
Version|4.3.3 |unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #3 from tstdenis at elliptictech dot com 2010-01-27 14:02 --- (In reply to comment #1) No attachment. Moreover, please try also a more recent release, in the 4.4.x series. No warning from GCC 4.4.0 when using '-Wall -W -O3'. -- tstdenis at elliptictech dot com changed: What|Removed |Added Version|4.3.3 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-27 14:07 --- Yes. I'm pretty sure we have duplicates in Bugzilla. Anyway, I just tested two other high quality compilers and they don't warn either. I don't think we can reach zero negatives in this area any time soon. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2010-01-27 14:07:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2010-01-27 14:07:00 |2010-01-27 14:07:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #5 from tstdenis at elliptictech dot com 2010-01-27 14:08 --- (In reply to comment #4) Yes. I'm pretty sure we have duplicates in Bugzilla. Anyway, I just tested two other high quality compilers and they don't warn either. I don't think we can reach zero negatives in this area any time soon. If this bug is a dupe please close this as resolved/dupe. I didn't check that hard. I think this is a bug because GCC attempts to resolve whether variables are initialized or not and doesn't in this case. It's misleading to the user to suggest it can do something it clearly cannot [in this case]. -- tstdenis at elliptictech dot com changed: What|Removed |Added Version|4.3.3 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #6 from paolo dot carlini at oracle dot com 2010-01-27 14:13 --- I'm restating my point: indeed, the variable can be used uninitialized. This is not at issue. My point is that, depending on the way the compiler is internally organized, etc, you can have it warning for a larger class of cases and not warning for a larger class of non-cases, but normally you cannot obtain full accuracy. As two data points, for comparison, I told you that two other, up to date, high quality, compilers don't warn either. I'm saying, do not hold your breath on this, in principle we can, and should, make progress, but it's hard to say now how much and when. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #7 from tstdenis at elliptictech dot com 2010-01-27 14:28 --- (In reply to comment #6) I'm restating my point: indeed, the variable can be used uninitialized. This is not at issue. My point is that, depending on the way the compiler is internally organized, etc, you can have it warning for a larger class of cases and not warning for a larger class of non-cases, but normally you cannot obtain full accuracy. As two data points, for comparison, I told you that two other, up to date, high quality, compilers don't warn either. I'm saying, do not hold your breath on this, in principle we can, and should, make progress, but it's hard to say now how much and when. I take your point about false warnings, but if something like coverity can correctly identify this, it is possible. I wouldn't expect this to be fixed overnight, but part of the point is to at least report these things so developers know about them. -- tstdenis at elliptictech dot com changed: What|Removed |Added Version|4.3.3 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #8 from paolo dot carlini at oracle dot com 2010-01-27 14:37 --- Is 'coverity' a compiler? I don't think so. Do you have actual examples of *compilers* which, everything taken into account, decided to make sure this case is worth warning? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #9 from tstdenis at elliptictech dot com 2010-01-27 15:43 --- (In reply to comment #8) Is 'coverity' a compiler? I don't think so. Do you have actual examples of *compilers* which, everything taken into account, decided to make sure this case is worth warning? I wonder if there is an apathy reason to close bugs ho hum... I'm just saying that it is something that should at some point be addressed. Maybe not today, maybe not tomorrow, but soon, and for the rest of the projects life cycle. -- tstdenis at elliptictech dot com changed: What|Removed |Added Version|4.3.3 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #10 from paolo dot carlini at oracle dot com 2010-01-27 15:47 --- To be clear: nobody closed this bug, ever. And talking about apathy is plain offensive, or maybe you are just ignorant of the trade-offs involved in this area. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Version|unknown |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #11 from tstdenis at elliptictech dot com 2010-01-27 15:57 --- (In reply to comment #10) To be clear: nobody closed this bug, ever. And talking about apathy is plain offensive, or maybe you are just ignorant of the trade-offs involved in this area. I didn't say you did close the bug I said you probably should if everyone is apathetic as you appear to be. I don't care if commercial compilers miss this, GCC claims to detect this sort of bug, it doesn't, that's a bug. Furthermore, it is detectable in an automated way [e.g., coverity] so it's not like I'm asking to boil the ocean or whatever... Whether it's high priority or not [I don't think it is] is not at issue. So stop being so dismissive about it. -- tstdenis at elliptictech dot com changed: What|Removed |Added Version|4.3.3 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-27 15:59 --- You are apathetic, and your mother and son. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #13 from tstdenis at elliptictech dot com 2010-01-27 16:05 --- (In reply to comment #12) You are apathetic, and your mother and son. ` Apathy: noun, a lack of enthusiasm or emotion. Being dismissive of the bug because other compilers don't detect it either is apathetic. Irony: noun, A statement that, when taken in context, may actually mean the opposite of what is written literally; the use of words expressing something other than their literal intention, notably as a form of humor. Calling someone who took the time to file a bug report apathetic is ironic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-27 16:06 --- As diglen has its address taken and we do not warn about uninitialized use of memory we do not warn. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #15 from tstdenis at elliptictech dot com 2010-01-27 16:22 --- (In reply to comment #14) As diglen has its address taken and we do not warn about uninitialized use of memory we do not warn. I get that the compiler can't track if an external function actually initializes a value through a pointer, but the diglen = sizeof... line should be good enough for the positive case. In the false path though diglen is not initialized nor its address taken. -- tstdenis at elliptictech dot com changed: What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-01-27 16:51 --- (In reply to comment #15) (In reply to comment #14) As diglen has its address taken and we do not warn about uninitialized use of memory we do not warn. I get that the compiler can't track if an external function actually initializes a value through a pointer, but the diglen = sizeof... line should be good enough for the positive case. In the false path though diglen is not initialized nor its address taken. No, it's an implementation detail. Uninitialized variable use tracking works with detecting uses of SSA name default definitions. Memory is not in SSA form so this mechanism does not work. Uninitialized memory detection is not done at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #17 from tstdenis at elliptictech dot com 2010-01-27 17:55 --- (In reply to comment #16) No, it's an implementation detail. Uninitialized variable use tracking works with detecting uses of SSA name default definitions. Memory is not in SSA form so this mechanism does not work. Uninitialized memory detection is not done at all. Forgive me for I know not much of the GCC internals (I use GCC, I don't develop it), but are you saying that any use of address-of on a variable kicks it out of contention for unused tracking? Even if it's not on a direct path (e.g., not always executed)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-01-27 19:51 --- (In reply to comment #17) (In reply to comment #16) No, it's an implementation detail. Uninitialized variable use tracking works with detecting uses of SSA name default definitions. Memory is not in SSA form so this mechanism does not work. Uninitialized memory detection is not done at all. Forgive me for I know not much of the GCC internals (I use GCC, I don't develop it), but are you saying that any use of address-of on a variable kicks it out of contention for unused tracking? Even if it's not on a direct path (e.g., not always executed)? Yes, that's correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
