[Bug exp/14558] New: Incorrect handling of bitfield type

["pkoning at equallogic dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=14558

             Bug #: 14558
           Summary: Incorrect handling of bitfield type
           Product: gdb
           Version: 7.3
            Status: NEW
          Severity: normal
          Priority: P2
         Component: exp
        AssignedTo: unassigned@sourceware.org
        ReportedBy: pkoning@equallogic.com
    Classification: Unclassified


Created attachment 6628
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6628
test program

I ran into a case where data taken from an unsigned bitfield was unexpectedly
sign extended, so I made up a test case that demonstrates this.

My theory was that a bitfield declared as "unsigned long long" but less than 32
bits long shouldn't be sign extended when it is shifted left and assigned to an
unsigned long long variable.

Andrew Pinski set me straight on the GCC list (quoting here first my comment
and then his reply):

>>Since the underlying type of field f2 is unsigned long long, I would not expect >>the expression "test.f2 << 16" to do sign extending of a 32 bit intermediate >>result.  But that is in fact what GCC produces, for x86_64-linux (gcc 4.7.0).
>>
>>If I explicitly cast test.f2 to unsigned long long before the shift, the >>expected result appears.  But I shouldn't have to do that cast, given that the >>type of f2 is already unsigned long long, correct?
>
>The type of  "test.f2" is a 31 bit unsigned integer (the declared type
>is used for alignment) and that fits in a 32bit signed integer so when
>doing test.f2 << 16, it is promoted to only an 32bit signed integer.

So the answer is that the compiler is doing the right thing and my testcase is
wrong.

However, GDB doesn't work this way.  Instead, it *does* assume that the type of
the bitfield is the type of its declaration, as opposed to following the logic
Andrew outlined.  To see this, compile the test program, and ask it to print
test.f2 << 16.  It will print 0x80000000 and will report that the type of that
value is unsigned long long int.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.