Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754600AbdCIKu3 (ORCPT ); Thu, 9 Mar 2017 05:50:29 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:37821 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753432AbdCIKtM (ORCPT ); Thu, 9 Mar 2017 05:49:12 -0500 Date: Thu, 9 Mar 2017 11:49:08 +0100 From: Pavel Machek To: Linus Torvalds Cc: Josh Poimboeuf , Andy Lutomirski , kernel list , Ingo Molnar , Andrew Lutomirski , Borislav Petkov , Brian Gerst , Denys Vlasenko , Peter Anvin , Peter Zijlstra , Thomas Gleixner Subject: Old compiler versions (was Re: v4.10: kernel stack frame pointer .. has bad value (null)) Message-ID: <20170309104908.GA20923@amd> References: <20170302234514.3qcqdozibcltkdai@treble> <20170306163807.GA20689@amd> <20170307173821.yknj5htr7plgdwxv@treble> <20170307182855.262ezbon2pm67qfd@treble> <20170308173703.2h57rsltma3smbcm@treble> <20170308212253.GA29562@amd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <20170308212253.GA29562@amd> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4861 Lines: 137 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > > - CONFIG_FUNCTION_GRAPH_TRACER sets it on x86-32 because of a gcc bug > > > where the stack gets aligned before the mcount call. This issue > > > should be mostly obsolete as most modern compilers now have -mfentr= y. > > > We could make it dependent on CC_USING_FENTRY. > >=20 > > Yeah. At some point we might even upgrade the compiler requirements to > > no longer accept the mcount model. > >=20 > > I think the fentry model is gcc-4.6.0 and up. Currently I guess we > > support gcc-3.2+, which is fairly ridiculous considering that 4.6.0 is > > from March, 2011. So it's over five years ago already. > >=20 > > gcc-3.2.0 is from 2002, I think. At some point you just have to say > > "caring about a 15 year old compiler is ridiculous" > >=20 > > The main reason we have fairly aggressively supported old compilers > > tends to be some odder architectures that don't have good support, so > > people use various random "this works for me" versions. > >=20 > > We could easily make the gcc version checks much more strict on x86, > > I suspect. >=20 > Well, I have fast CPUs, but most of the time they just compile > stuff. Especially bisect is compile-heavy. I suspect going back to > gcc-3.2 would bring me bigger advantages than CPU upgrade... Okay, would not it be nice if we supported gcc-3.3? It compiles about twice the speed of gcc-4.9, across the board: (If we could compile at -O1, we'd get 4 times the speed. At -O0, we'd be at cca 9 times the speed; that would be useful for a bisect!) Good news is that -Os is quite significantly faster than -O2 (and already supported), so that should be simple way to optimize bisect perform= ance.=20 (On thinkpad X220, compiling bzip2) | mach | gcc | | | real | user | sys | = $ | x220 | 4.9.2-10 | -O0 | bzip2.c caf036 | 0.644 | 0.54 | 0.03 | = $ | | | -O1 | | 1.501 | | | = $ | | | -O2 | | 2.607 | | | = $ | | | -O3 | | 3.052 | | | = $ | | | -Os | | 1.839 | | | = $ | | 3.3.5-13 | -O0 | | 0.343 | 0.300 | 0.028 | = $ | | | -O1 | | 0.721 | | | = $ | | | -O2 | | 1.238 | | | = $ | | | -O3 | | 1.598 | 1.508 | 0.032 | = $ 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 =66rom the ALTERNATIVE macro. It seems 3.3 just does not like " in macro arguments. arch/x86/boot/bioscall.S: Assembler messages: arch/x86/boot/bioscall.S:68: Error: `68(%esp)' is not a valid 16 bit base/index expression Plus I get about milion of from fs/fs-writeback.c:23: include/linux/irq.h:419: warning: parameter has incomplete type include/linux/irq.h:420: warning: parameter has incomplete type =20 =2E.. and problem with builtin_ffs in drm_blend.c, and others with function alignment in drm. lzo1x_compress needs __builtin_ctz. In the end, compilation fails with mm/built-in.o(.text+0x2b714): In function `do_set_pmd': : undefined reference to `__compiletime_assert_3034' mm/built-in.o(.text+0x2c09a): In function `create_huge_pmd': : undefined reference to `do_huge_pmd_anonymous_page' mm/built-in.o(.text+0x2c0ca): In function `wp_huge_pmd': : undefined reference to `do_huge_pmd_wp_page' drivers/built-in.o(.text+0xe5a2b): In function `cea_mode_alternate_timings': : undefined reference to `__compiletime_assert_2638' drivers/built-in.o(.text+0x3c969f): In function `sg_ioctl': : undefined reference to `__divdi3' But that looks fixable. But when I force the compilation, it is actually _slower_ than recent gcc (23 minutes vs. 13 minutes). Interesting. If someone knows what old gcc versions actually compile recent kernels, I'd like to know. Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljBMyMACgkQMOfwapXb+vKtugCgjULZYazLeKi55Gor0ZSuxFms gyIAoJLgfE3LKiIxlGHi03Tvaq8icVDv =7egd -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s--