This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: error: unable to emulate 'DI'


Andrew Haley wrote:
> 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.

I can't defend the earlier patch, nor the desire to enable ports which
have determined that 64bit support was unnecessary for whatever reason,
beyond the spirit in which it was proposed; being the only rational reason
to try to circumvent the otherwise implicit requirement for 64bit data type
support would be that its target was either too painful to support, or
possibly known not to be required and thereby arguably not worth the bother
inclusive of the implicit library routines correspondingly required if
supported.

I'm not trying to argue strongly for it, but merely observing it may be
rationally desired. (I presently don't care either way strongly)



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]