From mboxrd@z Thu Jan  1 00:00:00 1970
From: "David A. Greene" <greened@eecs.umich.edu>
To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>, egcs@egcs.cygnus.com
Subject: Re: egcs and bitfields
Date: Fri, 12 Mar 1999 07:16:00 -0000
Message-id: <36E92F61.5951621@eecs.umich.edu>
References: <36E844B2.8DAEFAAF@eecs.umich.edu> <199903112300.AAA19947@mira.isdn.cs.tu-berlin.de>
X-SW-Source: 1999-03/msg00454.html

Martin v. Loewis wrote:
> 
> > I sent this question to the list a few days ago but got
> > no response.  Can someone please help me out?
> 
> I think the problem with your previous report was that it was hard to
> understand. I tried to come up with a program that demonstrates your
> problem, and I got
> 
> struct baz { unsigned int a:2, b:4, c:32;} y;
> 
> void foo()
> {
>   y.c = 0x56789;
> }
> 
> int main()
> {
>   unsigned int  *b;
>   bzero(&y,sizeof(y));
>   foo();
>   b=&y;
>   printf("%x %x\n",b[0],b[1]);
> }
> 
> Is this the case you are talking about? Now, you claim that the SysV
> ABI requires y.c to be at offset 4, right? (this is a claim I can't
> verify since I don't have that specification)
> 
> Anyway, when I run the program on i586-pc-linux-gnu, with
> egcs-2.93.11, I get as output
> 
> 0 56789
> 
> >From your explanation, I understand that this result is
> ABI-compliant. So where is the problem?

>From this example, things look right.  Let me check my example
again.  Maybe I goofed!

Oh boy...It appears as though "gcc" on our machines has magically become
gcc-2.7.2.3 rather than egcs-1.1.1 as it used to be.  egcs in fact
functions correctly.  gcc-2.7.2.3 does not.

Our sysadmins will be hearing about this...  >:-[

Sorry to bother everyone with this "problem."

However, the signedness problem still seems to be there:

#include <stdio.h>

struct foo { int c:3; } x = { 7 };

int main(void)
{
  printf("%d\n", x.c);

  return(0);
}

>>-drakh-> egcc fieldinit.c
>>-drakh-> ./a.out
-1

I think the output should be 7, since an "int"
 bitfield is supposed
to be unsigned according to the i386 SysV ABI.

>>-drakh-> egcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/specs
gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)


                                            -Dave

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "David A. Greene" <greened@eecs.umich.edu>
To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>, egcs@egcs.cygnus.com
Subject: Re: egcs and bitfields
Date: Wed, 31 Mar 1999 23:46:00 -0000
Message-ID: <36E92F61.5951621@eecs.umich.edu>
References: <36E844B2.8DAEFAAF@eecs.umich.edu> <199903112300.AAA19947@mira.isdn.cs.tu-berlin.de>
X-SW-Source: 1999-03n/msg00458.html
Message-ID: <19990331234600.IWkD0c2qpEnMFwNCEKfunXVhdnFsCS6K3Mraj_uEpGg@z>

Martin v. Loewis wrote:
> 
> > I sent this question to the list a few days ago but got
> > no response.  Can someone please help me out?
> 
> I think the problem with your previous report was that it was hard to
> understand. I tried to come up with a program that demonstrates your
> problem, and I got
> 
> struct baz { unsigned int a:2, b:4, c:32;} y;
> 
> void foo()
> {
>   y.c = 0x56789;
> }
> 
> int main()
> {
>   unsigned int  *b;
>   bzero(&y,sizeof(y));
>   foo();
>   b=&y;
>   printf("%x %x\n",b[0],b[1]);
> }
> 
> Is this the case you are talking about? Now, you claim that the SysV
> ABI requires y.c to be at offset 4, right? (this is a claim I can't
> verify since I don't have that specification)
> 
> Anyway, when I run the program on i586-pc-linux-gnu, with
> egcs-2.93.11, I get as output
> 
> 0 56789
> 
> >From your explanation, I understand that this result is
> ABI-compliant. So where is the problem?