From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26630 invoked by alias); 9 Aug 2012 17:21:17 -0000 Received: (qmail 26606 invoked by uid 22791); 9 Aug 2012 17:21:15 -0000 X-SWARE-Spam-Status: No, hits=-5.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_HW X-Spam-Check-By: sourceware.org Received: from mail-pb0-f41.google.com (HELO mail-pb0-f41.google.com) (209.85.160.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 09 Aug 2012 17:20:54 +0000 Received: by pbbro12 with SMTP id ro12so1352661pbb.0 for ; Thu, 09 Aug 2012 10:20:54 -0700 (PDT) Received: by 10.68.231.163 with SMTP id th3mr5662721pbc.55.1344532853877; Thu, 09 Aug 2012 10:20:53 -0700 (PDT) Received: from [192.168.2.18] (bas3-ottawa23-1128747067.dsl.bell.ca. [67.71.80.59]) by mx.google.com with ESMTPS id qr2sm1500227pbc.44.2012.08.09.10.20.52 (version=SSLv3 cipher=OTHER); Thu, 09 Aug 2012 10:20:53 -0700 (PDT) Message-ID: <5023F173.1040506@systemhalted.org> Date: Thu, 09 Aug 2012 17:21:00 -0000 From: Carlos O'Donell User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Roland McGrath CC: "Joseph S. Myers" , libc-ports@sourceware.org Subject: Re: [PATCH roland/arm-hwcap-vfp] don't use HWCAP_ARM_* in OS-independent code References: <20120808235921.AA4292C075@topped-with-meat.com> <20120809171033.CC7D32C0FD@topped-with-meat.com> In-Reply-To: <20120809171033.CC7D32C0FD@topped-with-meat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2012-08/txt/msg00077.txt.bz2 On 8/9/2012 1:10 PM, Roland McGrath wrote: >> __VFP_FP__ doesn't mean "generating VFP instructions", it means >> "floating-point types have VFP layout" (i.e. normal IEEE floating-point >> with the same byte ordering / endianness as integer types, as opposed to >> FPA format), which is always true for EABI. The relevant test for >> "generating VFP instructions" is defined __VFP_FP__ && !defined __SOFTFP__ >> (which can be simplified to just !defined __SOFTFP__ given that EABI is >> assumed). > > Thanks for the explanation. I've changed the conditionals. On further > reflection I also decided that using ldsodefs.h was just too ugly and I've > added an arm-features.h instead. > > How does this look now? > > > Thanks, > Roland > > > ports/ChangeLog.arm > 2012-08-09 Roland McGrath > > * sysdeps/arm/arm-features.h: New file. > * sysdeps/unix/sysv/linux/arm/arm-features.h: New file. If we are going to make a new internal header for this kind of thing can you please add a "Internal Headers" section in the "Internals Documentation" part of the wiki and mention briefly "*-features.h" and when and why you might use it? http://sourceware.org/glibc/wiki/HomePage#InternalsDocumentation Alternatively add this to manual/maint.texi please :-) Cheers, Carlos.