This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Introduce abi_word_mode


Ulrich Weigand wrote:

Well, the way I see it, the user shouldn't even have to think about
some interfaces that are link-compatible with "pure" 31-bit code,
while other may not be -- the mode of operation of GCC I'm envisioning
should *be* "pure 31-bit" as far as link compatibility is concerned.

This is something that should be possible to switch on as a pure
optimization option, without changing any behaviour visibile on
the source code level.  (In fact, since current Linux distributions
on s390 no longer support 31-bit kernels, it should be feasible for
the 31-bit distribution compiler to default to this mode.)

This is why I'm wary of statements that say the user shouldn't
be using this or that GCC feature if they want to be able to
use this mode.

I think that's why some of us are suggesting that this feature ought to be removed. I agree with the goal you're trying to achieve, but I think mode ((word)) is hostile to that goal: as Richard Kenner has said, its meaning is BITS_PER_WORD, which is something that changes between the 32-bit and 64-bit modes. In other words, mode ((word)) exposes a implementation detail about the actual target hardware, rather than merely its ABI, through to the source level -- and that's a bad thing.


You're trying to argue we should fix the feature, but I don't think there's anything to salvage. You've also pointed out that the most obvious uses of this (mis)feature are in GCC itself -- and those we can fix, in a way that will help you achieve your goal of mixed 32-bit/64-bit code.

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]