From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47861 invoked by alias); 22 Jul 2019 17:57:28 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 47562 invoked by uid 89); 22 Jul 2019 17:57:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=our X-HELO: mail-io1-f47.google.com Received: from mail-io1-f47.google.com (HELO mail-io1-f47.google.com) (209.85.166.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Jul 2019 17:57:26 +0000 Received: by mail-io1-f47.google.com with SMTP id j5so71737219ioj.8 for ; Mon, 22 Jul 2019 10:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=Qzu3DiPRQfqsqtRfpRbdJNMSNZ66slDWTEGwN0mYp9Q=; b=kdLZ+CU2C9frn4BUbQKjWiB7rnCTVcxekx6x4ipZrTCJkqPa34PZRPGaRJ2bvwl+nr ShGC9hy3ecv+7szy+9nktPx3X7yk8BidF63T/WGl183AvZxgZ0FVvi6hOEcuEAgD4Kfu CVw06osTxy1zHV9PRwk8DoWADb5DbqfdTDciyao2i/ChW3tpacgDPXjjXKp+j6WbspXo OqPibe8+A4N0Drq5CFZ04kfWCjAkVAvdpvlzWvNEK7+a1tr6JDTqMj961ClFUijfUZfh 8bPehGkjxfuJjRz6FTG4wh/AdLM0wiLhCctE7n1MdiBkgSIFU1XSobs/HVfNNC2x9O00 PvLw== MIME-Version: 1.0 References: <87ftn4in6x.fsf@linux.intel.com> <71c86eab-4178-e841-f968-b4425f851dd3@redhat.com> In-Reply-To: <71c86eab-4178-e841-f968-b4425f851dd3@redhat.com> Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Mon, 22 Jul 2019 17:57:00 -0000 Message-ID: Subject: Re: Can LTO minor version be updated in backward compatible way ? To: Jeff Law Cc: GCC Development Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00152.txt.bz2 On Wed, Jul 17, 2019 at 2:10 PM Jeff Law wrote: > > ... > SuSE's announcement today is quite ironic. Red Hat's toolchain team is > planning to propose switching to LTO by default for Fedora 32 and were > working through various details yesterday. Our proposal will almost > certainly include stripping out the LTO bits from .o's and any static > libraries. Be sure to include an ARMv7 test case where on source file uses a the default arch flags, and one source file uses -march=armv7-a -mfpu=neon. (With runtime feature checking): for example: a.cpp - default flags b.cpp - -march=armv7-a -mfpu=neon We can't seem to get around errors like this during link driven through GCC: [ 303s] /usr/lib/gcc/armv7hl-suse-linux-gnueabi/9/include/arm_neon.h:4835:48: fatal error: You must enable NEON instructions (e.g. '-mfloat-abi=softfp' '-mfpu=neon') to use these intrinsics. [ 303s] 4835 | return (uint32x4_t)__builtin_neon_vshl_nv4si ((int32x4_t) __a, __b); [ 303s] | ^ [ 303s] compilation terminated. The only thing we have found to sidestep the problem is, disable LTO for ARM. Jeff