From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1878 invoked by alias); 9 Sep 2010 10:21:37 -0000 Received: (qmail 1735 invoked by uid 48); 9 Sep 2010 10:21:05 -0000 Date: Thu, 09 Sep 2010 10:21:00 -0000 Message-ID: <20100909102105.1734.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mikpe at it dot uu dot se" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-09/txt/msg01177.txt.bz2 ------- Comment #7 from mikpe at it dot uu dot se 2010-09-09 10:21 ------- It's not a stage2/stage3 debug difference as far as I can tell. I've recompiled every differing .o file with the stage 1/2/3 xgccs -fcompare-debug without complaints. The test case showing the different code generation is trivial (this is in the objdir for a native bootstrap of r163951): > cat sreal.c void normalize(unsigned long long *sreal_sig) { *sreal_sig <<= 1; } > stage1-gcc/xgcc -Bstage1-gcc -O2 -c sreal.c; objdump -d sreal.o sreal.o: file format elf32-littlearm Disassembly of section .text: 00000000 : 0: e1c020d0 ldrd r2, [r0] 4: e0922002 adds r2, r2, r2 8: e0a33003 adc r3, r3, r3 c: e1c020f0 strd r2, [r0] 10: e12fff1e bx lr > stage2-gcc/xgcc -Bstage2-gcc -O2 -c sreal.c ; objdump -d sreal.o sreal.o: file format elf32-littlearm Disassembly of section .text: 00000000 : 0: e1c020d0 ldrd r2, [r0] 4: e1b02082 lsls r2, r2, #1 8: e0a33003 adc r3, r3, r3 c: e1c020f0 strd r2, [r0] 10: e12fff1e bx lr > stage3-gcc/xgcc -Bstage3-gcc -O2 -c sreal.c ; objdump -d sreal.o sreal.o: file format elf32-littlearm Disassembly of section .text: 00000000 : 0: e1c020d0 ldrd r2, [r0] 4: e1b02082 lsls r2, r2, #1 8: e0a33003 adc r3, r3, r3 c: e1c020f0 strd r2, [r0] 10: e12fff1e bx lr So stage1 chooses adds but stage2 and stage3 choose lsls for << of the lower half of a long long. Since the behaviour of a stageN xgcc depends on both the gcc source code and the compiler used to build it, I have to suspect a source code ambiguity (e.g. evaluation order dependence) that the bootstrap compiler (gcc-4.4.4 in my case) resolves differently from post-r162417 4.6. I've so far not been able to reproduce this difference in a cross from i686; those cross compilers always seem to choose the adds form regardless of the version of gcc I'm building with. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445