[Bug c/42884] New: GCC (v4.3.3) fails to detect uninitialized variable

[Bug c/42884] New: GCC (v4.3.3) fails to detect uninitialized variable

[tstdenis at elliptictech dot com]

GCC fails to detect an unitialized variable in a function.  In the attached
code [warning.c] it fails to detect that 'diglen' could be unitialized by time
the 'for' loop is encountered.


-- 
           Summary: GCC (v4.3.3) fails to detect uninitialized variable
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tstdenis at elliptictech dot com


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]

------- 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]

-- 

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

[tstdenis at elliptictech dot com]

------- 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

[tstdenis at elliptictech dot com]

------- 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

[paolo dot carlini at oracle dot com]

------- 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|0000-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]

-- 

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

[tstdenis at elliptictech dot com]

------- 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

[paolo dot carlini at oracle dot com]

------- 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

[tstdenis at elliptictech dot com]

------- 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

[paolo dot carlini at oracle dot com]

------- 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

[tstdenis at elliptictech dot com]

------- 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

[paolo dot carlini at oracle dot com]

------- 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

[tstdenis at elliptictech dot com]

------- 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

[paolo dot carlini at oracle dot com]

------- 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

[tstdenis at elliptictech dot com]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[tstdenis at elliptictech dot com]

------- 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]

-- 

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

[rguenth at gcc dot gnu dot org]

------- 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

[tstdenis at elliptictech dot com]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable

[tadhunt at gmail dot com]

------- 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

[manu at gcc dot gnu dot org]

------- 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

[thutt at vmware dot com]

------- 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

[manu at gcc dot gnu dot org]

------- 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