public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug exp/14558] New: Incorrect handling of bitfield type
@ 2012-09-07 19:03 pkoning at equallogic dot com
  2020-04-11 13:37 ` [Bug exp/14558] " ssbssa at sourceware dot org
  0 siblings, 1 reply; 2+ messages in thread
From: pkoning at equallogic dot com @ 2012-09-07 19:03 UTC (permalink / raw)
  To: gdb-prs

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.


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug exp/14558] Incorrect handling of bitfield type
  2012-09-07 19:03 [Bug exp/14558] New: Incorrect handling of bitfield type pkoning at equallogic dot com
@ 2020-04-11 13:37 ` ssbssa at sourceware dot org
  0 siblings, 0 replies; 2+ messages in thread
From: ssbssa at sourceware dot org @ 2020-04-11 13:37 UTC (permalink / raw)
  To: gdb-prs

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

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-04-11 13:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-07 19:03 [Bug exp/14558] New: Incorrect handling of bitfield type pkoning at equallogic dot com
2020-04-11 13:37 ` [Bug exp/14558] " ssbssa at sourceware dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).