From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935466AbcJQVDH (ORCPT ); Mon, 17 Oct 2016 17:03:07 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:64278 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933239AbcJQVDB (ORCPT ); Mon, 17 Oct 2016 17:03:01 -0400 From: Arnd Bergmann To: Vineet Gupta Cc: Geert Uytterhoeven , "linux-kernel@vger.kernel.org" , arcml , Michael Ellerman , Peter Zijlstra , Michal Marek Subject: Re: Build regressions/improvements in v4.9-rc1 Date: Mon, 17 Oct 2016 23:02:02 +0200 Message-ID: <5541266.ySlPfDOezF@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <00b16c44-79b8-43b8-6516-13c8bb92eb03@synopsys.com> References: <1476688913-15648-1-git-send-email-geert@linux-m68k.org> <00b16c44-79b8-43b8-6516-13c8bb92eb03@synopsys.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:rbkQcSGmYVfSF9QfvyfWyU2chnQWm+cMTmt3PrvDZP8+TeNkctv y2WCf6CoGp9de2GfJb4Y433Ew2nsHdPGiyx+981oHWW294Xm6PxhPm+9iZnu9mguToUFhpk IBTzQi5m/62+4YEQZTzu2saIMCLsoGDhJiyKeFexK09/aNm0ndnKqQazXxZfiN4VPTgMKeD k90XRwu9WyfxilV9cBchg== X-UI-Out-Filterresults: notjunk:1;V01:K0:/0p+f2YDbeI=:twAE/BVN9SxbGpuYV9hnja /svOOM73n+d2OlW8xbDcjEdk5Cw40EVLk3ldY/co8f4pIpfAKj9qOWwGyjEtIQEIsKIu300r2 liaKhJAbDLxNpIGnf831nUq1nWe0ku1q4jCsQbUaAU3sW7RZaT6hKYlqzI6KsXzp4tnQKkVJ0 OaUWMXPbew6Pr7yzUgcYCS49v3EhrsFqaPF1OKCNy0pZsQWhyLj6CjQ2Rnu/TmdTeNHCv9EzZ 48GKUHgF2TBd/5kX9qH22Ur7hHTdqop+ydZcsdDWBtmaTBL60e7iDc16iDTOm8E9426vm17VA NiNDe0w7snFjvviJ9EG+t/yERMZftKPoYHXyxai3wgntMffETB0mxxApECLLUIcKkTLD3Dzy6 Xi2WtSWdofHQsqOzYErdRN/oMoBToMfQYOU3MVP/hOQMMjOyW8eCcoZ/GXTrmxZ1FMOQukaNh AQJfuopHPQS1QANGOFhNvm7+mYWcKO15LrE28b/TgLooCOayUFlIBDWrnhOEFJlKQQL92cLld hysQo0ALblePlKC6Iy2e2DhQxAEkDjyHxbqHEEtqlfE1mP9i5D1Uy9dTjw67rZzQx3uZW3yJP o2NgD16XZW+YSmaZ6Yqa7ayraXw4VIeu1HqFZoBE2T9qFaw3xJUWpLf6fB9zbHKHx+pNKRgh2 VRy1qFLnwZ5WNQQXQVANti7yNneJs2kXEAqAeSYX8UXukvVOdYouqshq2K20PI1Ak7jgHIIgM wmxHH7ZUVMtlyire Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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