From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 520C420248 for ; Fri, 8 Mar 2019 10:12:02 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; q=dns; s=default; b=pQ5t2 tczWAtAjKOwLbnaujt1PQKuMZ3WM+Qdx8V5P3tgqTwSlcyr1EGAoo3+rH92bIZVe AOWlFsuDCmn+KKQ2OSCAeNDP0d4x1CWofgALZXwVkn8bghXRF1Csn6pKjpx5MXJH U46nHF6hchVgNEHp+dPJNmPSbCKHBuAP4mZdAg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; s=default; bh=3GhF12jX9Sn pU95jD1ydr4hsNX4=; b=uG1Mvp0RmQyGUGUV5eKUKGSEIfkt+5n8lmgKMlNU4uj jIj0dFeKQq9xkf3vAbP4pu3p14hmdrxOjV0giXTtIIewcnA503iRBVeaWc1r+6Gw S5dWsbxcngtvMh6i/97+vsu0QIXtUqJ+4rALsp5tASmu48YZqG5wxGER0mtzzOu0 = Received: (qmail 53836 invoked by alias); 8 Mar 2019 10:11:59 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 53828 invoked by uid 89); 8 Mar 2019 10:11:59 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Szabolcs Nagy Cc: Joseph Myers , nd , Steve Ellcey , "libc-alpha\@sourceware.org" Subject: Re: [PATCH] Aarch64: Add simd exp/expf functions References: <2b85a60f-4b75-f819-5d07-879665ec88b3@arm.com> <871s3jak4w.fsf@mid.deneb.enyo.de> <87va0v948z.fsf@mid.deneb.enyo.de> <6957cf95-d719-e351-e23f-8652441dbaa0@arm.com> Date: Fri, 08 Mar 2019 11:11:13 +0100 In-Reply-To: <6957cf95-d719-e351-e23f-8652441dbaa0@arm.com> (Szabolcs Nagy's message of "Fri, 8 Mar 2019 09:10:08 +0000") Message-ID: <87o96l65ha.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain * Szabolcs Nagy: > On 07/03/2019 19:04, Joseph Myers wrote: >> On Wed, 6 Mar 2019, Florian Weimer wrote: >> >>> On the other hand, it could help to get libmvec out of the door more >>> quickly. I think it's not ideal that if you use an older compiler, >>> you get only a subset of the glibc ABI. We can get away with it here >>> because it affects an entire soname. Still it might be difficult to >>> explain why applications are not portable. >> >> On the whole I think I agree with Rich Felker's argument >> against >> having the presence of libmvec depend on the tools used for the build. >> (Note that the installed bits/math-vector.h file, which may be shared >> between multilibs, does not depend on the tools used, so if libmvec was >> disabled then the installed bits/math-vector.h is not actually correct and >> some programs will fail to build.) >> >> This is an argument for removing the --disable-mathvec configure option as >> well as either having assembly wrappers or a requirement for new-enough >> tool versions for building libmvec functions on platforms where the oldest >> supported GCC / binutils aren't new enough. > > so is it acceptable to submit generated asm to the > source tree together with the c source? No, before we do that, I think we should just require GCC 9 and binutils 2.33 for building aarch64. I had the hope that you could build a compatible ABI with just a few assember trampolines, but that's not the case if the DSOs need markers for disabling lazy binding in client code. (But it is probably more natural to disable lazy binding though function attributes in the header file.) Thanks, Florian