Re: [PATCH] DEFAULT_SIGNED_BITFIELDS Macro

[Donn Terry <donn at interix dot com>]

To (a) reiterate, and (b) conclude:

(a) gcc is intended to be ABI conformant for whatever architecture it
    is on.  To the extent that such conformance changes the semantics
    of a specific construct, the programmer is responsible to write
    his application stricutly portably (that is, in a way that doesn't
    care about that difference).  (In the absence of using
    whatever fine grained control is available, anyway.)

    Data file interchange falls into this same category, if I read
    you correctly.

(b) Then I agree that there's no need for a "native" vs. "gcc" switch,
    because there is no "gcc" mode.

Given the level of debate on this topic originally, does such a
statement appear anywhere in the "official" documentation?  If not,
it probably belongs there.  It would be useful guideance to future
porters.

Donn
    
Jeffrey A Law wrote:
> 
>   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

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================