From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118283 invoked by alias); 8 Jun 2017 14:32:54 -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 117156 invoked by uid 89); 8 Jun 2017 14:32:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*RU:cmgw2, Hx-spam-relays-external:cmgw2, H*r:cmgw2, Hx-spam-relays-external:10.0.90.83 X-HELO: gproxy7.mail.unifiedlayer.com Received: from gproxy7-pub.mail.unifiedlayer.com (HELO gproxy7.mail.unifiedlayer.com) (70.40.196.235) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Jun 2017 14:32:49 +0000 Received: from cmgw2 (unknown [10.0.90.83]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id D3D372160DF for ; Thu, 8 Jun 2017 08:32:51 -0600 (MDT) Received: from box522.bluehost.com ([74.220.219.122]) by cmgw2 with id WEYo1v00k2f2jeq01EYrVW; Thu, 08 Jun 2017 08:32:51 -0600 X-Authority-Analysis: v=2.2 cv=Ibz3YSia c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=LWSFodeU3zMA:10 a=Dh5RJQ9EyPBqE2bI2pQA:9 a=v2312BZ5C20A:10 Received: from 174-29-39-24.hlrn.qwest.net ([174.29.39.24]:34124 helo=pokyo) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1dIyUS-0005WI-Cd; Thu, 08 Jun 2017 08:32:48 -0600 From: Tom Tromey To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFA 0/5] improve printing of 128 bit ints References: <20170602193651.3173-1-tom@tromey.com> Date: Thu, 08 Jun 2017 14:32:00 -0000 In-Reply-To: <20170602193651.3173-1-tom@tromey.com> (Tom Tromey's message of "Fri, 2 Jun 2017 13:36:46 -0600") Message-ID: <87y3t24kja.fsf@pokyo> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Exim-ID: 1dIyUS-0005WI-Cd X-Source-Sender: 174-29-39-24.hlrn.qwest.net (pokyo) [174.29.39.24]:34124 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-SW-Source: 2017-06/txt/msg00213.txt.bz2 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? thanks, Tom