From mboxrd@z Thu Jan 1 00:00:00 1970 From: vladimir.murzin@arm.com (Vladimir Murzin) Date: Thu, 21 Jan 2016 12:32:09 +0000 Subject: [PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled In-Reply-To: <20151221133730.GP23092@arm.com> References: <1450498655-3820-1-git-send-email-apinski@cavium.com> <20151221123843.GM23092@arm.com> <20151221125130.GO23092@arm.com> <20151221133730.GP23092@arm.com> Message-ID: <56A0CFC9.1070401@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 21/12/15 13:37, Will Deacon wrote: > On Mon, Dec 21, 2015 at 01:58:30PM +0100, Ard Biesheuvel wrote: >> On 21 December 2015 at 13:51, Will Deacon wrote: >>> On Mon, Dec 21, 2015 at 01:46:22PM +0100, Ard Biesheuvel wrote: >>>> On 21 December 2015 at 13:38, Will Deacon wrote: >>>>> On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote: >>>>>> The problem here is that GCC 6 and above emits .arch now >>>>>> for each function so now the global .arch_extension has >>>>>> no effect. This fixes the problem by putting >>>>>> .arch_extension inside ARM64_LSE_ATOMIC_INSN so >>>>>> it is enabled for each place where LSE is used. >>>>> >>>>> Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64. >>>>> .arch_extension is used for virt, mp and sec over there, and it may be >>>>> tricky to isolate the actual instruction usage (at least, virt looks >>>>> lost in kvm/arm.c). >>>>> >>>>> Why can't gas have an option to accept all instruction encodings that it >>>>> knows about, inspite of any .arch directives? >>>>> >>>> >>>> Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it >>>> probably makes sense to pass that on the command line when building >>>> for v7 (or +sec only for v6) if the assembler is found to support it >>>> at build time. >>> >>> Does that override a more restrictive .arch directive emitted by the >>> compiler? >>> >> >> It seems to be additive: -march=armv7-a+mp+sec allows a .S file >> containing a virt arch_extension + both hvc and smc instructions to be >> assembled. > > The problem I'm seeing is if I have something like: > > .arch_extension lse > > before something like: > > .cpu cortex-a57+fp+simd+crc > > -or- > > .arch armv8-a+fp+simd+crc > > then I can no longer assemble lse instructions. So the .cpu/.arch > directive is undoing the .arch_extension. We can fix this by following > Andrew's suggestion to have .arch_extension before every point of use, > but the whole thing would be much simpler if we could just tell gas to > assemble harder. > > Maybe we just need to construct the mother of all -march options based > on build-time checks in the Makefile? > Since I've been bitten by this I'm curious what was conclusion on this topic? Thanks Vladimir > Will > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759516AbcAUMcV (ORCPT ); Thu, 21 Jan 2016 07:32:21 -0500 Received: from foss.arm.com ([217.140.101.70]:50694 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759214AbcAUMcS (ORCPT ); Thu, 21 Jan 2016 07:32:18 -0500 Message-ID: <56A0CFC9.1070401@arm.com> Date: Thu, 21 Jan 2016 12:32:09 +0000 From: Vladimir Murzin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Will Deacon , Ard Biesheuvel CC: Andrew Pinski , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled References: <1450498655-3820-1-git-send-email-apinski@cavium.com> <20151221123843.GM23092@arm.com> <20151221125130.GO23092@arm.com> <20151221133730.GP23092@arm.com> In-Reply-To: <20151221133730.GP23092@arm.com> 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 On 21/12/15 13:37, Will Deacon wrote: > On Mon, Dec 21, 2015 at 01:58:30PM +0100, Ard Biesheuvel wrote: >> On 21 December 2015 at 13:51, Will Deacon wrote: >>> On Mon, Dec 21, 2015 at 01:46:22PM +0100, Ard Biesheuvel wrote: >>>> On 21 December 2015 at 13:38, Will Deacon wrote: >>>>> On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote: >>>>>> The problem here is that GCC 6 and above emits .arch now >>>>>> for each function so now the global .arch_extension has >>>>>> no effect. This fixes the problem by putting >>>>>> .arch_extension inside ARM64_LSE_ATOMIC_INSN so >>>>>> it is enabled for each place where LSE is used. >>>>> >>>>> Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64. >>>>> .arch_extension is used for virt, mp and sec over there, and it may be >>>>> tricky to isolate the actual instruction usage (at least, virt looks >>>>> lost in kvm/arm.c). >>>>> >>>>> Why can't gas have an option to accept all instruction encodings that it >>>>> knows about, inspite of any .arch directives? >>>>> >>>> >>>> Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it >>>> probably makes sense to pass that on the command line when building >>>> for v7 (or +sec only for v6) if the assembler is found to support it >>>> at build time. >>> >>> Does that override a more restrictive .arch directive emitted by the >>> compiler? >>> >> >> It seems to be additive: -march=armv7-a+mp+sec allows a .S file >> containing a virt arch_extension + both hvc and smc instructions to be >> assembled. > > The problem I'm seeing is if I have something like: > > .arch_extension lse > > before something like: > > .cpu cortex-a57+fp+simd+crc > > -or- > > .arch armv8-a+fp+simd+crc > > then I can no longer assemble lse instructions. So the .cpu/.arch > directive is undoing the .arch_extension. We can fix this by following > Andrew's suggestion to have .arch_extension before every point of use, > but the whole thing would be much simpler if we could just tell gas to > assemble harder. > > Maybe we just need to construct the mother of all -march options based > on build-time checks in the Makefile? > Since I've been bitten by this I'm curious what was conclusion on this topic? Thanks Vladimir > Will > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > >