This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Re: Another weird sparc solaris 2.8 compiler error
- To: tromey at redhat dot com, Bryce McKinlay <bryce at albatross dot co dot nz>, Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>, Edgar Villanueva <EVillanueva at dynamicsoft dot com>, java at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Subject: Re: [patch] Re: Another weird sparc solaris 2.8 compiler error
- From: Alexandre Petit-Bianco <apbianco at cygnus dot com>
- Date: Fri, 2 Feb 2001 01:09:44 -0800 (PST)
- References: <Pine.BSF.4.32.0102010157480.96364-100000@deneb.dbai.tuwien.ac.at><3A790CDB.BA8DC4C6@albatross.co.nz><87zog6gfe4.fsf@creche.redhat.com><14969.61786.388398.659421@deliverance.cygnus.com>
- Reply-To: apbianco at cygnus dot com
Alexandre Petit-Bianco writes:
> I'll put that on my todo list.
It's harder than I thought, as the new mangling code requires support
from other parts of the compiler that are asking for resources usually
provided by a front-end implementation -- we would end up linking a
huge amount of stubs, 38 as I now try to link with
toplev.o libbackend.a obstack.o ../libiberty/libiberty.a
I'm going to try an other way. Put unicode_mangling_length,
append_unicode_mangled_name and append_gpp_mangled_name in a separate
file, which will only require obstack.o and would jcf.h (for
UTF8_GET.) It should suffice as the mangling we have to perform is
fairly simple (for example, it doesn't require compression.)
./A