Re: [PATCH] Introduce abi_word_mode

[Ian Lance Taylor <iant at google dot com>]

Mark Mitchell <mark@codesourcery.com> writes:

> Ian Lance Taylor wrote:
> > Mark Mitchell <mark@codesourcery.com> writes:
> >
> >> 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.
> > To be clear, the cases where it matters for gcc code are the uses of
> > attribute ((mode (word))) in unwind-generic.h and libgcc2.h.  Since on
> > the S/390 you can (apparently) compile code with BITS_PER_WORD set to
> > either 32 and 64, and since you can (apparently) link such code
> > together safely, then by your argument (which I think is reasonable)
> > those uses are broken.
> 
> So, are we converging towards telling Andreas that there is no way to
> do what he wishes?  In other words, are going to declare that
> attribute ((mode (word))) is not something that back ends can
> configure independently of BITS_PER_WORD, and that, therefore, if you
> have 32-bit code involving that type, that this binary code cannot be
> recompiled without change to use 64-bit registers?
> 
> I'm OK with that decision, though I think we should certainly document
> this limitation, even if we don't go so far as to deprecate the use of
> mode ((word)).

I would be OK with that, in which case we should change
unwind-generic.h and libgcc2.h.

But I would also be OK with permitting a backend to specify that
"attribute ((mode (word)))" gives you a type which is not the same
size as word_mode.  Actually the only reason I see to support
"attribute ((mode (word)))" is backward compatibility, since it is
documented, albeit rather ambiguously.  It seems to me to be rather
difficult to write code that uses the attribute safely, correctly, and
portably.  As we are seeing right now.

Ian