GCC Bugzilla – Bug 42561
missing uninitialized variable warning on simple arrays
Last modified: 2010-10-18 22:37:46 UTC
in the attached testcase, both GCC 4.5.20091214 and GCC 4.4.1 on Ubuntu 9.10 miss the uninitialized use warnings specified in the comments. it does correct catch the simple byte variable base, as noted in the comments.
Created attachment 19428 [details]
to replicate (-O3 is required, would be nice if it just worked with -O2):
g++ -O3 -Wall -c gcc-missing-uninit.cpp
Well with: int32_t actuallyRead = read(&v, SIZE_OF_BYTE);
And inlining turned on all the way, this:
if (toRead < 1)
memcpy(data, _totPtr, toRead);
*_totPtr = *data;
which in turn becomes:
* _totPtr = v;
So the issue is more complex and GCC needs uninitialized warning for memcpy and arrays (and array SSA).
Most compilers don't implement array SSA really. I Know of only two that do, Jikes VM (IBM's Java JIT compiler) and another one which I forget about but it is also a JIT IIRC.
Created attachment 19432 [details]
slightly different example that eliminates heap dependency
g++ -O3 -Wall gcc-missing-uninit.cpp
gives 1 warning
should give 3 warnings, as noted in comments
It seems like this analysis would succeed if the intrinsic memcpy for copying the  and  were inlined before this analysis. Is there a reason that the intrinsic version of memcpy isn't substituted in before this analysis is done? Am I missing something else?
What would be the implementation steps to fix this issue?
(In reply to comment #4)
> What would be the implementation steps to fix this issue?
1) Create a small self-contained testcase
2) Examine the dumps (-fdump-tree- options) and debug the compiler to know exactly why the warning is missing. Typical cases are common constant propagation, not enough alias information, not enough optimization, too much optimization, and bugs.
3) Propose a way to fix the above problem that does not regress on optimization.
4) Send a patch to gcc-patches (http://gcc.gnu.org/contribute.html)
Any of those steps would help. Unfortunately, they have to be done in order.
Before confirming this, we would need to do (2), and we don't even have (1).
Note that uninitialized warnings on memory are severely limited by design.
It's not hard to improve that but it will be very costly in terms of compile-time.
Re-tested on 188.8.131.5201004 and the issue remains.