Re: [PATCH] DEFAULT_SIGNED_BITFIELDS Macro

[Jeffrey A Law <law at cygnus dot com>]

  In message <37575AB0.FEFD5FD0@verinet.com>you write:
  > Craig's argument is that for purity, that gcc should always do things the
  > "same" (pure) way.  If I hear you correctly, you're saying that it should
  > always conform to the native ABI (otherwise a compatability switch WOULD
  > be meaningful).   Do I understand you correctly?
Basically yes.  "always conform" -> "strive to conform" is probably more
accurate.  There are known cases where we do not strictly conform.  For
example we have some problems in structure passing to varargs functions on
some platforms.  However, I look at those as bugs, not features.

  > If I do, then you're saying that occasionally we have to pay the price of
  > having things like differences in semantics for bitfield sign extension,
  > and it's the responsibility of the program author that uses bitfields to
  > be sure that it's not a problem.
Yes.  However in this case, if the programmer writes portable code, then it is
a non-issue.  In fact, that is the case most of the time with any kind of ABI
issue.


  > Either that, or we need a switch to force a consistent interpretation
  > across all ports (in the face of less-than-perfect programs).
No, because if the code was portable, then it does not matter what the
signedness of those objects is (or endianness, or how structure packing
rules, or parameter passing rules, etc).  That is the point behind coding to
a standard like ANSI or ISO.  If you code to those standards you typically will
never need to care about issues that are defined by the ABI.

  > In the face of the existence of at least one ABI that has semantics which
  > vary from some gcc default, (signed bitfields, packing order, alignment rul
  > es,...)
  > 
  > (which probably means that every variant anyone can possibly think of
  > does exist, thanks to Murphy), this becomes a 2^n problem, one way or
  > another.  (Either the programmer that wants portabilty ahead of native conf
  > ormance
Yes, and much of the complexity in the front-end is to deal with all these
kinds of issues.  It's also one of the reasons gcc is so portable.  At some
point we've implement almost every oddball thing an ABI might require (there
are a few obscure exceptions, mostly dealing with varargs/stdarg issues).

And we have ways to runtime tweak most of those things like endianness,
structure packing, structure returns, some of the alignment stuff, etc.  But
you'll find that by default gcc will already try to be ABI conformant in these
areas.  If the programmer wants something different, they have to ask for it
explicitly.

And it makes perfect sense.  If we were not ABI conformant, then we'd be unable
to link with libraries compiled by any other compiler.  That would be 100%
totally stupid.  That's why ABIs exist in the first place -- so that compilers
can generate code that will interoperate with code from other compilers.


jeff