public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* how to stop bit-field sign extension
@ 2003-09-29 19:45 Kevin Nomura
  2003-09-29 20:01 ` Falk Hueffner
  2003-09-30 11:32 ` Eljay Love-Jensen
  0 siblings, 2 replies; 4+ messages in thread
From: Kevin Nomura @ 2003-09-29 19:45 UTC (permalink / raw)
  To: gcc-help

What does it mean to have an unsigned bit-field if sign extension
can still occur in a case such as this:


[siml4]$ cat a.c
struct foo {
        unsigned int a:16;
} x;

main()
{
        unsigned long long ll;
        x.a = 0x8000;
        ll = x.a << 16;   /* (unsigned int) x.a does not help */
        printf ("%llx\n", ll);
}


[siml4]$ gcc a.c
[siml4]$ a.out
ffffffff80000000

The target of the assignment is unsigned, so the result of the shift 
of an unsigned bit field is evidently treated as signed.  

Are unsigned semantics of bit fields supported in ANSI C?
The standard mentions that bit fields can have unsigned type,
but are unsigned bit fields then allowed 'implementation
defined' behavior (meaning the unsigned-ness can be ignored)?

Replacing the 16-bit unsigned field with unsigned short avoids
the sign extension when widening to 64 bits.  So this doesn't
seem like a fundamental effect of integral promotion -- not a
consistent one, at least.


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

* Re: how to stop bit-field sign extension
  2003-09-29 19:45 how to stop bit-field sign extension Kevin Nomura
@ 2003-09-29 20:01 ` Falk Hueffner
  2003-09-30 11:32 ` Eljay Love-Jensen
  1 sibling, 0 replies; 4+ messages in thread
From: Falk Hueffner @ 2003-09-29 20:01 UTC (permalink / raw)
  To: Kevin Nomura; +Cc: gcc-help

Kevin Nomura <nomura@netapp.com> writes:

> What does it mean to have an unsigned bit-field if sign extension
> can still occur in a case such as this:
> 
> [siml4]$ cat a.c
> struct foo {
>         unsigned int a:16;
> } x;
> 
> main()
> {
>         unsigned long long ll;
>         x.a = 0x8000;
>         ll = x.a << 16;   /* (unsigned int) x.a does not help */
>         printf ("%llx\n", ll);
> }
> 
> [siml4]$ gcc a.c
> [siml4]$ a.out
> ffffffff80000000

The rule is very simple -- all values of unsigned int a:16 fit into an
int, so it is promoted to int, just like short or unsigned short are.
Therefore, you need the cast to unsigned. Unfortunately, it does not
help with gcc since due to of the most long-standing bugs in gcc
(http://gcc.gnu.org/PR3325), this cast gets ignored.  As a workaround,
try assigning the bitfield value to an unsigned variable first and
shift it then.

-- 
	Falk

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

* Re: how to stop bit-field sign extension
  2003-09-29 19:45 how to stop bit-field sign extension Kevin Nomura
  2003-09-29 20:01 ` Falk Hueffner
@ 2003-09-30 11:32 ` Eljay Love-Jensen
  2003-09-30 15:38   ` Kevin Nomura
  1 sibling, 1 reply; 4+ messages in thread
From: Eljay Love-Jensen @ 2003-09-30 11:32 UTC (permalink / raw)
  To: Kevin Nomura, gcc-help

Hi Kevin,

ll = x.a;
ll <<= 16;

HTH,
--Eljay


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

* Re: how to stop bit-field sign extension
  2003-09-30 11:32 ` Eljay Love-Jensen
@ 2003-09-30 15:38   ` Kevin Nomura
  0 siblings, 0 replies; 4+ messages in thread
From: Kevin Nomura @ 2003-09-30 15:38 UTC (permalink / raw)
  To: Eljay Love-Jensen; +Cc: Kevin Nomura, gcc-help

I added a check to c-typeck.c to find where we are assigning 
unsigned long long from signed int, and this potential problem 
is widespread in our code base, albeit not usually from bit fields.  
Thank you for the response!


On Tue, Sep 30, 2003 at 06:32:09AM -0500, Eljay Love-Jensen wrote:
> Hi Kevin,
> 
> ll = x.a;
> ll <<= 16;
> 
> HTH,
> --Eljay
> 

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

end of thread, other threads:[~2003-09-30 15:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-29 19:45 how to stop bit-field sign extension Kevin Nomura
2003-09-29 20:01 ` Falk Hueffner
2003-09-30 11:32 ` Eljay Love-Jensen
2003-09-30 15:38   ` Kevin Nomura

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).