From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7028 invoked by alias); 8 Jun 2017 16:12:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 7013 invoked by uid 89); 8 Jun 2017 16:12:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=0.1, draws X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Jun 2017 16:12:23 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C1B3730C426; Thu, 8 Jun 2017 16:12:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C1B3730C426 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C1B3730C426 Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0092817C77; Thu, 8 Jun 2017 16:12:25 +0000 (UTC) Subject: Power/AltiVec question (Re: [RFA 0/5] improve printing of 128 bit ints) To: Tom Tromey References: <20170602193651.3173-1-tom@tromey.com> <87y3t24kja.fsf@pokyo> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <0760241c-7347-26a7-950f-2341c4807f10@redhat.com> Date: Thu, 08 Jun 2017 16:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <87y3t24kja.fsf@pokyo> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00215.txt.bz2 On 06/08/2017 03:32 PM, Tom Tromey wrote: > Tom> I wanted to improve 128-bit integer support, primarily for Rust, > Tom> though I see in Bugzilla that I reported this bug at least twice for C > Tom> as well. > [...] > Tom> Regtested on the buildbot. > > I misread the results :(. The powerpc64le builds come much later than > the other results, and this confused me because I was running several > buildbot tests at the same time. > > Consider this excerpt from altivec-regs.exp: > > set vector_register ".uint128 = 0x00000001000000010000000100000001, v4_float = .0x0, 0x0, 0x0, 0x0., v4_int32 = .0x1, 0x1, 0x1, 0x1., v8_int16 = .0x1, 0x0, 0x1, 0x0, 0x1, 0x0, 0x1, 0x0., v16_int8 = .0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0.." > > This is an expected result from an "info regs". > > This looks to me like there's a specific 128-bit value with a 1 in the > low byte of each 4-byte word, but the test is expecting that the > v4_float part will print as 0x0. However, with my patches, the v4_float > parts print as 0x1. > > I tend to think the test here is incorrect. But, I thought I would > check in first. What should this actually print, and why? I'd expect that it prints 0x0 because "0x00000001", when reinterpreted (note, not cast/converted) as the storage for a 32-bit float of whatever format AltiVec uses, gives you a real number between 0 and 1. And then, considering , when that number is converted to integer for printing as hex, it it is converted to zero [as in, (int)0.1 => 0]. The test just below that one expects the same value to match "1.*e-45": set decimal_vector ".uint128 = 0x00000001000000010000000100000001, v4_float = .1.*e-45, 1.*e-45, 1.*e-45, 1.*e-45., v4_int32 = .1, 1, 1, 1., v8_int16 = .0, 1, 0, 1, 0, 1, 0, 1., v16_int8 = .0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 1.." Which seems to confirm it. I'm not really sure whether PR 15318 applies in this case, the Power backend may be doing something else, but that's my guess. I've changed to subject to see if it draws the attention of someone who might know for sure. Thanks, Pedro Alves