Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp6378244imd; Wed, 31 Oct 2018 10:45:05 -0700 (PDT) X-Google-Smtp-Source: AJdET5fbYR99lao1f4YxAIxl+Z9sfn3nhAKvYFF6FlFGvZrjjpKh87WK+ZG6rBaqyJMxRq7JuCoJ X-Received: by 2002:a63:f006:: with SMTP id k6mr4049572pgh.259.1541007905741; Wed, 31 Oct 2018 10:45:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541007905; cv=none; d=google.com; s=arc-20160816; b=iuqQ/bPRtnLrisdH6VhlOygrwP6lutr0m7xPdET5AN+SobgWl+dIk30JV4LLeALosU hUXxsyouM3CskVyNkyDtZ4bVZ0fsCGuECPxH4Z20w57LH8g31N5+RTsXtmf6QdQvYzXw lttRcjSCY0yUgy6P2HEh2JQLgCJV8NPbYZ90HGtGChm5KgwMFNi5OSw62/+VOTmcg2uo MhaKVtkj5TyckTxOuWGa9p3T7Zjq7ebaXQbriISYF73/kJnjA0Ytmd8Ejj/R4gs8Vu0H MKTQutgzW4aoPDcpIPjjbR/r8YLEcbleQIO1wx4GvvUqwcxdlC+r/RLeakCgLHY/GRvU IlGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ckw/p7ReiRanuNSI7twPBlqU5z0OSqO4jMy2fBJqGjY=; b=bD7UF0YiqOoQbfNriO/NRwlPb9CybXfLZeN5i4s6pSGr3N+xJvFBsz5zZjXMbTTQ8i caGHqOWyp6alHM0uiXLe0mgX1TMLrJZY4xQtDVlTIAHfYbQWDWyikpLz4hGOrAe8ydFq yLj0r+5TztvOwVDVW2WXAbbO43neJjCaKllmDFGuK3WqrX/F6ssjXpcFRGKMTJoP23Io l5Yh0SuLhclLm41sGIbWPmNOqErlE40L7ZLOLWq4Caoz7BIkOG0YFKEoMN0klV/Xm73n bK6QAZkhlUc8xBj7BTxtXg3pgkjjOBbNOXD9W+sX4d04aDU3Eyxh0L9LHgzsS0X6HeWQ p1Rg== 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 r68-v6si30274009pfk.151.2018.10.31.10.44.49; Wed, 31 Oct 2018 10:45:05 -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 S1729960AbeKACnC (ORCPT + 99 others); Wed, 31 Oct 2018 22:43:02 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:44562 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729315AbeKACnC (ORCPT ); Wed, 31 Oct 2018 22:43:02 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4579980D; Wed, 31 Oct 2018 10:44:02 -0700 (PDT) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 1580E3F6A8; Wed, 31 Oct 2018 10:44:02 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id E86641AE0CFD; Wed, 31 Oct 2018 17:44:08 +0000 (GMT) Date: Wed, 31 Oct 2018 17:44:08 +0000 From: Will Deacon To: Arnaldo Carvalho de Melo Cc: Daniel Borkmann , Peter Zijlstra , Linux Kernel Mailing List Subject: Re: arm64 tools build failure wrt smp_load_{acquire,release} expansion on gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) Message-ID: <20181031174408.GA27871@arm.com> References: <20181031154550.GA28340@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181031154550.GA28340@kernel.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnaldo, On Wed, Oct 31, 2018 at 12:45:50PM -0300, Arnaldo Carvalho de Melo wrote: > So I noticed the following build failure thare point to: > > commit 09d62154f61316f7e97eae3f31ef8770c7e4b386 > Author: Daniel Borkmann > Date: Fri Oct 19 15:51:02 2018 +0200 > > tools, perf: add and use optimized ring_buffer_{read_head, write_tail} helpers > > ------------------------- > > 50 ubuntu:16.04-x-arm64 : FAIL aarch64-linux-gnu-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 > > Works well with: > > 59 ubuntu:18.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04) 7.3.0 > > And all the other environments I test build :-) Cheers for reporting this. I managed to reproduce the build failure with gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1). The code in question is the arm64 versions of smp_load_acquire() and smp_store_release(). Unlike other architectures, these are not built around READ_ONCE() and WRITE_ONCE() since we have instructions we can use instead of fences. Bringing our macros up-to-date with those (i.e. tweaking the union initialisation and using the special "uXX_alias_t" types) appears to fix the issue for me. Diff below... Will --->8 diff --git a/tools/arch/arm64/include/asm/barrier.h b/tools/arch/arm64/include/asm/barrier.h index 12835ea0e417..378c051fa177 100644 --- a/tools/arch/arm64/include/asm/barrier.h +++ b/tools/arch/arm64/include/asm/barrier.h @@ -14,74 +14,75 @@ #define wmb() asm volatile("dmb ishst" ::: "memory") #define rmb() asm volatile("dmb ishld" ::: "memory") -#define smp_store_release(p, v) \ -do { \ - union { typeof(*p) __val; char __c[1]; } __u = \ - { .__val = (__force typeof(*p)) (v) }; \ - \ - switch (sizeof(*p)) { \ - case 1: \ - asm volatile ("stlrb %w1, %0" \ - : "=Q" (*p) \ - : "r" (*(__u8 *)__u.__c) \ - : "memory"); \ - break; \ - case 2: \ - asm volatile ("stlrh %w1, %0" \ - : "=Q" (*p) \ - : "r" (*(__u16 *)__u.__c) \ - : "memory"); \ - break; \ - case 4: \ - asm volatile ("stlr %w1, %0" \ - : "=Q" (*p) \ - : "r" (*(__u32 *)__u.__c) \ - : "memory"); \ - break; \ - case 8: \ - asm volatile ("stlr %1, %0" \ - : "=Q" (*p) \ - : "r" (*(__u64 *)__u.__c) \ - : "memory"); \ - break; \ - default: \ - /* Only to shut up gcc ... */ \ - mb(); \ - break; \ - } \ +#define smp_store_release(p, v) \ +do { \ + union { typeof(*p) __val; char __c[1]; } __u = \ + { .__val = (v) }; \ + \ + switch (sizeof(*p)) { \ + case 1: \ + asm volatile ("stlrb %w1, %0" \ + : "=Q" (*p) \ + : "r" (*(__u8_alias_t *)__u.__c) \ + : "memory"); \ + break; \ + case 2: \ + asm volatile ("stlrh %w1, %0" \ + : "=Q" (*p) \ + : "r" (*(__u16_alias_t *)__u.__c) \ + : "memory"); \ + break; \ + case 4: \ + asm volatile ("stlr %w1, %0" \ + : "=Q" (*p) \ + : "r" (*(__u32_alias_t *)__u.__c) \ + : "memory"); \ + break; \ + case 8: \ + asm volatile ("stlr %1, %0" \ + : "=Q" (*p) \ + : "r" (*(__u64_alias_t *)__u.__c) \ + : "memory"); \ + break; \ + default: \ + /* Only to shut up gcc ... */ \ + mb(); \ + break; \ + } \ } while (0) -#define smp_load_acquire(p) \ -({ \ - union { typeof(*p) __val; char __c[1]; } __u; \ - \ - switch (sizeof(*p)) { \ - case 1: \ - asm volatile ("ldarb %w0, %1" \ - : "=r" (*(__u8 *)__u.__c) \ - : "Q" (*p) : "memory"); \ - break; \ - case 2: \ - asm volatile ("ldarh %w0, %1" \ - : "=r" (*(__u16 *)__u.__c) \ - : "Q" (*p) : "memory"); \ - break; \ - case 4: \ - asm volatile ("ldar %w0, %1" \ - : "=r" (*(__u32 *)__u.__c) \ - : "Q" (*p) : "memory"); \ - break; \ - case 8: \ - asm volatile ("ldar %0, %1" \ - : "=r" (*(__u64 *)__u.__c) \ - : "Q" (*p) : "memory"); \ - break; \ - default: \ - /* Only to shut up gcc ... */ \ - mb(); \ - break; \ - } \ - __u.__val; \ +#define smp_load_acquire(p) \ +({ \ + union { typeof(*p) __val; char __c[1]; } __u = \ + { .__c = { 0 } }; \ + \ + switch (sizeof(*p)) { \ + case 1: \ + asm volatile ("ldarb %w0, %1" \ + : "=r" (*(__u8_alias_t *)__u.__c) \ + : "Q" (*p) : "memory"); \ + break; \ + case 2: \ + asm volatile ("ldarh %w0, %1" \ + : "=r" (*(__u16_alias_t *)__u.__c) \ + : "Q" (*p) : "memory"); \ + break; \ + case 4: \ + asm volatile ("ldar %w0, %1" \ + : "=r" (*(__u32_alias_t *)__u.__c) \ + : "Q" (*p) : "memory"); \ + break; \ + case 8: \ + asm volatile ("ldar %0, %1" \ + : "=r" (*(__u64_alias_t *)__u.__c) \ + : "Q" (*p) : "memory"); \ + break; \ + default: \ + /* Only to shut up gcc ... */ \ + mb(); \ + break; \ + } \ + __u.__val; \ }) #endif /* _TOOLS_LINUX_ASM_AARCH64_BARRIER_H */