This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Problems with __int64, unsigned __int64 and DImode/ILP32 on ia64
On Fri, Jun 20, 2003 at 03:38:46PM -0700, Mark Mitchell wrote:
> > > Or make __int64 a builtin type, as with the Intel compiler.
> > >
> > > For builtins, you can usually use DImode internally.
> >
> > __int64 is used in intrinsic prototype. How do I add __int64 to ia64
>
> You can add it to ia64 only. There are machine specific builtin types
> for this purpose. You will have to look around to see how this is done;
> I don't know off the top of my head.
>
I trid to add
record_builtin_type (RID_LONG, "__int64",
long_integer_type_node);
record_builtin_type (RID_MAX, "unsigned __int64",
long_long_unsigned_type_node);
to ia64. But the parser won't accept "unsigned __int64" since sees
"unsigned" first as a keyword and __int64 isn't. In fact, none of
those "complex xxx" work for C++ since complex is not a keyword while
"__complex xxx" works. Is
complex double x;
supported to work in C++? If not, what is
(*lang_hooks.decls.pushdecl) (build_decl (TYPE_DECL,
get_identifier ("complex double"),
complex_double_type_node));
doing in c-common.c for C++?
Does anyone know how to make gcc to take "unsigned __int64"? If gcc
can't be made to accept "unsigned __int64" as a valid type, I guess I
have to use
record_builtin_type (RID_MAX, "__uint64",
long_long_unsigned_type_node);
There is another problem with ia64intrin.h. There are things like
extern long __sync_val_compare_and_swap_di (long *, long, long);
DImode is 64bit. But long can be 32bit for ILP32. __int64 will be
very useful here.
H.J.