From patchwork Wed Jun 12 15:13:49 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 250809 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 7F9E32C0099 for ; Thu, 13 Jun 2013 01:14:04 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; q=dns; s=default; b=pAcis7aghvZY7krl98XPIbZAHa2vX80rpGpomO39s30RFIi3z7 ALXZZ09kZLlYL8hi/eHqkYEM3vtwMbqWS856quxDfEgeTXHbg6Un69mLHMeM0xGP paA7pi5+2ra3HP/iEe8WC+ob9BsjWOS8cv7CV01mi8gSHD277AdBB1eQE= 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:date :from:to:cc:subject:message-id:mime-version:content-type; s= default; bh=H//gNMDopOjGweSsJiudf0z69wY=; b=S0RfjtHBDz1GwRDQaNX9 eNcK1kITyHXFNkjed6BQDprl5mrtNSz9RbguK2LW7SmQRIOBgGSFk4f+SF9xWcwx QIsdYI8OqXQy/kX3nUs9jCPo0tskopEbJ0zPCQdEEVZQ+AA76lwtK13vHU7qk2vL KcCMQO+0dR3uFHAe7dcWpVY= Received: (qmail 31978 invoked by alias); 12 Jun 2013 15:13:57 -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 31968 invoked by uid 89); 12 Jun 2013 15:13:57 -0000 X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, SPF_PASS autolearn=ham version=3.3.1 Received: from mail-ob0-f179.google.com (HELO mail-ob0-f179.google.com) (209.85.214.179) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 12 Jun 2013 15:13:56 +0000 Received: by mail-ob0-f179.google.com with SMTP id xk17so13428705obc.10 for ; Wed, 12 Jun 2013 08:13:54 -0700 (PDT) X-Received: by 10.60.37.233 with SMTP id b9mr15916442oek.27.1371050034814; Wed, 12 Jun 2013 08:13:54 -0700 (PDT) Received: from bubble.grove.modra.org ([101.166.26.37]) by mx.google.com with ESMTPSA id wv8sm33562500obb.2.2013.06.12.08.13.52 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Jun 2013 08:13:54 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 8D2A4EA009D; Thu, 13 Jun 2013 00:43:49 +0930 (CST) Date: Thu, 13 Jun 2013 00:43:49 +0930 From: Alan Modra To: gcc-patches@gcc.gnu.org Cc: Richard Sandiford , David Edelsohn Subject: RFC [MIPS, RS6000] Mangling of IBM long double template literals Message-ID: <20130612151349.GB21523@bubble.grove.modra.org> Mail-Followup-To: gcc-patches@gcc.gnu.org, Richard Sandiford , David Edelsohn MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) As noted in the comment below, IBM long double is really an array of two doubles. In little-endian mode this means the words of each double should be reversed in write_real_cst, but the large magnitude double remains the first element of the array. This patch specially treats IBM long double so that mangling for template literal args of a given long double value is the same for both little and big endian. Bootstrapped etc. powerpc64-linux. This is of course an ABI change for any existing little-endian users of IBM long double literals in templates. On powerpc, I think we can safely say there are no such users. However it does look like MIPS also uses a variant of IBM long double, and I'm less certain there. * mangle.c (write_real_cst): Specially treat IBM long double. Index: gcc/cp/mangle.c =================================================================== --- gcc/cp/mangle.c (revision 199975) +++ gcc/cp/mangle.c (working copy) @@ -1591,28 +1591,35 @@ write_real_cst (const tree value) { if (abi_version_at_least (2)) { + const struct real_format *fmt; long target_real[4]; /* largest supported float */ char buffer[9]; /* eight hex digits in a 32-bit number */ - int i, limit, dir; + int i, limit, dir, twid; tree type = TREE_TYPE (value); int words = GET_MODE_BITSIZE (TYPE_MODE (type)) / 32; - real_to_target (target_real, &TREE_REAL_CST (value), - TYPE_MODE (type)); + fmt = REAL_MODE_FORMAT (TYPE_MODE (type)); + real_to_target_fmt (target_real, &TREE_REAL_CST (value), fmt); /* The value in target_real is in the target word order, so we must write it out backward if that happens to be little-endian. write_number cannot be used, it will produce uppercase. */ if (FLOAT_WORDS_BIG_ENDIAN) - i = 0, limit = words, dir = 1; + i = 0, limit = words, dir = 1, twid = 0; + else if (fmt->pnan < fmt->p) + /* This is an IBM extended double format made up of two IEEE + doubles. When little-endian, the doubles are in + little-endian word order, but the array order stays the + same. */ + i = 0, limit = words, dir = 1, twid = 1; else - i = words - 1, limit = -1, dir = -1; + i = words - 1, limit = -1, dir = -1, twid = 0; for (; i != limit; i += dir) { - sprintf (buffer, "%08lx", (unsigned long) target_real[i]); + sprintf (buffer, "%08lx", (unsigned long) target_real[i ^ twid]); write_chars (buffer, 8); } }