Message-Id: <002201bd8446$d48ab840$45111d0f@ros51675cra.rose.hp.com>
From: "Andrew Crabtree" <andrewc AT rosemail DOT rose DOT hp DOT com>
To: <djgpp-workers AT delorie DOT com>
Subject: Fw: gcc 2.8.1 outputs are much larger than gcc 2.7.2 ... why ??
Date: Wed, 20 May 1998 16:27:14 -0700
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Precedence: bulk

Just in case people missed it on c.o.m.d.   Troy's analysis appears to be
correct as far as I can tell.  Any suggestion on to what would be better to
fix?  cc1plus or as?  Not sure of the consequences in either case.

Andy


-----Original Message-----
From: Troy <reply AT newsgroups DOT com DOT ok>
Newsgroups: comp.os.msdos.djgpp
Date: Wednesday, May 20, 1998 6:17 AM
Subject: Re: gcc 2.8.1 outputs are much larger than gcc 2.7.2 ... why ??

>      It's partly the exception tables.  The reason the file size is larger
>is that when gcc 2.8.1 produces code with exception tables, it produces a
>lot of labels in the assembly file it outputs (run gcc -S program.cc to see
>for your self). All these lables are local labels and begin with a capital
>'L'. AS.exe from binutils 2.8.1 expects local labels (labels which don't
>need to be in the symbol tables) to begin with '.L'. Because of the
>missmatch, the symbol table explodes in size with all these useless labels
>when you are compiling C++ code with exceptions enabled.  A partial
>sollution is, if you don't need exception handling, to compile with
>-fno-exceptions, and make sure you strip your final executables.
>
> The real solution for this is to get bintuils and gcc on the same
>wavelength.  Either recompiling binutils after making a fairly simple
>change to a header file somewhere, or recompiling gcc getting it to produce
>the proper form of local labels.
>
> Troy Van Horn