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

Issue #12209 has been updated by Usaku NAKAMURA.

Backport changed from 2.1: WONTFIX, 2.2: REQUIRED, 2.3: DONE to 2.1: WONTFIX, 2.2: DONE, 2.3: DONE

ruby_2_2 r55927 merged revision(s) 55573.

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

* Author: Johan Holmberg
* Status: Closed
* Priority: Normal
* Assignee: 
* ruby -v: ruby 2.4.0dev (2016-03-23 trunk 54235) [x86_64-linux]
* Backport: 2.1: WONTFIX, 2.2: DONE, 2.3: DONE
----------------------------------------
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>