From patchwork Sun Sep 29 02:14:34 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oleg Endo X-Patchwork-Id: 1168947 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-509787-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=t-online.de Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="tVNZ1fyM"; dkim-atps=neutral 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 ozlabs.org (Postfix) with ESMTPS id 46gpyg4Z71z9sNF for ; Sun, 29 Sep 2019 12:15:05 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:subject:from:to:date:content-type:mime-version; q= dns; s=default; b=PYfafNTC14+ejCQdRPs5J/pLFbKaQ9WcfLdlcHjV3a1tYs qz8nlePdx65QMhZv6H/AiG+03lF4RFIY8IODgdxG/EJVh/qX5OjP6/f5orXBdrxp 0V0cKVz5PGycrOjEqCT6P6T+lYdWleEQhjpwUbKTfebtThysH5/+513Lh+Abc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:subject:from:to:date:content-type:mime-version; s= default; bh=vrpy3CSTLniiGjSiAOGAPtUMDUY=; b=tVNZ1fyMff25m6md0g1I gXnGwiGBheXCQG57uIrJa4sMxNmVLWhWK0cZ0dDdH0pw6LxVsju8bXhKxt02K8KH mabhKhdx2kGCJ7502SetReTCXa62ThYVbzBdlQn9HGXA3SMZ/sM0F6sLO20iIqfr x+DYHwLZmKZ++ZckYhNgk8c= Received: (qmail 112537 invoked by alias); 29 Sep 2019 02:14:54 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 112429 invoked by uid 89); 29 Sep 2019 02:14:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.7 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPOOFED_FREEMAIL autolearn=ham version=3.3.1 spammy=automated, swapped, H*r:sk:mailout, story X-HELO: mailout04.t-online.de Received: from mailout04.t-online.de (HELO mailout04.t-online.de) (194.25.134.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 29 Sep 2019 02:14:43 +0000 Received: from fwd39.aul.t-online.de (fwd39.aul.t-online.de [172.20.27.138]) by mailout04.t-online.de (Postfix) with SMTP id A67EF41F6FC3 for ; Sun, 29 Sep 2019 04:14:40 +0200 (CEST) Received: from yam-desktop (bKEAloZlohhK2wD9rx27p5YarCNPYxU6yevqtQwi2UmH8nhcJoOJGjnOrBUF8woZOL@[163.58.16.102]) by fwd39.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1iEOjO-48m6Ua0; Sun, 29 Sep 2019 04:14:38 +0200 Message-ID: Subject: [RFH][libgcc] fp-bit bit ordering (PR 78804) From: Oleg Endo To: gcc-patches Date: Sun, 29 Sep 2019 11:14:34 +0900 Mime-Version: 1.0 X-IsSubscribed: yes Hi, I've been dragging this patch along with me for a while. At the moment, I don't have the resources to fully test it as requested by Ian in the PR discussion. So I would like to ask for general comments on this one and hope that folks with bigger automated test setups can run the patch through their machinery for little endian targets. Summary of the story: I've noticed this issue on the RX on GCC 6, but it seems it's been there forever. On RX, fp-bit is used for software floating point emulation. The RX target also uses "MS bit-field" layout by default. This means that code like struct { fractype fraction:FRACBITS __attribute__ ((packed)); unsigned int exp:EXPBITS __attribute__ ((packed)); unsigned int sign:1 __attribute__ ((packed)); } bits; will result in sizeof (bits) != 8 For some reason, this bit-field style declaration is used only for FLOAT_BIT_ORDER_MISMATCH, which generally seems to be set for little endian targets. In other cases (i.e. big endian) open coded bit field extraction and packing is used on the base integer type, like fraction = src->value_raw & ((((fractype)1) << FRACBITS) - 1); exp = ((int)(src->value_raw >> FRACBITS)) & ((1 << EXPBITS) - 1); sign = ((int)(src->value_raw >> (FRACBITS + EXPBITS))) & 1; This works of course regardless of the bit-field packing layout of the target. Joseph suggested to pack the struct bit, which would fix the issue. https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01651.html However, I would like to propose to remove the special case of FLOAT_BIT_ORDER_MISMATCH altogether as in the attached patch. Any comments? Cheers, Oleg libgcc/ChangeLog PR libgcc/77804 * fp-bit.h: Remove FLOAT_BIT_ORDER_MISMATCH. * fp-bit.c (pack_d, unpack_d): Remove special cases for FLOAT_BIT_ORDER_MISMATCH. * config/arc/t-arc: Remove FLOAT_BIT_ORDER_MISMATCH. Index: libgcc/config/arc/t-arc =================================================================== --- libgcc/config/arc/t-arc (revision 251045) +++ libgcc/config/arc/t-arc (working copy) @@ -46,7 +46,6 @@ dp-bit.c: $(srcdir)/fp-bit.c echo '#ifndef __big_endian__' > dp-bit.c - echo '#define FLOAT_BIT_ORDER_MISMATCH' >> dp-bit.c echo '#endif' >> dp-bit.c echo '#include "fp-bit.h"' >> dp-bit.c echo '#include "config/arc/dp-hack.h"' >> dp-bit.c @@ -55,7 +54,6 @@ fp-bit.c: $(srcdir)/fp-bit.c echo '#define FLOAT' > fp-bit.c echo '#ifndef __big_endian__' >> fp-bit.c - echo '#define FLOAT_BIT_ORDER_MISMATCH' >> fp-bit.c echo '#endif' >> fp-bit.c echo '#include "config/arc/fp-hack.h"' >> fp-bit.c cat $(srcdir)/fp-bit.c >> fp-bit.c Index: libgcc/fp-bit.c =================================================================== --- libgcc/fp-bit.c (revision 251045) +++ libgcc/fp-bit.c (working copy) @@ -316,12 +316,7 @@ /* We previously used bitfields to store the number, but this doesn't handle little/big endian systems conveniently, so use shifts and masks */ -#ifdef FLOAT_BIT_ORDER_MISMATCH - dst.bits.fraction = fraction; - dst.bits.exp = exp; - dst.bits.sign = sign; -#else -# if defined TFLOAT && defined HALFFRACBITS +#if defined TFLOAT && defined HALFFRACBITS { halffractype high, low, unity; int lowsign, lowexp; @@ -394,11 +389,10 @@ } dst.value_raw = ((fractype) high << HALFSHIFT) | low; } -# else +#else dst.value_raw = fraction & ((((fractype)1) << FRACBITS) - (fractype)1); dst.value_raw |= ((fractype) (exp & ((1 << EXPBITS) - 1))) << FRACBITS; dst.value_raw |= ((fractype) (sign & 1)) << (FRACBITS | EXPBITS); -# endif #endif #if defined(FLOAT_WORD_ORDER_MISMATCH) && !defined(FLOAT) @@ -450,12 +444,7 @@ src = &swapped; #endif -#ifdef FLOAT_BIT_ORDER_MISMATCH - fraction = src->bits.fraction; - exp = src->bits.exp; - sign = src->bits.sign; -#else -# if defined TFLOAT && defined HALFFRACBITS +#if defined TFLOAT && defined HALFFRACBITS { halffractype high, low; @@ -498,11 +487,10 @@ } } } -# else +#else fraction = src->value_raw & ((((fractype)1) << FRACBITS) - 1); exp = ((int)(src->value_raw >> FRACBITS)) & ((1 << EXPBITS) - 1); sign = ((int)(src->value_raw >> (FRACBITS + EXPBITS))) & 1; -# endif #endif dst->sign = sign; Index: libgcc/fp-bit.h =================================================================== --- libgcc/fp-bit.h (revision 251045) +++ libgcc/fp-bit.h (working copy) @@ -128,10 +128,6 @@ #define NO_DI_MODE #endif -#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ -#define FLOAT_BIT_ORDER_MISMATCH -#endif - #if __BYTE_ORDER__ != __FLOAT_WORD_ORDER__ #define FLOAT_WORD_ORDER_MISMATCH #endif @@ -354,16 +350,6 @@ # endif #endif -#ifdef FLOAT_BIT_ORDER_MISMATCH - struct - { - fractype fraction:FRACBITS __attribute__ ((packed)); - unsigned int exp:EXPBITS __attribute__ ((packed)); - unsigned int sign:1 __attribute__ ((packed)); - } - bits; -#endif - #ifdef _DEBUG_BITFLOAT struct {