This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Introduce abi_word_mode
> I'd argue that a program which uses word mode in a context that matters
> for the ABI is broken, if that program is intended to be used on
> multiple CPUs.
Unfortunately even gcc itself serves as a bad example here since the
mode(word) attribute is used for the eh data structures. And since it
isn't documented somewhere that attribute mode(mode) must not be used when
defining external interfaces I think we can't blame someone for using it
in an ABI-relevant context, can we?
> SImode is always the same width, "int" is always the
> same width, but "word" is a property of the CPU. That argument aside, I
> understand where you're coming from: you want to preserve source
> compatibility, but use the 64-bit registers. Have any other ports ever
> tried to do this? I thought that there were PowerPC configurations that
> used 64-bit registers with the 32-bit ABI; what do they do?
When compiling for PowerPC64 the PowerPC backend sets word_mode to 64bit
even when TARGET_32BIT is set. So without knowing details about the ABI
I would say it would break when using attribute(mode(word)) for external
As Ulrich pointed out the exception handling bits only work since the
libgcc_eh is build in a "real" 32bit mode i.e. in which also word_mode
is 32 bits.
> I agree with Geoff that this is an attribute we could do without, though
> I don't know how practical it is to remove it. Whatever you can do with
> "word" mode, you can also do with "int" on 90% of all platforms, and
> with a teeny bit of autoconf on the remainder.
Is there really a chance to remove it?! Since it is documented in the gcc
manual we have to consider that everybody makes use of it - right?!. Even
if it is not widely used and its uses are arguable I would think we are stuck
Redirecting mode(word) to int would e.g. break things on s390x where we have
an 32bit int although registers are 64bit.