From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1523 invoked by alias); 20 Nov 2011 00:48:37 -0000 Received: (qmail 1515 invoked by uid 22791); 20 Nov 2011 00:48:36 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from cesium.clock.org (HELO cesium.clock.org) (192.5.16.65) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 20 Nov 2011 00:48:22 +0000 Received: from cesium.clock.org (cesium.clock.org [192.5.16.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by cesium.clock.org (Postfix) with ESMTP id DED9415EC05; Sat, 19 Nov 2011 16:48:20 -0800 (PST) Date: Sun, 20 Nov 2011 06:51:00 -0000 From: Matt To: Ian Lance Taylor cc: gcc-help@gcc.gnu.org Subject: Re: bootstrap comparison failure with bootstrap-lto In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg00201.txt.bz2 On Fri, 18 Nov 2011, Ian Lance Taylor wrote: > Matt writes: > >> Should I file a bug about the multiple runs being necessary? I poked >> around a bit and it seemed that different -j options results in a >> different number of tries. That being said, even -j1 required multiple >> tries. (This may be a symptom of one of the issues that causes my >> builds to fail spectacularly every blue moon when doing -jN>6.) > > Sure, go ahead and file a bug. It would be nice to get these things > cleaned up. Done. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51232 I added you on the cc for it, hope you don't mind. > Great. I think that now we've cleared through the weeds and gotten to > the interesting part: why does it crash? I think the failing test is > gcc_AC_INITFINI_ARRAY in gcc/acinclude.m4. It is intended to see > whether the host linker correctly supports a mix of .init_array and > .ctors sections with priorities. This test is intended to be more or > less independent of the compiler, and is intended to only test the > linker. Both the host gcc used to build stage1 and the stage1 gcc > itself are presumably using the same linker (right?). So, why would the > test pass with the host gcc and fail with the stage1 gcc? > > If you can trace the points at which the static variable "count" > changes, that may help us pin down what is going wrong. Pin down, indeed :) When I try to watch or print 'count', I get this from GDB: Reading symbols from /home/matt/src/gcc-trunk/obj/conftest...done. (gdb) watch count Watchpoint 1: count (gdb) run Starting program: /home/matt/src/gcc-trunk/obj/conftest Error evaluating expression for watchpoint 1 value has been optimized out Watchpoint 1 deleted. So, it looks like an optimization bug of a sort to my naive eyes. As such, I started trying different combinations on the compile line, the original was: /home/matt/src/gcc-trunk/obj/./prev-gcc/xgcc -B/home/matt/src/gcc-trunk/obj/./prev-gcc/ -B/home/matt/x86_64-unknown-linux-gnu/bin/ -B/home/matt/x86_64-unknown-linux-gnu/bin/ -B/home/matt/x86_64-unknown-linux-gnu/lib/ -isystem /home/matt/x86_64-unknown-linux-gnu/include -isystem /home/matt/x86_64-unknown-linux-gnu/sys-include -o conftest -g -O2 -flto=jobserver -frandom-seed=1 -static-libstdc++ -static-libgcc ~/finitest.c If I take out the -flto=jobserver, the test no longer crashes and the variable is no longer optimized out incorrectly. Trying other -flto variants all elicited the original problem. When I tested compilation using the trunk *or* the system compiler (GCC 4.6.1-based) with -O2 -flto, I was able to repeat the problem exactly. Is this a wrong-code bug, and/or should that test never be compiled with -flto? -- tangled strands of DNA explain the way that I behave. http://www.clock.org/~matt