Xref:	news2.mv.net comp.os.msdos.djgpp:2312
From:	cziwkga AT pluto DOT ulcc DOT ac DOT uk (Kevin Ashley)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Exe size
Date:	29 Mar 1996 16:22:46 GMT
Organization:	University of London Computer Centre
Lines:	29
Distribution:	world
Message-ID:	<4jh2om$fbl@calypso.ulcc.ac.uk>
References:	<9603261706 DOT AA08184 AT tina DOT dei DOT unipd DOT it>
Reply-To:	k DOT ashley AT ulcc DOT ac DOT uk
NNTP-Posting-Host:	pluto-e.ulcc.ac.uk
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

In article <9603261706 DOT AA08184 AT tina DOT dei DOT unipd DOT it>, gelido AT dei DOT unipd DOT it writes:
|>Hi DJs,
|>	which is the inline GCC options to make the smaller .exe ?
|>I use 'GCC -s -O3' but the output file is 2-3 times bigger than BCC.
|>Is this what I have to pay for 32 bit ?

Using -O3 will often make your files much bigger. gcc's optimizations
are targeted toward speed of execution rather than size of program.

-O3 invokes inlining (which may also involve 'cloning'), which means
that your EXE file may contain many slightly different copies of the
object code for one routine. Loop unrolling can also make your
program slightly larger. 32-bit can make your code larger just because
addresses need more bytes, but on the other hand you can often write
simpler code so the program may be smaller. If EXE size is really
important to you,  try -O2 and look closer at the optimization
switches in the info file - it explains which affect speed and which
size. 

But inlining and small code size are fundamentally incompatible.
Why do you want small EXE files ? 

 ----------------------------------------------------------------------------
Kevin Ashley                              K DOT Ashley AT Ulcc DOT ac DOT uk
Systems Development Group Manager      http://www.ulcc.ac.uk/staff/Kevin+Ashley
University of London Computer Centre.      ...ukc!ncdlab!K.Ashley
                      This is not a signature

- Raw text -