[ia64-abi] Issue reminder

[Jim Dehnert]

> From drepper at cygnus.com  Thu Mar 16 15:45:00 2000
> 
> dehnert at baalbek.engr.sgi.com (Jim Dehnert) writes:
> 
> > So again, I propose that we treat:
> > [...]
> > 	__float80 as a synonym for long double
> 
> If you want to the ABI be universally usable this is bad.  On SPARC,
> PPC, and many other archs __float128 would be long double.  There is
> no consistency.

I don't.  We're defining a 64-bit IA-64 psABI, where we've already
determined that long double is the native 80-bit type.

Of course, to the extent that we're also defining the language API,
there is an issue.  In C, I think it only affects the user if he
attempts to mix the types in different declarations of the same
function, which might work on one target and fail on another -- so he
shouldn't do it.  Furthermore, the only machines I can think of with
80-bit FP are IA-32 and IA-64, both of which use it for long double.
So even this won't produce any more porting problems than using
__float80 does in the first place.

C++ becomes much more interesting.  Introducing new fundamental types
requires different overloading and therefore mangling (so we'll have
to define it), which is straightforward.  But it also requires defining
the overload resolution/ambiguity rules, which isn't straightforward,
and probably other issues (I'm no expert in this area).  It will also
end up causing additional instantiations of templates.  It is for this
reason that we've suggested treating those we can as synonyms.

Now, there is a minor issue.  If one interprets "synonym" as
"typedef", doing "typedef long long __int64" does not enable one to use
"signed __int64" or "unsigned __int64".  So the synonym treatment would
require something deeper.

We could take another approach, more drastic on the surface, but
more in keeping with the C2000 standard.  That would be to remove
__int64 and __float80, and instead use the C2000 stdint.h and the
equivalent for floats (which we'd have to define).  We could
typedef them if anyone is already using them to minimize problems.
I'm sure that wouldn't avoid all issues, but it would leave us with
something more in the spirit of the C2000 standard.

Whatever the decision, we need to make it so C++ can do whatever ends
up being required.

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272