From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933486AbcJQJJs (ORCPT ); Mon, 17 Oct 2016 05:09:48 -0400 Received: from merlin.infradead.org ([205.233.59.134]:52130 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933278AbcJQJJl (ORCPT ); Mon, 17 Oct 2016 05:09:41 -0400 Date: Mon, 17 Oct 2016 11:09:30 +0200 From: Peter Zijlstra To: Jiri Slaby Cc: Vegard Nossum , linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Linus Torvalds , "Luis R . Rodriguez" , stable@vger.kernel.org, Ming Lei , Steven Rostedt Subject: Re: [PATCH 01/12] extarray: define helpers for arrays defined in linker scripts Message-ID: <20161017090930.GT3142@twins.programming.kicks-ass.net> References: <20161016151616.31451-1-vegard.nossum@oracle.com> <20161016151616.31451-2-vegard.nossum@oracle.com> <20161017083315.GA29322@worktop.vlan200.pylonone.local> <186f8242-3f8d-31cd-a8e8-9743bbc1c1fd@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <186f8242-3f8d-31cd-a8e8-9743bbc1c1fd@suse.cz> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 17, 2016 at 11:01:13AM +0200, Jiri Slaby wrote: > 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. Should we get one? > On the top of that, it's incorrect C according to the standard. According to the standard non of the kernel has any chance in hell of working, so don't pretend you care about that :-)