Paul Schlie wrote:
> Andrew Haley wrote:
>> Omar Torres wrote:
>>> Hi Andrew,
>>> Looks like Paul did submitted a patch here:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
>>>
>>> Can you or someone else take a look and comment on it?
>> Oh my goodness, that is a huge patch. It's also incorrect, as
>> far as I can see: LONG_LONG_TYPE_SIZE is never less than 64 bits,
>> so this test always returns true. There's a discussion in Section
>> 6.2.5. of the rationale in C99 that explains why long long is defined
>> to be this way.
>
> Yes, a target port which which does not support 64 bit operations
> could not be strictly C99 compliant, however don't see any reason
> to forbid such as may be desired with this understanding; as such
> a port would remain compliant otherwise and fully useful in this
> respect, and remain fully compliant with earlier standards.
I don't understand this. If a target will generate inefficient code
for long long, that is surely no reason not to support it, it's a
reason to avoid using it. How does the availability of long long
cause any kind of a problem?
> (So unless there is a standing requirement that the compiler source
> inhibit ports which may not be capable of fully complying with the
> latest evolving language standards; enabling such as may be desired
> for whatever purpose would seem reasonable, as long as it does not
> interfere with the ability to support fully compliant ports, and
> thereby be harmless).
Understood, but surely even you don't like what that patch does.
For example,
unsigned u8 __attribute__ ((mode (SI)));
is defining a type called "u8" as a four byte type.
Andrew.
