[ruby-core:74528] [Ruby trunk Bug#12209] Array#pack("G") problem

Issue #12209 has been updated by Kazuho Oku.


This is obviously a bug in the Ruby-side.

The original code, after swapping the bytes of a double, assigns it to a double.

~~~
d = (..., d);
~~~

At this point, the bit pattern of d ends with f67f, which is a signalling NAN for x87.

However, there is no guarantee that the bit pattern of a NAN is retained after being assigned.  In this case, I assume x87 is converting the value to quiet NAN, as discussed in http://stackoverflow.com/questions/22816095/signalling-nan-was-corrupted-when-returning-from-x86-function-flds-fstps-of-x87.

That is why the bit pattern changes to fe7f.

----------------------------------------
Bug #12209: Array#pack("G") problem
https://bugs.ruby-lang.org/issues/12209#change-57652

* Author: Johan Holmberg
* Status: Feedback
* Priority: Normal
* Assignee: 
* ruby -v: ruby 2.4.0dev (2016-03-23 trunk 54235) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
Array#pack("G") gives incorrect result *sometimes*. The problem occurs with:

* all Ruby versions I have tried: 2.0.0, 2.3.0 and Subversion-trunk (all built from source)
* only with 32-bit builds (not 64-bit)
* only with GCC (not CLANG)
* with GCC 4.8.5 (from Ubuntu 14.04) and also with 5.3.1 (from Ubuntu 16.04 beta)
* also with a Ruby 2.0.0 on Windows (installed with RubyInstaller I think) 

The function failing is "HTOND" (it is really a macro) in "pack.c" in the function "pack_value".
When it is called, the macro expands to (reformatted for easy reading):

~~~
                d = (memcpy(&(dtmp),&(d),sizeof(double)),
                     (dtmp) = (0?((uint64_t)(dtmp)):__builtin_bswap64((uint64_t)(dtmp))),
                     memcpy(&(d),&(dtmp),sizeof(double)),
                     (d));

~~~

If I brake this complicated expression apart manually into two statements and rebuild ruby with this code:

~~~
                memcpy(&(dtmp),&(d),sizeof(double));
                ((dtmp) = (0?((uint64_t)(dtmp)):__builtin_bswap64((uint64_t)(dtmp))),
                 memcpy(&(d),&(dtmp),sizeof(double)),
                 (d));
~~~

the problem goes away. My conclusion is that GCC is too "aggressive" when optimizing the code as it looks
in the Ruby source, and my change stops GCC from doing that. As mentioned above, Ruby built with CLANG
doesn't seem to have this problem (Ubuntu 16.04 beta + 32-bit Ruby + Clang 3.8). And if I build "pack.c" with GCC
using "-O0" instead of "-O3" the probolem also seem to go away.

A simple example to demonstrate the problem is:

~~~
f = 2.769637943971985816
puts 'pack("D") failed' if [f].pack("D").unpack("D")[0] != f
puts 'pack("G") failed' if [f].pack("G").unpack("G")[0] != f

# output: pack("G") failed

# wrong   bit pattern: 40062837f038fe7f
# correct bit pattern: 40062837f038f67f
~~~

Even if this turns out to be a pure GCC bug (I'm not absolutely certain about this),
it becomes a Ruby problem too since it seem to exist in all 32-bit Rubys I have tried.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>