From patchwork Sun Mar 31 00:40:42 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stafford Horne X-Patchwork-Id: 32099 Received: (qmail 92523 invoked by alias); 31 Mar 2019 00:41:15 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 92444 invoked by uid 89); 31 Mar 2019 00:41:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-22.8 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS, URIBL_BLOCKED autolearn=ham version=3.3.1 spammy=bfd_endian_big, BFD_ENDIAN_BIG, HX-Spam-Relays-External:sk:mail-pf, H*r:sk:mail-pf X-HELO: mail-pf1-f180.google.com Received: from mail-pf1-f180.google.com (HELO mail-pf1-f180.google.com) (209.85.210.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 31 Mar 2019 00:41:13 +0000 Received: by mail-pf1-f180.google.com with SMTP id 8so2783793pfr.4 for ; Sat, 30 Mar 2019 17:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=bQa52dEk5M9yp2q+QMm9+upEczVVd1Hv77sfY3nA9Ik=; b=kd1mAczYBNqgHTJvezCNJnxwadCTZShGO3/a5LhmnxFYBHkw09XiRfMqa0g40qY9Hv +RSZYvQCPK9p9fbCj5E+9sOFnsq9eWKyJyGWO22CP6Q9qWyJ400eM7RU5iZriYggERwJ zVk7mZ/MrvRALOpjITGLHk/iYQFnqz8y/84DmuUOHCHXD5M5Ps8ZFA1RI904bjyhqlkK q8hhmSR1WD+D0jmQs0SmWAg3nS6IzHYtBqCussO381XRiv3Ji4KngZQwf5ifNf/5I/qN ZOgj6SQsTkhgJaEICP02t24jGS5QRNXaUbBCYM3RFbb9SxmIt5Gqd7/Eox7z0sUzjVxE IY7w== Return-Path: Received: from localhost (g191.61-115-60.ppp.wakwak.ne.jp. [61.115.60.191]) by smtp.gmail.com with ESMTPSA id k12sm7597865pfk.109.2019.03.30.17.41.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 30 Mar 2019 17:41:10 -0700 (PDT) From: Stafford Horne To: GDB patches Cc: Andrey Bacherov , Openrisc , Stafford Horne Subject: [PATCH 6/6] sim/common: Fix issue with wrong byte order on BE targets Date: Sun, 31 Mar 2019 09:40:42 +0900 Message-Id: <20190331004042.12172-7-shorne@gmail.com> In-Reply-To: <20190331004042.12172-1-shorne@gmail.com> References: <20190331004042.12172-1-shorne@gmail.com> MIME-Version: 1.0 X-IsSubscribed: yes Currently only the OpenRISC sim uses this JOINSIDF() function to compose a double float from 2 registers. The old code doesn't seem to work as the work order gets swapped when running on a x86_64 host. This change fixes that, but I am not sure if its the best thing to do. On mips they do similar reg pair floating point operations composing doubles from 2 32-bit registers in sim/mips/cp1.c value_fpr(). sim/common/ChangeLog: * cgen-ops.h (JOINSIDF): Fix big endian check. --- sim/common/cgen-ops.h | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/sim/common/cgen-ops.h b/sim/common/cgen-ops.h index 841552066f..d718394723 100644 --- a/sim/common/cgen-ops.h +++ b/sim/common/cgen-ops.h @@ -431,12 +431,8 @@ JOINSIDI (SI x0, SI x1) SEMOPS_INLINE DF JOINSIDF (SI x0, SI x1) { - union { SI in[2]; DF out; } x; - if (CURRENT_TARGET_BYTE_ORDER == BFD_ENDIAN_BIG) - x.in[0] = x0, x.in[1] = x1; - else - x.in[1] = x0, x.in[0] = x1; - return x.out; + /* Making doubles is the same as making long longs. */ + return MAKEDI (x0, x1); } SEMOPS_INLINE XF