Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp89528imm; Tue, 14 Aug 2018 14:39:16 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyN40p9eyvfpd3HT3OQBLwnUmI16Vk3c9MwygLg2aQ36XcSGBuBs5QBJS0ADpPiv50CoYkY X-Received: by 2002:a65:450a:: with SMTP id n10-v6mr22043371pgq.392.1534282755931; Tue, 14 Aug 2018 14:39:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534282755; cv=none; d=google.com; s=arc-20160816; b=M+Kon68phw8Y1KkcJK+05oBLzwMui4Se9NZusUVBPWQBKHmpImgjToOPfmH00hA+pp uY2LfB1PTtpMuDBS21zZINdCPdmB0qurV8o1Oh4bS2lyiniQgQdjBvHdNIZYANHTt3NW 0nW+KzEBK8zs7wwFyE3ukZxtMCiAmIouj3hU3mnRdKlbmrQ9CVPcUkeAv5R0XMw8/4Lo ZLSitLBn2qeTNm5RDEdKFAg/aedvMP6Y1N4+WVOSQEiCffV1WTzwdhtNNJkvDXsTZuDt Q3SC4yjqZlSJBwTv3iAPCkVgug4beHJyd5pnTdMUVKzEI7OfcBiKFcoPz4x9N5o00uOW bvfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=fpeEkc0cnFeEckYN4rA3PUg9fqmhuzTBFQwOk19rBPE=; b=nj/wWR03+ujJSUPzD8WQ+NMDIrkN0ikBZ3oKHMwCOM1J2wnP77sciJXu4xGlCiEdTx HpX+JbRXQQDJT49DZMpgDfCGr3Fono7FpCHQ0A3eXKPiyi5hgKC0jfP3PQGcq/yQSVzu RtfLCLEHFk77u9z8fmpXGPTILKHgyEaWoa7r8I66f44lyOFsYkm7xSWdu55ayT2iAekj KkOcK8T6MtxoBAAF+zGBSDDzFIJ2tDFxkx0qnOnNX5sWPqlO4U9WN7ua/wdJgf7Y9QKW B4WSilPReTu/MJarnBGOPBYRT5fsLhXyKoeocWFlFR1Z7djtWwsDqXoKanl2FeueFV+z GGhw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t188-v6si19936101pfd.148.2018.08.14.14.38.46; Tue, 14 Aug 2018 14:39:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729177AbeHOA0E (ORCPT + 99 others); Tue, 14 Aug 2018 20:26:04 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:48384 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728302AbeHOA0E (ORCPT ); Tue, 14 Aug 2018 20:26:04 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.92]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id B905ACFC; Tue, 14 Aug 2018 21:36:56 +0000 (UTC) Date: Tue, 14 Aug 2018 14:36:55 -0700 From: Andrew Morton To: Guenter Roeck Cc: linux-kernel@vger.kernel.org, Rik van Riel , Mike Galbraith , Dave Hansen , Linus Torvalds Subject: Re: Build failures with gcc 4.5 and older Message-Id: <20180814143655.3acd4bb211d44747f77e74f2@linux-foundation.org> In-Reply-To: <20180814170904.GA12768@roeck-us.net> References: <20180814170904.GA12768@roeck-us.net> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 14 Aug 2018 10:09:04 -0700 Guenter Roeck wrote: > Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask > (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building > the Linux kernel with gcc version 4.5 and older fails as follows. > > In file included from ./include/linux/mm.h:17:0, > from ./include/linux/pid_namespace.h:7, > from ./include/linux/ptrace.h:10, > from arch/openrisc/kernel/asm-offsets.c:32: > ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise empty struct Confused. Why does it think that the mm_struct is "otherwise empty"? This shuts it up: --- a/include/linux/mm_types.h~a +++ a/include/linux/mm_types.h @@ -490,6 +490,7 @@ struct mm_struct { #endif } __randomize_layout; + int wibble; /* * The mm_cpumask needs to be at the end of mm_struct, because it * is dynamically sized based on nr_cpu_ids. So we could add something like that, along with the appropriate #if GCC_VERSION and a comment. A simple enough change, to keep those old gcc versions limping along for a bit longer?