Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932774AbdCISFK (ORCPT ); Thu, 9 Mar 2017 13:05:10 -0500 Received: from mail-io0-f193.google.com ([209.85.223.193]:33677 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754822AbdCISFG (ORCPT ); Thu, 9 Mar 2017 13:05:06 -0500 MIME-Version: 1.0 In-Reply-To: <20170309104908.GA20923@amd> References: <20170302234514.3qcqdozibcltkdai@treble> <20170306163807.GA20689@amd> <20170307173821.yknj5htr7plgdwxv@treble> <20170307182855.262ezbon2pm67qfd@treble> <20170308173703.2h57rsltma3smbcm@treble> <20170308212253.GA29562@amd> <20170309104908.GA20923@amd> From: Linus Torvalds Date: Thu, 9 Mar 2017 10:05:03 -0800 X-Google-Sender-Auth: J_e7dhFj8c_2u_5B1BVlS3t8RKg Message-ID: Subject: Re: Old compiler versions (was Re: v4.10: kernel stack frame pointer .. has bad value (null)) To: Pavel Machek Cc: Josh Poimboeuf , Andy Lutomirski , kernel list , Ingo Molnar , Andrew Lutomirski , Borislav Petkov , Brian Gerst , Denys Vlasenko , Peter Anvin , Peter Zijlstra , Thomas Gleixner Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2601 Lines: 67 On Thu, Mar 9, 2017 at 2:49 AM, Pavel Machek wrote: > > (On thinkpad X220, compiling bzip2) You really shouldn't assume that the zlib build tracks the kernel build. At least at some point, a noticeable part of the build cost for the kernel was just parsing the fairly big source code. We have honking big include files and deep nesting, and there is a lot of preprocessor and just general parsing overhead for stuff that in most files don't even generate code. All those inline functions and type declarations for things that then aren't actually used in most files means that you spend relatively more time just parsing files than you spend on generating and optimizing code. So the trade-offs between different projects can be very different. Some projects have huge tables with static initializers that gcc at some point had serious quadratic-time issues with, and other code has big functions where the actual optimization phase is the bulk of it. And some projects have a lot of big and nested include files. It's not nearly as bad as some C++ projects (where the header file mess can often _easily_ be the dominant factor by far), but it's still potentially completely different from something like building zlib. Oh, and don't even bother looking at -O0 times. That's almost purely parsing, but more importantly, the kernel has never in its lifetime built without optimizations. We basically rely on the compiler not being moronic crap. Always have, always will. > Unfortunately, 4.11-rc1 fails to compile on gcc 3.3.5. > >> 1. None (CC_STACKPROTECTOR_NONE) (NEW) > > is needed. Easy. But then I get > > AS arch/x86/entry/entry_32.o > arch/x86/entry/entry_32.S: Assembler messages: > arch/x86/entry/entry_32.S:440: Error: invalid character '"' in > operand 1 > > from the ALTERNATIVE macro. It seems 3.3 just does not like " in macro > arguments. Ok. Clearly our checks in are outdated, and we "allow" compilers that don't actually work. > But that looks fixable. But when I force the compilation, it is > actually _slower_ than recent gcc (23 minutes vs. 13 > minutes). Interesting. I forget when gcc got the "integrated preprocessor". It's a long time ago. But that actually sped things up, because it basically halves (or more) the overhead of parsing. With an external preprocessor you obviously first have cpp doing its parsing, then writing the preprocessed results out, and then you had cc1 doing parsing again. So yes, gcc has gotten a lot slower over time, but some things have actually improved. Linus