GCC Bugzilla Bug 17993

avr-gcc-v:
Reading specs from c:/programs/WinAVR/bin/../lib/gcc/avr/3.4.1/specs
Configured with: ../gcc-3.4.1/configure --prefix=e:/avrdev/install
--build=mingw32 --host=mingw32 --target=avr --enable-languages=c,c++
Thread model: single
gcc version 3.4.1

command line:
avr-gcc -gdwarf-2 bitfieldbug.c  -o bf.elf

The debug output as shown by avr-readelf -w bf.elf shows that the first bitfield
member has a DW_AT_data_member_location of ff ff ff ff ff, which is obviously
wrong. 

This behaviour seems to persist no matter how I define the bitfield.

---source---
typedef struct
{
  int   j:5;
  int   k:6;
  int   m:5;
  int   n:8;
} faultybitfield_t; 

int main(int arcg, char **argv)
{
  faultybitfield_t bf;
  bf.j = 3;
  return 0;
}
---end source---

This has been discussed on the gcc mailinglist:
http://gcc.gnu.org/ml/gcc/2004-05/msg00186.html

From the link in comment #1, on the gcc list, from Jim Wilson:


">    DW_AT_member_location seems to consequently equal -1 (ff ff ff ff) for
the > first member of a bitfield. 


FYI You can get descriptive assembly by using the -dA option. This adds
comments that make the dwarf2 debug info readable. Gcc calls this
DW_AT_data_member_location.

The DWARF2 info comes from dwarf2out.c. Grepping for DW_AT_data_member_location
shows that it comes from the function add_data_member_location_attribute. The
offset comes from the function field_byte_offset. Looking at this code, it
seems to have a general problem on targets where TYPE_ALIGN of int is smaller
than TYPE_SIZE of int. This is true on avr where the size is 2 but the
alignment is 1. The code computes the end of the bitfield, subtracts the type
size, and then rounds up to the alignment, which gives -1 for the offset, which
is not a useful number. I would think the code would work better if we started
with the beginning of the bitfield, and then rounded down to the alignment. I'd
suggest checking the history of the code to see if there is a reason why it was
written this way. There may be an obscure reason why the code is like it is."

The issue is in field_byte_offset() in dwarf2out.c.

Can someone with Bugzilla permissions please mark this bug as NEW (confirmed)?

Bug fixed in 4.3.0 20070817 snapshot.

Fixed then.