Compile this code with -O2 -Wall on 4.0.x or mainline: ------------------------------------- struct testme { int testval; int unusedval; }; extern void forget (struct testme forgotten); int main () { struct testme testarray[1]; struct testme testvar; testvar.testval = 0; testarray[0] = testvar; forget (testarray[0]); return 0; } -------------------------------------- This will give this warning: unused.c:13: warning: ‘testvar.unusedval’ is used uninitialized in this function The problem is the copy of some uninitialized part. Yes, it does copy something uninitialized, but that's okay, as long as it is not really accessed. At the very least it should only be a "may be used uninit" warning. This is only noticed by tree-sra. With -fno-tree-sra there's no warning. So, in effect, accesses to uninitialized parts for purpose of copying should not lead to such warning.
but isn't that the same as (except it is an aggregate in the case in comment #1): void g(int); void f(void) { int i; g(i); } because g might not look at the agrument value?
Hmm, sort of. The call of g(i) also warns with "is used", although I think it might deserve only a "may be used". But anyway I think that this nevertheless has different causes. It's not the call creating the problem, but the copy itself. On could for instance delete the call and instead make 'testarray' volatile (so that the copy is not optimized away). This would still warn, IMHO incorrectly. What's even stranger is, that if I add a call "forget(testvar)" then the warning vanishes. I.e. like so: ------------------------------------- int main() { struct testme volatile testarray[1]; struct testme testvar; testvar.testval = 0; testarray[0] = testvar; forget (testvar); return 0; } ------------------------------------- So this shows that not the call on a partly initialized struct is the problem (because that is still the case with the above), but something in SRA dealing with the copy. If one removes the call to forget above the warning will return (note the added volatile) on the copy.
In the case of g(i) you have an initialisation of the parameter variable which already constitutes a use of the value.
(In reply to comment #2) > Hmm, sort of. The call of g(i) also warns with "is used", although I > think it might deserve only a "may be used". But anyway I think that > this nevertheless has different causes. It's not the call creating > the problem, but the copy itself. yes, how a is copy not a use? At the very list, on modern architectures, it implies memory->register->memory traffic of garbage data.
This is an interaction between SRA deciding to create separate variables for testval and unusedval because of the copy and DCE deciding whether to remove all references to unusedval because of the call. The copy is an use, but if the result is not used, then DCE removes it and the warning goes away. If you pass something to a function, that is an use. In particular, the BLOCK is not conditional and there is no PHI node: so the uninitialized value "is used". GCC does not warn for forget(testvar) because SRA is not applied there and hence GCC does not know whether elements of testvar are uninitialized. Ideally, we should warn in all cases or in none. I would rather warn in all cases as we do for simple variables. If testvar is completely uninitialized and passed to a function, we should definitely get a warning. Anyway, this will be hard to get right because we would need to look within structures. This is more an enhancement request.
Clearly the warning is correct, a copy is a use, you do not initialize testvar.unusedval but use it when assigning testvar to testarray[0].