Power/AltiVec question (Re: [RFA 0/5] improve printing of 128 bit ints)

[Pedro Alves <palves at redhat dot com>]

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 <https://sourceware.org/bugzilla/show_bug.cgi?id=15318>,
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