From patchwork Thu Mar 6 19:31:57 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wilco Dijkstra X-Patchwork-Id: 6 Return-Path: X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx23.g.dreamhost.com (caibbdcaabja.dreamhost.com [208.113.200.190]) by wilcox.dreamhost.com (Postfix) with ESMTP id 113DA3600B2 for ; Thu, 6 Mar 2014 11:32:07 -0800 (PST) Received: by homiemail-mx23.g.dreamhost.com (Postfix, from userid 14307373) id 43EF962A9E458; Thu, 6 Mar 2014 11:32:07 -0800 (PST) X-Original-To: glibc@patchwork.siddhesh.in Delivered-To: x14307373@homiemail-mx23.g.dreamhost.com 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 homiemail-mx23.g.dreamhost.com (Postfix) with ESMTPS id 27BB562A9E44B for ; Thu, 6 Mar 2014 11:32:07 -0800 (PST) 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:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding; q=dns; s=default; b=XOg0DT0v3TtRnvBYocNXz5/QPtM2H/5/LIiUfFi+pZ5 ejuZPnzvsZgJBwK4b3/IlqwxDdEqUUBIaA/L0SGPA6w36+foS4WqiWqlPRacd/w5 f4X2bxBa9A+7osbFezgjpo0FODqZsff6wp7gVEjRHJ+pKjConWUzyBmpdrxqyKh4 = 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:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding; s=default; bh=/GhwjNKKm2wivMjb09/RgIz03cU=; b=LHYBCjIQ0Cv3qzU0u 4ZxWrNgE9zNahsmaOdlF3sxK/JB2XM9/t6cMsSHy2jeS+GqwfHIgfp7ekI4GKvNM a1Na28ceuea7PJS6nYM/mh7shCGy1rTk8dXhR00NORtyzs1f91gd9b/NHZZyXRoP 1CWqKnSXYhHy1VpD41rPCAAFaU= Received: (qmail 8664 invoked by alias); 6 Mar 2014 19:32:05 -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 Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 8651 invoked by uid 89); 6 Mar 2014 19:32:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com From: "Wilco" To: "'Joseph Myers'" Cc: References: <000b01cf3949$7e3a0080$7aae0180$@com> In-Reply-To: Subject: RE: [PATCH] [ARM] ] Add support for fenv_private on ARM Date: Thu, 6 Mar 2014 19:31:57 -0000 Message-ID: <000c01cf3972$bd2b72f0$378258d0$@com> MIME-Version: 1.0 X-MC-Unique: 114030619320000301 X-DH-Original-To: glibc@patchwork.siddhesh.in On Thu, 6 Mar 2014, Joseph Myers wrote: > ARM_HAVE_VFP isn't suitable for use in #if; see the > sysdeps/unix/sysv/linux/arm/arm-features.h definition. You need either a > new macro meaning "VFP is known at compile time to be available", or to > move to checks with "if" inside the functions. Good point - it appears __SOFTFP__ is what I wanted: > (The case of a soft-float build, VFP hardware available at runtime - the > one addressed by "if" conditionals - has other problems with exceptions > and rounding modes, that I think would best be addressed by use of IFUNCs > in libgcc for the relevant RTABI functions; see bug 10064. Anyway, the > present patch is purely an optimization, so there's certainly no need for > it to cover all cases as long as it doesn't break them.) I think the best option is to not change the behaviour of fenv when you use softfp but run on a CPU that supports VFP - especially since softfp doesn't support rounding modes or exceptions. I'm working on a patch to improve fenv with the same optimizations and clean up the code, so can fix all the if (ARM_HAVE_VFP) to use __SOFTFP__. On a related issue, the fenv testing code doesn't check the return code of the fenv functions, which causes failures. It also assumes that fenv functions set errno when this is not part of the C99 spec. Is that on purpose or a bug? Wilco diff --git a/sysdeps/arm/fenv_private.h b/sysdeps/arm/fenv_private.h index 6c65cfa..0b73816 100644 --- a/sysdeps/arm/fenv_private.h +++ b/sysdeps/arm/fenv_private.h @@ -23,7 +23,7 @@ #include #include -#if ARM_HAVE_VFP +#ifndef __SOFTFP__ static __always_inline void libc_feholdexcept_vfp (fenv_t *envp)