Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755655AbaGZTgJ (ORCPT ); Sat, 26 Jul 2014 15:36:09 -0400 Received: from ud10.udmedia.de ([194.117.254.50]:51002 "EHLO mail.ud10.udmedia.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754974AbaGZTgF (ORCPT ); Sat, 26 Jul 2014 15:36:05 -0400 Date: Sat, 26 Jul 2014 21:35:57 +0200 From: Markus Trippelsdorf To: Linus Torvalds Cc: Steven Rostedt , Alexei Starovoitov , Michel =?iso-8859-1?Q?D=E4nzer?= , Jakub Jelinek , Linux Kernel Mailing List , Debian GCC Maintainers , Debian Kernel Team Subject: Re: Random panic in load_balance() with 3.16-rc Message-ID: <20140726193557.GA21842@x4> References: <20140723190230.GH3935@laptop> <53D064C7.5050807@daenzer.net> <53D1B1EF.7030603@daenzer.net> <20140725035527.GA30108@pg-vmw-gw1> <20140725140237.GB32669@home.goodmis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2014.07.26 at 11:39 -0700, Linus Torvalds wrote: > On Sat, Jul 26, 2014 at 11:28 AM, Linus Torvalds > wrote: > > > > That's a bit worrisome. I haven't actually checked if the code > > generation differs in significant ways yet.. > > Nope. Just three instructions that got re-ordered from ABC to CAB in a > way that makes no difference. But just the knowledge that "-g" affects > code generation is nasty. And with "allmodconfig" my build fails > almost immediately (failures on at least arch/x86/kernel/process_64.c, > kernel/exit.c and mm/vmalloc.c in that case. I was too lazy to check > what the differences were). > > Does anybody have current gcc build and can verify that current gcc > tip passes the kernel compile with that > > export GCC_COMPARE_DEBUG=1 > > thing? The fs/ext4/inode.c issue is a variant of the gcc bug and isn't fixed yet. I will open a bug report. The kernel/exit.c issue is already fixed, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 for a reduced testcase. But fortunately the workaround for the new inode.c bug is the same as for the original bug: -fno-var-tracking-assignments. It would make sense to enabled it unconditionally for all debug configurations for now. -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/