This is the mail archive of the gcc@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]

Re: A remark on -fsquangle


In article <199811201924.LAA13271.cygnus.egcs@possibly.synopsys.com> you write:
>
>> Undoubtedly, it's a brilliant idea, to compress huge mangled names. But
>> the necessity to have the entire run-time system being compiled with an
>> option, which is disabled per default, is a real handicap. When I
>> develop some software package and make it publicly available, I can't in
>> earnest require from the potential users that they have to reinstall
>> their compiler prior to using my package.
>
>This is why -fsquangle isn't the default.  However, we must break
>binary compatibility for other reasons, to have a fully conforming
>C++ library.  For this reason we were planning to make all the changes
>that break compatibility as a group, so we break things only once.

Perhaps the posters original thought was that squangling shouldn't
necessarily break compatibility. Could the mangling scheme in new-abi
and squangle be allowed to co-exist, with perhaps some element indicating
which is which?

I'm talking about something simple here, e.g. from your example the
unsquangled version of
        MyClass::MyClass(const MyClass&)
could be
__7MyClassRC7MyClassR
instead of
__7MyClassRC7MyClass

with maybe R for Raw, or something more imaginative. g++ could spot this
and react accordingly.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"Women marry hoping their husbands will change, men||Home e-mail: jifl @ 
marry hoping their wives never do. Both are rare." ||     jifvik.demon.co.uk
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault


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