From: johan556@... Date: 2016-03-24T06:08:50+00:00 Subject: [ruby-core:74506] [Ruby trunk Bug#12209] Array#pack("G") problem Issue #12209 has been updated by Johan Holmberg. I am aware of the x87 vs. SSE2 differences, but I don't think this issue has anything to do with that. Note that my example demonstrated that a given Float, when processed by pack("G") + unpack("G") is changed into another bit pattern. No floating point calculation is involved. Also note that when pack("D") + unpack("D") is used, I get back the bit pattern I started with. That should have happened with "G" too. The difference between these two cases is that conversions with "D" uses "native format", but "G" uses "network (big-endian) byte order". And for "network byte order", the macro HTOND used in "pack.c" was supposed to rearrange the bytes in the correct order. In both 32-bit and 64-bit Ruby, a Float is a "double" at C level and has size 64-bit. ---------------------------------------- Bug #12209: Array#pack("G") problem https://bugs.ruby-lang.org/issues/12209#change-57625 * 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: