From: naruse@... Date: 2016-03-24T04:20:46+00:00 Subject: [ruby-core:74505] [Ruby trunk Bug#12209][Feedback] Array#pack("G") problem Issue #12209 has been updated by Yui NARUSE. Status changed from Open to Feedback It looks because of x87 FPU's internal calculation behavior. x87 always calculates floating points with 80bit precision on their register, even if the number is 64bit double. And only when the number is assigned to a 64bit double variable, the number is rounded into 64bit. It seems the reason why when you use ';' instead of ',', the issue disappear. You may force FPU to always round in 64bit by following ways: (1) assign the number to a variable (2) specify -ffloat-store for gcc/clang, -Op for VC6, -fp:precise for VC8+. (3) specify -msse2 -mfpmath=sse or similar one (1) is the one Vit suggested and marcandre commited. It is still problematic because a smart C compiler will optimize out a variable. Failed test results I showed in are because of it. So you must add volatile to guard the variable from such optimization. But it is barrier for optimization on non x87 FPU. (2) is not so good because it effects above volatile effect all over the code. It degrade the speed. (3) uses SSE2 to calculate floating point numbers. This doesn't have such speed penalty, but it is less portable for CPUs. ---------------------------------------- Bug #12209: Array#pack("G") problem https://bugs.ruby-lang.org/issues/12209#change-57624 * 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: