From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8701 invoked by alias); 13 Jun 2002 10:16:25 -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 8598 invoked from network); 13 Jun 2002 10:16:15 -0000 Received: from unknown (HELO anchor-post-31.mail.demon.net) (194.217.242.89) by sources.redhat.com with SMTP; 13 Jun 2002 10:16:15 -0000 Received: from mailgate.softwire.co.uk ([62.49.203.138] helo=polarbear) by anchor-post-31.mail.demon.net with esmtp (Exim 3.35 #1) id 17IReH-000Q0d-0V; Thu, 13 Jun 2002 11:16:13 +0100 From: "Rupert Wood" To: "'David T-G'" Cc: , , "'Fergus Henderson'" Subject: RE: why would two copies of gcc-2.95.2 yield different output? Date: Thu, 13 Jun 2002 03:16:00 -0000 Message-ID: <616BE6A276E3714788D2AC35C40CD18D5EC468@whale.softwire.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal In-Reply-To: <616BE6A276E3714788D2AC35C40CD18D69DB0E@whale.softwire.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-SW-Source: 2002-06/txt/msg00112.txt.bz2 Fergus Henderson wrote: > > Is there perhaps a way for a mere mortal to reverse-engineer the > > binaries and see what the differences are? > > Use objdump (from the GNU binutils package). It may be easier to use the two compilers to generate assembly output for a few simple examples and diff those instead; if the assembly code is all the same, then the difference is in the assemble or link steps or there's a difference in libraries used. You may also get some clues by diffing the specs files (found under /lib/gcc-lib//2.95.2/specs) of the two compilers. In any case, does it matter that the new compiler generates different binaries? It depends how seriously you take your binary validation: even if you rebuild the source to a tested binary with a one-line fix, it could be argued you should re-run all your tests on the new binary. In that case, you can just ship the binary you've got, bin the old compiler and start using the new compiler for all future releases. (Or even jump to a newer GCC version - if you want to stick with 2.95.x then there's always 2.95.3, CVS gcc-2_95-branch or vendor, e.g. Debian, patches of the CVS; or prehaps you could try GCC 3.1+.) In the worst case, you just have to keep the old build environment until your tested binaries reach end-of-supported-life: there's no reason you can't start using a new one for new builds. Rup.