Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759375AbYG2OeG (ORCPT ); Tue, 29 Jul 2008 10:34:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758207AbYG2Ody (ORCPT ); Tue, 29 Jul 2008 10:33:54 -0400 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:54823 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756620AbYG2Odx (ORCPT ); Tue, 29 Jul 2008 10:33:53 -0400 Message-ID: <488F2A50.5060107@sgi.com> Date: Tue, 29 Jul 2008 07:33:52 -0700 From: Mike Travis User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: Ingo Molnar CC: KOSAKI Motohiro , Stephen Rothwell , David Miller , linux-next@vger.kernel.org, LKML , Andrew Morton , Linus Subject: Re: linux-next: build failure References: <20080729180317.94c64634.sfr@canb.auug.org.au> <20080729085815.GA1301@elte.hu> <20080729202731.F18F.KOSAKI.MOTOHIRO@jp.fujitsu.com> <20080729114029.GA3836@elte.hu> <488F29D5.1080105@sgi.com> In-Reply-To: <488F29D5.1080105@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2034 Lines: 60 Mike Travis wrote: > Ingo Molnar wrote: >> * KOSAKI Motohiro wrote: >> >>>> * Stephen Rothwell wrote: >>>> >>>>> Hi Ingo, >>>>> >>>>> On Tue, 29 Jul 2008 10:00:55 +0200 Ingo Molnar wrote: >>>>>>> -#define cpumask_of_cpu(cpu) ({ *get_cpu_mask(cpu); }) >>>>>>> +#define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu)) >>>>>> hm, i'm wondering - is this a compiler bug? >>>>> Or maybe a deficiency in such an old compiler (v3.4.5) but the fix >>>>> makes sense anyway, right? >>>> yeah, i was just wondering. >>> in linux/README >>> >>> COMPILING the kernel: >>> >>> - Make sure you have at least gcc 3.2 available. >>> For more information, refer to Documentation/Changes. >>> >>> So, if 3.4.5 is old, Should we change readme? >> the fix is simple enough. >> >> but the question is, wont it generate huge artificial stackframes with >> CONFIG_MAXSMP and NR_CPUS=4096? Maybe it is unable to figure out and >> simplify the arithmetics there - or something like that. >> >> Ingo > > I've looked at stack frames quite extensively and usually they are > not generated unless you explicitly use a named cpumask variable, > pass a cpumask by value, expect a cpumask function return, create > an initializer that contains a cpumask field, and (probably a couple > more I missed). > > Almost all others are done efficiently via pointers or simple > struct copies: > > cpus_xxx(*cpumask_of_cpu(), ... > struct->cpumask_var = *cpumask_of_cpu() > global_cpumask_var = *cpumask_of_cpu() > etc. > > Thanks, > Mike Geez, I edited the above after I first used *cpumask_var and didn't get the semantics right! cpus_xxx(cpumask_of_cpu(), ... struct->cpumask_var = cpumask_of_cpu() global_cpumask_var = cpumask_of_cpu() -- 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/