Description of problem: Version-Release number of selected component (if applicable): gcc-4.1.1-51.fc5 How reproducible: 100% Steps to Reproduce: 1.gcc -O2 -Wall -S uninit-anon-bitfield.c 2. 3. Actual results: uninit-anon-bitfield.c: In function 'foo': uninit-anon-bitfield.c:18: warning: 'tmp.<U48fc>' is used uninitialized in this function Expected results: No warning, or at least a warning without a bogus field name. Additional info: In the case of an anonymous bitfield used for padding, there is no way the field could be initialized. There can be no harm from copying an uninitialized value there, unless the target were part of a union that could access those bits in another way. At the very least, the warning is confusing because it names the field with an internal identifier. But really, there should be no warning when there is no way to avoid it.
Created attachment 148471 [details] test function to compile
A SRA bug. Tracking this upstream, as it affects upstream 4.1/4.2/4.3 as well.
Created attachment 149247 [details] Patch that fixes the bug by silencing the warning It is simple enough to silence the warning. Optimizing the code generated by the compiler when the bitfields are scalarized is much harder, not only in general (http://gcc.gnu.org/PR22156), but also for padding bitfields, considering that padding bits *must* be copied unless the entire byte is a padding byte (6.2.6.1/6 in C99-TC2).