From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f193.google.com (mail-ua0-f193.google.com [209.85.217.193]) by mail.openembedded.org (Postfix) with ESMTP id B8D14753FD for ; Thu, 7 Jun 2018 23:38:09 +0000 (UTC) Received: by mail-ua0-f193.google.com with SMTP id 59-v6so7704834uas.5 for ; Thu, 07 Jun 2018 16:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FRXWt6qTZJCqb8TjKPOOIodw7JcgvR/95xD+asIE0hc=; b=uijAC6egI8tY135CzVReEviaGTznbvCPAA4Pbw+m+t0yyDpz6YUN1RLSK3hcl/1xtA BBmvH4pIbJwXlz1nRgruZSD8GJ+XHp4/HVtH0mIZv7uZ67FPNbdNMO/zvSDAa4hEvbq1 XRGKAgl7AVu+WhzYIJZRE8sC6t2eE+5T5ZInzZs2ApEIoiqvC13sItiBVzZikDYSyw68 TKIW5kXh7M0A4nor4ZM4eYNR9hNTKf0Cc7+UBxWuWsqSW63rYbeo1iQ5vSUTTwIR6UBZ Euhr9TcOCONGtjBpWaXf47z40Rwfpunwr5FvfRAhXE8pA4Fq2DdvXVoCQmdowawLqvMR OvJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FRXWt6qTZJCqb8TjKPOOIodw7JcgvR/95xD+asIE0hc=; b=YHzxkLIf2CdJvPuH3YsP83i0AdBJ6BRjoEVuVsRkPRRpgW0Wx7+V0JkogrKUY+9jND zoysUj6GmIHkyH0JB4rnUES6z+T3QoIRubDsiZoaFEQRquf0vp4c3YrzYqTagcNCmzK5 UqC+NzttlZFR2jwsKvTnYzxVwp4OIK+XyXdaLDACHiCwJ46ATJk76I7wJJKCQMBNT3yw z+v5AZ0Jr9PLiRMGaN9zXMbTuCj9vSM6/STQJ87oXXZOCcuDot/svuv0QFmGCqn64/+F F5vJLZOTMjWsU5sjn/Gt9PB58HVlNriwiIOPSFcWHER79wudoxRlUC/ggfHQ7Sw2t/JZ B+yQ== X-Gm-Message-State: APt69E1lyuKrUNpUf/vsy8m8MXpV5FctiOyXJswtIWxdpw8weUrbodRH ZF7SmIn68ZRuiFr1un0mIT1yZ12o3F9TyRPd6zw= X-Google-Smtp-Source: ADUXVKIKTljqmdI8VBW7qsXIh3YUkgE3d3a8S1ZmF6bn4saC38nB799eBZ2NRA74cNGFTUARjI19/FUGhg3atmvujDE= X-Received: by 2002:ab0:50ba:: with SMTP id c55-v6mr2902312uaa.150.1528414690570; Thu, 07 Jun 2018 16:38:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:28a:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 16:38:09 -0700 (PDT) In-Reply-To: References: <635c8757bf852c8a4248009f241c19146431cacd.1528320772.git.raj.khem@gmail.com> <5c57a121-c4cd-e548-cd26-182076deb917@gmail.com> From: Andre McCurdy Date: Thu, 7 Jun 2018 16:38:09 -0700 Message-ID: To: Khem Raj Cc: OE Core mailing list Subject: Re: [PATCH 01/12] tune/arm: Set -mtune instead of -mcpu X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 23:38:09 -0000 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 7, 2018 at 7:04 AM, Khem Raj wrote: > On Thu, Jun 7, 2018 at 12:14 AM, Andre McCurdy wrote: >> On Wed, Jun 6, 2018 at 10:58 PM, Khem Raj wrote: >>> On 6/6/18 4:42 PM, Andre McCurdy wrote: >>>> On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj wrote: >>>> >>>> The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch >>>> the same conflicts. It doesn't make sense that gcc8 is just catching >>>> more issues. >>> >>> It does make sense. the option parsing for these specific options on arm >>> have been revamped after gcc7, see >>> >>> https://github.com/kraj/gcc/compare/a99ae290af49793cd3db7a74f3dbc59e64d356a1...68b54adbd7b10c66d968d74b96fba552bd46ebb7 >> >> Thanks. These commits seem to be related to handling of options like >> "-mcpu=cortexa9+nosimd". Was that the error you saw in testing? >> >> If you can provide the command line that caused the error then it >> should be quick to establish whether it's gcc8 being more picky. >> >> Or perhaps there's always been a warning and -Werror has been added to >> a gcc8 Makefile where it wasn't before? >> >>>> If we are trying to build something which is reusable across multiple >>>> machines with the same architecture then it's a bug to be passing >>>> machine specific CFLAGS. Making the machine specific CFLAGS more >>>> generic is not the right solution. >>> >>> being reusable is a side-effect and a good one. Real problem is we are not >>> matching to what we say in package arches, Probably you are confusing tunes >>> to be meant for static code generation for a given CPU. >> >> Sorry, I don't really follow what you mean? >> >>> I am interested to >>> hear more ideas to what would be right solution if this is not it. >> >> I'd like to understand what the problem is first before trying to >> propose any solutions. >> >> ie what specifically has changed with gcc8 to cause the error which >> wasn't seen before? > > I would suggest take this gcc8 patch series and revert this one then build > gcc-runtime for rpi3 That's the answer to "how do I reproduce the issue" not to "what is the issue". Anyway, I can reproduce the issue. The root cause is that gcc-runtime libatomic tries to support runtime selection between different implementations of a few low level functions by making use of the gcc "ifunc" function attribute: https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute ie libatomic can contain versions of functions specific to armv6 or armv7 with selection between them being made at runtime via ifunc. In order to build the armv7 versions of these few functions, the libatomic Makefiles selectively add -march=armv7-a to CFLAGS. This isn't new - it goes back to at least 2012 in gcc git history. https://gcc.gnu.org/ml/gcc/2014-01/msg00141.html What _is_ new is that for ARM, support for ifunc function attributes was not enabled prior to gcc8. ie when building with gcc7, the libatomic configure script determines that the toolchain doesn't support ifunc and libatomic therefore builds without support for runtime function selection... since it never needs to compile armv7 specific versions of the runtime selectable functions the -march -vs- -mcpu conflict never happens. https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00521.html (Note that ifunc support for ARM in gcc8 is still only enabled for glibc, so this issue doesn't show up at all with musl). Various solutions are possible: 1) Let libatomic continue to build with ifunc support enabled, but avoid -march -vs- mcpu conflicts by dropping -mcpu from OE's CFLAGS in the gcc-runtime recipe. 2) Let libatomic continue to build with ifunc support enabled, but avoid -march -vs- -mcpu conflicts by updating the libatomic Makefiles so that they always safely over-ride any combination of -march, -mcpu, etc passed in from the build environment. ie patch the libatomic Makefiles to replace: IFUNC_OPTIONS = -march=armv7-a+fp -DHAVE_KERNEL64 with: IFUNC_OPTIONS = -march=armv7-a+fp -mcpu=generic-armv7-a -DHAVE_KERNEL64 (Regardless of the solution we pick for OE, I think that fix should be submitted upstream to libatomic. There's no need for libatomic to risk build errors by not defining -mcpu in cases where it specifically wants to target armv7a). 3) Prevent libatomic from building with ifunc support enabled for ARM by forcing "libat_cv_have_ifunc=no" from the gcc-runtime recipe. Votes?