Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933422AbcJQJBZ (ORCPT ); Mon, 17 Oct 2016 05:01:25 -0400 Received: from mail-qk0-f194.google.com ([209.85.220.194]:35156 "EHLO mail-qk0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932536AbcJQJBQ (ORCPT ); Mon, 17 Oct 2016 05:01:16 -0400 Subject: Re: [PATCH 01/12] extarray: define helpers for arrays defined in linker scripts To: Peter Zijlstra , Vegard Nossum References: <20161016151616.31451-1-vegard.nossum@oracle.com> <20161016151616.31451-2-vegard.nossum@oracle.com> <20161017083315.GA29322@worktop.vlan200.pylonone.local> Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Linus Torvalds , "Luis R . Rodriguez" , stable@vger.kernel.org, Ming Lei , Steven Rostedt From: Jiri Slaby Message-ID: <186f8242-3f8d-31cd-a8e8-9743bbc1c1fd@suse.cz> Date: Mon, 17 Oct 2016 11:01:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161017083315.GA29322@worktop.vlan200.pylonone.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1060 Lines: 29 On 10/17/2016, 10:33 AM, Peter Zijlstra wrote: > On Sun, Oct 16, 2016 at 05:16:05PM +0200, Vegard Nossum wrote: >> The test in this loop: >> >> for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) { >> >> was getting completely compiled out by my gcc, 7.0.0 20160520. The result >> was that the loop was going beyond the end of the builtin_fw array and >> giving me a page fault when trying to dereference b_fw->name. >> >> This is because __start_builtin_fw and __end_builtin_fw are both declared >> as (separate) arrays, and so gcc conludes that b_fw can never point to >> __end_builtin_fw. >> > > Urgh, isn't that the kind of 'optimizations' we should shoot in the head > for the kernel? Just like the -fno-strict-aliassing crap? Unfortunately, there is no such switch for this optimization. On the top of that, it's incorrect C according to the standard. So it is as correct as expecting 0 printed here: 'int zero; printf("%d\n", zero);'. It never worked, not even with gcc 4 and maybe older. We were just lucky. thanks, -- js suse labs