On Thu, Oct 16, 2008 at 11:59 AM, Andrew Haley <[EMAIL PROTECTED]> 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?
Agree, and it turns out that long long is *never* used in the intended application, so the original port author decided not to bother implementing 64-bit support. Since implementing 64-bit support for this target is out of the question in the immediate future, I am in the look for an alternative solution. Realized just now that the original port have a comment on how to work around this same issue: # We do not have DF or DI types, so fake out the libgcc2 compilation. TARGET_LIBGCC2_CFLAGS = -DDF=SF -DDI=SI -D__DF__=__SF__ -D__DI__=__SI__ Looks like GCC now sucessfuly complies my x-compiler. Now, the hard part: check that it does the "right thing". Thanks for your help! -Omar
