GCC has gone mad

In my July post I praised the GCC ability to detect uninitialized variables, but now it seems I have to take this praise back. We discovered several cases of false negatives (i.e. missing warnings) about uninitialized variables in GCC 4.5.1 that look like regressions from the behavior of GCC 4.4.4 or perhaps were not detected even by the older version.

Make your own picture of the situation. The following is an example of one use of an uninitialized variable that goes undetected by the new GCC at the -O3 optimization level:

312 static int packet_reply(const packet_t packet)
313 {
314         ipc_callid_t callid;
315         size_t size;
316 
317         if (!packet_is_valid(packet))
318                 return EINVAL;
319 
320          if (size != packet->length)
321                  return ENOMEM;

And yes, packet is valid and line 320 is being reached. This and other examples can be found here:

• Comparison with an uninitialized variable,
• Passing an uninitialized variable to another function,
• Function leaves its output argument uninitialized.
  

On the web I found the GCC meta-bug for these and related issues and it looks like this is currently a big problem in GCC. Perhaps I would get more warnings if I first built with -O. That's possible, maybe. But I don't want to run the compilation twice. I don't like arguments that say if we detected uninitialized variables more reliably, the compilation would get slower. I can wait a little longer if I get reliable warnings.