Re: [PATCH] Introduce abi_word_mode

[Richard Sandiford <richard at codesourcery dot com>]

"Ulrich Weigand" <uweigand@de.ibm.com> writes:
> Saying that, well, -march=i686 doesn't conform to the ABI as cited
> above anyway, and therefore we might as well use a different calling
> convention, isn't really practical.  There is a lot of value to users
> to still keep the "ABI" -in the sense of link compatibility- invariant,
> while allowing to exploit different instruction set variants.

Yes, and I'm not claiming otherwise.  It sounds like you're trying
to justify the existence of this compatibility mode in the first place,
but I fully understand why wou want it.  And...

> And this is exactly what we want to achieve -- provide a configuration
> of GCC for s390 that exploits the capabilities of 64-bit machines,
> while keeping link compatibility with the 31-bit ABI.

...I'm not disputing that's a good thing.  I'm just disputing that
word(mode) is something you should use in an interface that has to be
link-compatible with pure 31-bit code.  Both meanings under discussion
have an ABI meaning, and if we have to keep the thing at all, I think
the current meaning makes more sense.  It seems like the kind of thing
that would be useful if you want to exploit the extra capabilities
you're trying to exploit here.

> If there were a clear understanding that attribute ((mode (word)))
> may change between configurations even if they otherwise support
> the same ABI (in the sense of link compatibility), then I guess
> attribute ((mode (word)) would be a suitable type for strictly
> local use as you describe above.  But the current user of
> ((mode (word))), at least in the GCC code base, are not of
> that type.

I think there was agreement in principle that gcc itself
should change though.

> Also, I still claim that I don't want to provide a "different"
> definition that the one we've been providing. I just want to clarify
> how the -currently vague- definition applies in an area where we
> hadn't needed to apply it before.

OK, well we clearly disagree there.

Richard