From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32152 invoked by alias); 19 Jul 2012 12:55:17 -0000 Received: (qmail 32141 invoked by uid 22791); 19 Jul 2012 12:55:15 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_50,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Jul 2012 12:55:02 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SrqFx-000144-Ft from Paul_Brook@mentor.com ; Thu, 19 Jul 2012 05:55:01 -0700 Received: from SVR-IES-FEM-02.mgc.mentorg.com ([137.202.0.106]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jul 2012 05:55:06 -0700 Received: from nowt.org (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.1.289.1; Thu, 19 Jul 2012 13:54:59 +0100 Received: from wren.localnet (wren.home [192.168.93.7]) by nowt.org (Postfix) with ESMTP id B147B6D9CB; Thu, 19 Jul 2012 13:54:58 +0100 (BST) From: Paul Brook To: Julian Brown Subject: Re: RTABI half-precision conversion functions (ping) Date: Thu, 19 Jul 2012 12:55:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.2.0-3-amd64; KDE/4.8.4; x86_64; ; ) CC: , , , References: <20120719132816.2b51c0bc@octopus> In-Reply-To: <20120719132816.2b51c0bc@octopus> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Message-ID: <201207191354.58297.paul@codesourcery.com> Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-07/txt/msg00908.txt.bz2 > Hi, > > The patch that Andrew Stubbs sent upstream here: > > http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02130.html > > seems to have become stalled after Ramana's question here: > > http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00291.html > > This was discussed with ARM personnel (i.e. Lee Smith) at the time the > patch was created. AFAICT, our reasoning went like this (Paul, please > correct me if I'm just making stuff up): we wish to use aliases for the > old and new names for the helpers. The existing > __gnu_{f2h,h2f}_{ieee,alternative} helpers take unsigned short > arguments, and therefore assume (on function entry) that the values > contained in those arguments are zero-extended (although, due to the > vagaries of libcall handling in GCC, that may not actually be true -- > at the time, this was a latent bug, and may in fact still be). The > __aeabi_* helpers are defined to pass/return unadorned "short" values, > intending to convey that only the low-order 16 bits of half-float > values contain meaningful data. Yes, that matches my understanding. > But, that means EABI-conformant callers are also perfectly entitled to > sign-extend half-float values before calling our helper functions > (although GCC itself won't do that). Using "unsigned int" and taking > care to only examine the low-order bits of the value in the helper > function itself serves to fix the latent bug, is compatible with > existing code, allows us to be conformant with the eabi, and allows use > of aliases to make the __gnu and __aeabi functions the same. As long as LTO never sees this mismatch we should be fine :-) AFAIK we don't curently have any way of expressing the actual ABI. > The patch no longer applied as-is, so I've updated it (attached, > re-tested). Note that there are no longer any target-independent changes > (though I'm not certain that the symbol versions are still correct). > > OK to apply? I think this deserves a comment in the source. Otherwise it's liable to get "fixed" in the future :-) Something allong the lines of "While the EABI describes the arguments to the half-float helper routines as 'short', it does not require that they be extended to full register width. The normal ABI requres that the caller sign/zero extend short values to 32 bit. We use unsigned int arguments to prevent the gcc making assumptions about the high half of the register." Paul