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


Richard Sandiford wrote:
This probably isn't going to advance the discussion much, but...

Andreas Krebbel <Andreas.Krebbel@de.ibm.com> writes:
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
with it.

...IMO, this point argues against the change you're trying to make. You're effectively trying to _redefine_ what the attribute means, and one of the drawbacks of that is precisely that it may hurt people who are already using it.

The status quo has the advantage of being what previous compilers do,
and of being easier to understand.  The EH symbols aren't mangled,
so if they are a concern, it seems better to just change the types
(unless it's OK to continue compiling them in 32-bit mode).

I agree. I think that it's unfortunate that GCC didn't clearly document this limitation (perhaps because nobody thought of it); it shows once again how we can get burned by adding source extensions. But, to me, it really does seem the lesser of two evils to preserve the current meaning (or to remove the feature entirely) rather than to change its meaning.


--
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]