Bug 229459 - useless warning using anonymous bitfield
useless warning using anonymous bitfield
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2007-02-21 05:31 EST by Roland McGrath
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-21 09:29:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test function to compile (232 bytes, text/plain)
2007-02-21 05:31 EST, Roland McGrath
no flags Details
Patch that fixes the bug by silencing the warning (2.69 KB, patch)
2007-03-05 02:35 EST, Alexandre Oliva
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 30913 None None None Never

  None (edit)
Description Roland McGrath 2007-02-21 05:31:39 EST
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.gcc -O2 -Wall -S uninit-anon-bitfield.c
Actual results:

uninit-anon-bitfield.c: In function 'foo':
uninit-anon-bitfield.c:18: warning: 'tmp.<U48fc>' is used uninitialized in this

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.
Comment 1 Roland McGrath 2007-02-21 05:31:40 EST
Created attachment 148471 [details]
test function to compile
Comment 2 Jakub Jelinek 2007-02-21 09:29:36 EST
A SRA bug.  Tracking this upstream, as it affects upstream 4.1/4.2/4.3 as well.
Comment 3 Alexandre Oliva 2007-03-05 02:35:11 EST
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 ( in C99-TC2).

Note You need to log in before you can comment on or make changes to this bug.