From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26507 invoked by alias); 16 Dec 2004 09:15:27 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 26479 invoked from network); 16 Dec 2004 09:15:20 -0000 Received: from unknown (HELO wproxy.gmail.com) (64.233.184.193) by sourceware.org with SMTP; 16 Dec 2004 09:15:20 -0000 Received: by wproxy.gmail.com with SMTP id 37so2107881wra for ; Thu, 16 Dec 2004 01:15:20 -0800 (PST) Received: by 10.54.4.40 with SMTP id 40mr2578174wrd; Thu, 16 Dec 2004 01:15:19 -0800 (PST) Received: by 10.54.45.53 with HTTP; Thu, 16 Dec 2004 01:15:19 -0800 (PST) Message-ID: <42f6506e041216011565134163@mail.gmail.com> Date: Thu, 16 Dec 2004 09:15:00 -0000 From: Gaurav Jain Reply-To: Gaurav Jain To: Ramana Radhakrishnan Subject: Re: Code Bloat using GCC 3.2 on Linux Cc: gcc-help@gcc.gnu.org In-Reply-To: <41C11DEE.1000800@codito.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <42f6506e041215034463e2c9b@mail.gmail.com> <20041215132426.78ca7b5e@zeta.comsys.se> <42f6506e04121506105903a2e2@mail.gmail.com> <6.2.0.14.2.20041215081802.0207dbd8@iplan-mn.corp.adobe.com> <42f6506e0412150728558fe41b@mail.gmail.com> <002601c4e2c0$7b59afd0$1400a8c0@bors> <42f6506e0412152108579628b6@mail.gmail.com> <41C11DEE.1000800@codito.com> X-SW-Source: 2004-12/txt/msg00149.txt.bz2 > -fdata-sections and -ffunction-sections puts the code in different > sections and with the linker flag --gc-sections you can remove code that > is never called or data which is never used. This does reduce code size > provided the --gc-sections is implemented in the linker. Could you try > it on your case and see what happens ? That makes me more comfortable - I'll sure give this one a try and see how it goes. > Also 3.2 is no longer supported by the community, so you might not see > too much interest in looking at a 3.2 problem. The versions that are > supported today are 3.3 and 3.4 . You could try either and see if there > are any improvements or they help solve your problem. That's not an option for me - I *have* to go with 3.2 > Do you have a number of inline functions in your code ? You could try > tuning that with -finline-limit-X, where X may be reasonably set to a > value between 100 and 5000. Yes I do, but I'm already using -fno-inline. I guess that should do away with it? Thanks, -Gaurav