This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: error: unable to emulate 'DI'
- From: Andrew Haley <aph at redhat dot com>
- To: Paul Schlie <schlie at comcast dot net>
- Cc: Omar Torres <gcc dot omar at gmail dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 16 Oct 2008 17:59:04 +0100
- Subject: Re: error: unable to emulate 'DI'
- References: <C51CE824.14728%schlie@comcast.net>
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.