This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 0/5] improve printing of 128 bit ints
- From: Tom Tromey <tom at tromey dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 08 Jun 2017 08:32:41 -0600
- Subject: Re: [RFA 0/5] improve printing of 128 bit ints
- Authentication-results: sourceware.org; auth=none
- References: <20170602193651.3173-1-tom@tromey.com>
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