Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934841AbcJQWiT (ORCPT ); Mon, 17 Oct 2016 18:38:19 -0400 Received: from smtprelay.synopsys.com ([198.182.60.111]:58569 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934571AbcJQWiK (ORCPT ); Mon, 17 Oct 2016 18:38:10 -0400 Subject: Re: Build regressions/improvements in v4.9-rc1 To: Arnd Bergmann References: <1476688913-15648-1-git-send-email-geert@linux-m68k.org> <00b16c44-79b8-43b8-6516-13c8bb92eb03@synopsys.com> <5541266.ySlPfDOezF@wuerfel> CC: Michal Marek , Peter Zijlstra , Michael Ellerman , "linux-kernel@vger.kernel.org" , Geert Uytterhoeven , arcml Newsgroups: gmane.linux.kernel.arc,gmane.linux.kernel From: Vineet Gupta Message-ID: <9a0f80b3-adb3-36de-d59f-885ac29ea2e6@synopsys.com> Date: Mon, 17 Oct 2016 15:37:58 -0700 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: <5541266.ySlPfDOezF@wuerfel> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.161.50] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2360 Lines: 58 On 10/17/2016 02:02 PM, Arnd Bergmann wrote: > On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote: >> +CC Arnd, Michal >> >> Hi Geert, Arnd >> >> Need some guidance here. >> >> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote: >>>> 48 error regressions: >>>>> + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]': => 476 >>>>> + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]': => 475 >> >> [snip...] >> >>>>> + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]': => 516 >>>>> + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]': => 478 >>> arcv2/axs103_smp_defconfig >> >> >> I'm thinking how to address this correctly. >> >> This is due to the older version of compiler. The fix itself is trivial - add an >> "call as-instr" construct in Makefile to get -DARC_TOOLS_SUPPORT_LLOCKD >> >> However the atomic64 API variant (CONFIG_GENERIC_ATOMIC64 or arch native) which >> gets included in build comes from Kconfig (ISA supports them or not). How do we >> tie the Makefile info into the Kconfig. >> >> We could trigger a build failure for invalid combinations of GENERIC_ATOMIC64 and >> ARC_TOOLS_SUPPORT_LLOCKD but that would be less than ideal out of box experience. >> >> Or the simpler solution is that kisskb upgrades the ARC GNU compiler > > Some ideas, none of which are perfect: > > - add an #ifndef ARC_TOOLS_SUPPORT_LLOCKD clause in asm/atomic.h that uses > .long with hardcoded opcodes in place of the mnemonics. > > - instead of setting CONFIG_GENERIC_ATOMIC64 from Kconfig, add a file > in arch/arc/kernel/ that includes lib/atomic64.c if ARC_TOOLS_SUPPORT_LLOCKD > is not set. > > - add "-DCONFIG_GENERIC_ATOMIC64" to cflags-y from arch/arc/Makefile if > old binutils are found. I'm tending towards this one - seems cleanest, however... @Michael can I bother you to upgrade the tools or is this absolutely must for you. > > I think someone was suggesting in the past that Kconfig could be extended > to make decisions based on the gcc version, and the same thing could > be done for binutils. Don't remember who that was though. I think a number > of awkward hacks in the kernel could be simplified if we had this. > > And >