From:	"Troy " <reply AT newsgroups DOT com DOT ok>
Subject:	Re: [Q] Size of compiled executables from GCC 2.7x vs. 2.8
Newsgroups:	comp.os.msdos.djgpp
References:	<Pine DOT OSF DOT 3 DOT 96b DOT 980417140428 DOT 16994A-100000 AT saul2 DOT u DOT washington DOT edu>
Message-ID:	<01bd6c8b$cde17240$662e37a6@default>
Lines:	37
Date:	Mon, 20 Apr 1998 18:40:10 GMT
NNTP-Posting-Host:	usr46-dialup38.mix1.willowsprings.mci.net
NNTP-Posting-Date:	Mon, 20 Apr 1998 14:40:10 EDT
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Anshuman Pandey <apandey AT u DOT washington DOT edu> wrote in article
<Pine DOT OSF DOT 3 DOT 96b DOT 980417140428 DOT 16994A-100000 AT saul2 DOT u DOT washington DOT edu>...
> 
> Hello,
> 
> I just recently downloaded gcc280b.zip and bnu281.zip, and installed them
> in place of gcc2721b.zip and bnu27b.zip.
> 
> I noticed that my executables were considerably larger when compiled with
> gcc v2.8 and bnu v2.81 than they were originally when compiled with gcc 
> v2.721 and v2.7. The increase in size was about 100k. Does anyone happen
> to know what the reason behind this might be?
> 
> It is interesting to note that I uninstalled bnu v2.81 and switched back
> to v2.7, retaining gcc v2.8. Now the compiled executable was only about
> 45-55k larger than with gcc v2.721 and bnu v2.7.

Ok, first of all, try running STRIP on your executables, and you should
find them to be about the same size using either setup you mentioned.

As to the reason the executables were larger: 
	1. I believe gcc 2.8.0 probably outputs some more information in the
symbol table than 2.7.2.1 did.
	2. as.exe from binutils 2.7 was properly configured to throw out the local
lables which gcc outputs in is assembly code.  (a local lable is a lable
which begins with an L). Binutils 2.8.1 was not configured to throw them
out, so the lables are stored in every object file, and every unstripped
executable, making them larger than those produced by bnu v2.7.


Troy Van Horn

- Raw text -