From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14777 invoked by alias); 20 Nov 2009 01:29:17 -0000 Received: (qmail 14766 invoked by uid 22791); 20 Nov 2009 01:29:16 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from www.tglx.de (HELO www.tglx.de) (62.245.132.106) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Nov 2009 01:28:05 +0000 Received: from localhost (www.tglx.de [127.0.0.1]) by www.tglx.de (8.13.8/8.13.8/TGLX-2007100201) with ESMTP id nAK1RqIZ010498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 02:27:52 +0100 Date: Fri, 20 Nov 2009 01:29:00 -0000 From: Thomas Gleixner To: Linus Torvalds cc: Jeff Law , rostedt@goodmis.org, "H. Peter Anvin" , David Daney , Andrew Haley , Richard Guenther , Ingo Molnar , LKML , Andrew Morton , Heiko Carstens , feng.tang@intel.com, Fr??d??ric Weisbecker , Peter Zijlstra , jakub@redhat.com, gcc@gcc.gnu.org Subject: Re: BUG: GCC-4.4.x changes the function frame on some functions In-Reply-To: Message-ID: References: <4B05B7AD.20500@redhat.com> <1258670580.22249.1002.camel@gandalf.stny.rr.com> <4B05DBBF.5000804@redhat.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00556.txt.bz2 On Thu, 19 Nov 2009, Linus Torvalds wrote: > On Fri, 20 Nov 2009, Thomas Gleixner wrote: > > > > While testing various kernel configs we found out that the problem > > comes and goes. Finally I started to compare the gcc command line > > options and after some fiddling it turned out that the following > > minimal deltas change the code generator behaviour: > > > > Bad: -march=pentium-mmx -Wa,-mtune=generic32 > > Good: -march=i686 -mtune=generic -Wa,-mtune=generic32 > > Good: -march=pentium-mmx -mtune-generic -Wa,-mtune=generic32 > > > > I'm not supposed to understand the logic behind that, right ? > > Are you sure it's just the compiler flags? I first captured the command line with V=1 and created a script of it. Then I changed the -march -mtune options in that script and compiled just that single file manually w/o changing .config or invoking the kernel make magic. The good ones produce: 650: 55 push %ebp 651: 89 e5 mov %esp,%ebp 653: 83 e4 f0 and $0xfffffff0,%esp The bad one: 000005f0 : 5f0: 57 push %edi 5f1: 8d 7c 24 08 lea 0x8(%esp),%edi 5f5: 83 e4 f0 and $0xfffffff0,%esp 5f8: ff 77 fc pushl -0x4(%edi) 5fb: 55 push %ebp 5fc: 89 e5 mov %esp,%ebp > There's another configuration portion: the size of the alignment itself. > That's dependent on L1_CACHE_SHIFT, which in turn is taken from the kernel > config CONFIG_X86_L1_CACHE_SHIFT. > > Maybe that value matters too - for example maybe gcc will not try to align > the stack if it's big? That does not change any of the compiler options, but yes it could have some effect via the various include magics, but all I have seen so far is linkage.h which should not affect the compiler. And the manual compile did not change any of this. > [ Btw, looking at that, why are X86_L1_CACHE_BYTES and X86_L1_CACHE_SHIFT > totally unrelated numbers? Very confusing. ] Agreed. > The compiler flags we use are tied to some of the same choices that choose > the cache shift, so the correlation you found while debugging this would > still hold. Digging further tomorrow when my brain is more awake. Thanks, tglx