[Bug c/17211] New: [sparc/i386]: Bitfields should be *unsigned* by default.

[Bug c/17211] New: [sparc/i386]: Bitfields should be *unsigned* by default.

[terra at gnome dot org]

http://www.caldera.com/developers/devspecs/abi386-4.pdf on page 32 makes it
clear that "int x : 5" should have the range 0-31.  Sun's C compiler has the
same idea on solaris.

The conform to the ABIs, -funsigned-bitfields therefore needs to be the default
for i386 and sparc at least.


-------------------------------------------------------------------------------
#include <stdio.h>

int main (int argc, char **argv)
{
  struct Foo {
    int x : 5;
  } foo;

  foo.x = 31;

  printf ("%d\n", foo.x);
  return 0;
}


Solaris:
> gcc-3.4 -std=c99 ~/foo.c
./a.out 
-1
/opt/SUNWspro/bin/cc -xc99 ~/foo.c
./a.out 
31


Linux/x86, gcc 3.3.1:
Same as gcc-3.4 on solaris.

-- 
           Summary: [sparc/i386]: Bitfields should be *unsigned* by default.
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: terra at gnome dot org
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: sparc-sun-solaris2.8, i586-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17211

[Bug c/17211] [sparc/i386]: Bitfields should be *unsigned* by default.

[jsm at polyomino dot org dot uk]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-08-27 16:04 -------
Subject: Re:  New: [sparc/i386]: Bitfields should be *unsigned*
 by default.

On Fri, 27 Aug 2004, terra at gnome dot org wrote:

> http://www.caldera.com/developers/devspecs/abi386-4.pdf on page 32 makes it
> clear that "int x : 5" should have the range 0-31.  Sun's C compiler has the
> same idea on solaris.
> 
> The conform to the ABIs, -funsigned-bitfields therefore needs to be the default
> for i386 and sparc at least.

What is this to do with the ABI?  I.e., what is your argument against the 
section of the manual (in trouble.texi) explaining why this does not 
belong in an ABI?  The documentation of implementation-defined behavior in 
implement-c.texi specifically describes how GCC implements this and does 
not refer to an ABI.

I should also add that while as that document suggests we let 
-funsigned-bitfields determine the signedness of bit-fields declared as 
plain char, short, long (or long long), which accords with the handling of 
this matter in C++, I see nothing in the C standard that would permit 
doing so; it only refers to int for such special handling and short is 
always the same as signed short (for example).  Thus the only way we get 
away with doing so is that we document that we don't allow these types as 
implementation-defined extra bit-field types (pedwarning for them if 
pedantic).  If we were to change to allowing them in C99 mode as proper 
implementation-defined types, DRs would be needed about this and other 
issues.

Also, that document doesn't discuss _Bool, long long or complex types, 
i.e. it predates C99; a more recent version or supplement discussing C99 
is needed before we could completely resolve the lack of ABI documentation 
by saying "on platform X we follow that document", though we could still 
say "on platform X we follow that document for the features described 
therein, subject to these exceptions and these extensions".



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17211

[Bug target/17211] [sparc/i386]: Bitfields should be *unsigned* by default.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-27 16:07 -------
Note if I read the psABI correct for AMD64 (aka x86_64), it should be signed by default so this is a 
target problem only.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target
   GCC host triplet|sparc-sun-solaris2.8, i586- |
                   |suse-linux                  |
 GCC target triplet|                            |sparc-sun-solaris2.8, i586-
                   |                            |suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17211

[Bug target/17211] [sparc/i386]: Bitfields should be *unsigned* by default.

[jsm at polyomino dot org dot uk]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-08-27 16:27 -------
Subject: Re:  [sparc/i386]: Bitfields should be *unsigned*
 by default.

I would add that the definition in mcore/mcore.h

/* The MCore ABI says that bitfields are unsigned by default.  */
#define CC1_SPEC "-funsigned-bitfields"

is in clear contradiction to the documentation of bit-field handling; 
either that definition should be removed or the documentation should be 
revisited to allow for target exceptions.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17211

[Bug target/17211] [sparc/i386]: Bitfields should be *unsigned* by default.

[terra at gnome dot org]

------- Additional Comments From terra at gnome dot org  2004-08-27 16:50 -------
C99 clearly says that "int x : 5" may be either signed or unsigned.

C99 only requires bitfields of base types _Bool, enums, int, signed int, and
unsigned int.  No char, no short, and no long long -- they are left to the
implementation.

Thus the C99 definition is not in the way of changing this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17211

[Bug target/17211] [sparc/i386]: Bitfields should be *unsigned* by default.

[jsm at polyomino dot org dot uk]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-08-27 17:03 -------
Subject: Re:  [sparc/i386]: Bitfields should be *unsigned*
 by default.

On Fri, 27 Aug 2004, terra at gnome dot org wrote:

> C99 only requires bitfields of base types _Bool, enums, int, signed int, and
> unsigned int.  No char, no short, and no long long -- they are left to the
> implementation.

C99 says "or some other implementation-defined type".

At present we support no such types; see implement-c.texi.  Attempts to 
use such types get pedwarns with -pedantic.

Suppose we were to support short as such a type.  6.7.2#5 says that short, 
signed short, short int and signed short int all designate the same type.  
It has an exception for int as a bit-field type, but none for short.  
Thus if an implementation supports short bit-fields as an 
implementation-defined bit-field type, they must be the same as signed 
short bit-fields.  This may be a defect, but it is the clear meaning of 
the standard is it is at present.

I don't think we should change to supporting such types as 
implementation-defined bit-field types without a DR on this, and another 
DR on the meaning of sizeof applied to an expression derived by arithmetic 
on bit-field types wider than int.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17211

[Bug target/17211] [sparc/i386]: Bitfields should be *unsigned* by default.

[terra at gnome dot org]

------- Additional Comments From terra at gnome dot org  2004-08-30 15:14 -------
You're reading things into the standard that aren't there.  Here's what it says
on the topic:

[#5] Each of the comma-separated sets  designates  the  same
     type,  except  that  for  bit-fields,  it is implementation-
     defined whether the specifier int designates the  same  type
     as signed int or the same type as unsigned int.

Note, that the expection is for the *specifier* int, not the C-type int.
Therefore "short int" etc. are perfectly covered by the very same clause.
(I guess that leaves "char" if you really wanted to nit-pick about it.)

Note, that the language laywers at Sun seem to have decided that the smaller
types should be unsigned by default too.

The rant in trouble.texi is misguided.  The ABIs make lots of random choices
for which one could write an almost identical rant.  (Bit-field packing;
int alignment.)

I translate trouble.texi into "I don't like what the ABI says".  That is
rather inappropriate because after all the purpose of following an ABI is
to facilitate inter-operability.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17211

[Bug target/17211] [sparc/i386]: Bitfields should be *unsigned* by default.

[jsm at polyomino dot org dot uk]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-08-30 15:57 -------
Subject: Re:  [sparc/i386]: Bitfields should be *unsigned*
 by default.

On Mon, 30 Aug 2004, terra at gnome dot org wrote:

> Note, that the expection is for the *specifier* int, not the C-type int.
> Therefore "short int" etc. are perfectly covered by the very same clause.
> (I guess that leaves "char" if you really wanted to nit-pick about it.)

It is quite clear from the context that "specifier" refers one of the 
lists rather than to "int" on its own; your reading would make it 
implementation-defined whether "signed int" meant "signed signed int" or 
"signed unsigned int", both of which are invalid.  After all, "long int" 
has meaning as a whole; in it, "int" does not designate a type at all.

> Note, that the language laywers at Sun seem to have decided that the smaller
> types should be unsigned by default too.

What does their C99 compiler's documentation of implementation-defined 
behavior say about implementation-defined other bit-field types?

> The rant in trouble.texi is misguided.  The ABIs make lots of random choices
> for which one could write an almost identical rant.  (Bit-field packing;
> int alignment.)

Some rants in trouble.texi are misguided, but that one makes a specific 
decision about interoperability of GNU C on different platforms.  
Bit-field packing and int alignment affect interoperability of compiled 
objects in a way bit-field signedness doesn't; it is an API issue and we 
can fixinclude system headers making a particular presumption to state 
signedness explicitly.

GCC supports many variations of implementation-defined behavior on each 
platform, with options such as -funsigned-bitfields, -fshort-enums, 
-fshort-wchar.  Proper documentation of what behavior GCC has on each 
platform needs to take account of this.

We do not currently have much in the way of documentation that says "on 
platform X, GCC follows ABI Y subject to caveats and command-line 
influences Z".  This is indeed a bug.  Fixing it means ensuring 
documentation describing the actual ABI and API GCC follows rather than 
just pointing to a vaguely similar ABI and API for a given CPU.  The ABI 
and API GCC follows can be changed if necessary, but only with great care.  

Considerations in choice of interface include compatibility with previous 
versions of GCC, compatibility with other compilers on platforms where GCC 
is not the system compiler, efficiency of particular interfaces, and 
consistency and implementability of particular specifications.  The most 
natural choice in documentation is to document what GCC does, i.e. make 
clear GCC's choice for bit-fields, rather than artificially require GCC to 
follow an external ABI in this regard.  On x86-linux, where GCC is the 
system compiler, I don't think there can be much case for changing the 
rule for bit-field sign; GCC has determined the de facto API and ABI. Some 
platforms might sufficiently strongly define a particular C API that it 
makes sense to provide that by default rather than the normal GNU C API.  
Perhaps MCore is one such.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17211

[Bug target/17211] [sparc/i386]: Bitfields should be *unsigned* by default.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-30 18:56 -------
Since this API vs ABI, closing as will not fix.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17211