Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761084AbXHPAYX (ORCPT ); Wed, 15 Aug 2007 20:24:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S934943AbXHPAXy (ORCPT ); Wed, 15 Aug 2007 20:23:54 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:36334 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934836AbXHPAXg (ORCPT ); Wed, 15 Aug 2007 20:23:36 -0400 Date: Thu, 16 Aug 2007 06:06:00 +0530 (IST) From: Satyam Sharma X-X-Sender: satyam@enigma.security.iitk.ac.in To: Segher Boessenkool cc: horms@verge.net.au, Stefan Richter , Linux Kernel Mailing List , "Paul E. McKenney" , ak@suse.de, netdev@vger.kernel.org, cfriesen@nortel.com, Heiko Carstens , rpjday@mindspring.com, jesper.juhl@gmail.com, linux-arch@vger.kernel.org, Andrew Morton , zlynx@acm.org, clameter@sgi.com, schwidefsky@de.ibm.com, Chris Snook , Herbert Xu , davem@davemloft.net, Linus Torvalds , wensong@linux-vs.org, wjiang@resilience.com In-Reply-To: <2d2eeab6276cab2e6cc5830d36a43b98@kernel.crashing.org> Message-ID: References: <46C2350A.1010807@redhat.com> <20070815081841.GA16551@osiris.boeblingen.de.ibm.com> <46C30540.2070603@s5r6.in-berlin.de> <20070815145207.GA23106@gondor.apana.org.au> <46C3253F.5090707@s5r6.in-berlin.de> <20070815162722.GD9645@linux.vnet.ibm.com> <20070815185724.GH9645@linux.vnet.ibm.com> <2d2eeab6276cab2e6cc5830d36a43b98@kernel.crashing.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2386 Lines: 61 On Wed, 15 Aug 2007, Segher Boessenkool wrote: > > > > What you probably mean is that the compiler has to assume any code > > > > it cannot currently see can do anything (insofar as allowed by the > > > > relevant standards etc.) > > > > I think this was just terminology confusion here again. Isn't "any code > > that it cannot currently see" the same as "another compilation unit", > > It is not; try gcc -combine or the upcoming link-time optimisation > stuff, for example. > > > and wouldn't the "compilation unit" itself expand if we ask gcc to > > compile more than one unit at once? Or is there some more specific > > "definition" for "compilation unit" (in gcc lingo, possibly?) > > "compilation unit" is a C standard term. It typically boils down > to "single .c file". As you mentioned later, "single .c file with all the other files (headers or other .c files) that it pulls in via #include" is actually "translation unit", both in the C standard as well as gcc docs. "Compilation unit" doesn't seem to be nearly as standard a term, though in most places it is indeed meant to be same as "translation unit", but with the new gcc inter-module-analysis stuff that you referred to above, I suspect one may reasonably want to call a "compilation unit" as all that the compiler sees at a given instant. BTW I did some auditing (only inside include/asm-{i386,x86_64}/ and arch/{i386,x86_64}/) and found a couple more callsites that don't use cpu_relax(): arch/i386/kernel/crash.c:101 arch/x86_64/kernel/crash.c:97 that are: while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) { mdelay(1); msecs--; } where mdelay() becomes __const_udelay() which happens to be in another translation unit (arch/i386/lib/delay.c) and hence saves this callsite from being a bug :-) Curiously, __const_udelay() is still marked as "inline" where it is implemented in lib/delay.c which is weird, considering it won't ever be inlined, would it? With the kernel presently being compiled one translation unit at a time, I don't see how the implementation would be visible to any callsite out there to be able to inline it. Satyam - 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/