[#61171] Re: [ruby-changes:33145] normal:r45224 (trunk): gc.c: fix build for testing w/o RGenGC — SASADA Koichi <ko1@...>
(2014/03/01 16:15), normal wrote:
[#61243] [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops — normalperson@...
Issue #9425 has been updated by Eric Wong.
[#61359] [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs — normalperson@...
Issue #9609 has been reported by Eric Wong.
(2014/03/07 19:09), [email protected] wrote:
SASADA Koichi <[email protected]> wrote:
[#61424] [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals — Eric Wong <normalperson@...>
I'm unsure about this. I _hate_ the extra branches this adds;
Hi Eric,
SASADA Koichi <[email protected]> wrote:
(2014/03/14 2:12), Eric Wong wrote:
SASADA Koichi <[email protected]> wrote:
(2014/03/15 17:34), Eric Wong wrote:
[#61452] [ruby-trunk - Feature #9632] [Open] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been reported by Eric Wong.
[#61496] [ruby-trunk - Feature #9638] [Open] [PATCH] limit IDs to 32-bits on 64-bit systems — normalperson@...
Issue #9638 has been reported by Eric Wong.
[#61568] hash function for global method cache — Eric Wong <normalperson@...>
I came upon this because I noticed existing st numtable worked poorly
(2014/03/18 8:03), Eric Wong wrote:
SASADA Koichi <[email protected]> wrote:
what's the profit from using binary tree in place of hash?
Юрий Соколов <[email protected]> wrote:
[#61687] [ruby-trunk - Bug #9606] Ocassional SIGSEGV inTestException#test_machine_stackoverflow on OpenBSD — normalperson@...
Issue #9606 has been updated by Eric Wong.
[#61760] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been updated by Eric Wong.
[ruby-core:61563] [ruby-trunk - Bug #8358] TestSprintf#test_float test failuer
Issue #8358 has been updated by Anatol Pomozov. I maintain ruby package in Linux Arch and our users reported an issue with it https://bugs.archlinux.org/task/39470 We compile 32-bit binaries for old machines (PentiumPro+ CPU). The old CPUs do not have SSE2 support, but we've found that our 32-bit kernels contain SSE2 operations. ~~~ $ objdump -d /usr/lib/libruby.so | grep movapd | head 2c743: 66 0f 28 c8 movapd %xmm0,%xmm1 2c7e5: 66 0f 28 9b 10 89 f4 movapd -0xb76f0(%ebx),%xmm3 2c800: 66 0f 28 f3 movapd %xmm3,%xmm6 2c808: 66 0f 28 fb movapd %xmm3,%xmm7 32676: 66 0f 28 c8 movapd %xmm0,%xmm1 765d5: 66 0f 28 8b 10 89 f4 movapd -0xb76f0(%ebx),%xmm1 ~~~ After I reverted the whole sse2 block ~~~ - AS_CASE(["$target"], - [*-darwin*], [ - # doesn't seem necessary on Mac OS X - ], - [[i[4-6]86*]], [ - RUBY_TRY_CFLAGS(-msse2 -mfpmath=sse, [ - RUBY_APPEND_OPTION(XCFLAGS, -msse2 -mfpmath=sse) - ]) - AS_CASE(["$XCFLAGS"], - [[*-msse2*]], [ - RUBY_TRY_CFLAGS(-mstackrealign, [ - RUBY_APPEND_OPTION(XCFLAGS, -mstackrealign) - ]) - ]) - ] - ) ~~~ i686 binaries do not contain sse2 operations anymore, x86_64 (64 bit binaries for newer CPU) contain sse2 as expected. Tests "make test" are passed. Here are the compilation flags uses on Arch: ~~~ config.status: creating x86_64-linux-fake.rb CC = gcc LD = ld LDSHARED = gcc -shared CFLAGS = -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -fPIC XCFLAGS = -D_FORTIFY_SOURCE=2 -fstack-protector -fno-strict-overflow -fvisibility=hidden -DRUBY_EXPORT CPPFLAGS = -D_FORTIFY_SOURCE=2 -I. -I.ext/include/x86_64-linux -I./include -I. DLDFLAGS = -Wl,-soname,libruby.so.2.1 -fstack-protector SOLIBS = -lpthread -lgmp -ldl -lcrypt -lm ~~~ Note to "-march=x86-64" it is for 64-bit builds, on 32-bit builds it is "-march=i686". I believe this flags are enough to tell gcc whether sse2 should be enabled. compiler (at least on Linux Arch) does not need additional sse2 compilation flags. So my question: why to enable sse2 if the binary is compiled for i686 microarchitecture? "i686" is PentiumPro family that does not support sse2, sse2 is supported only starting from pentium4. See http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options ---------------------------------------- Bug #8358: TestSprintf#test_float test failuer https://bugs.ruby-lang.org/issues/8358#change-45846 * Author: Heesob Park * Status: Assigned * Priority: Immediate * Assignee: Yui NARUSE * Category: build * Target version: current: 2.2.0 * ruby -v: ruby 2.1.0dev (2013-05-01) [i386-mingw32] * Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN ---------------------------------------- I noticed TestSprintf#test_float http://ci.rubyinstaller.org/job/ruby-trunk-x86-test-all/1287/console 1) Failure: TestSprintf#test_float [C:/Users/Worker/Jenkins/workspace/ruby-trunk-x86-build/test/ruby/test_sprintf.rb:193]: [ruby-dev:42551]. <"0x1p+2"> expected but was <"0x1p+1">. This failure is due to r40404. And Actually, this issue is almost same to bug #8299. ruby_hdtoa function requires 53-bit precision but mingw32 compiler is 64-bit precision. There are 2 possible workarounds. 1. adding -msse2 -mfpmath=sse flag when compiling. 2. adding _control87(_PC_53, _MCW_PC) when running. ---Files-------------------------------- 0001-Properly-detect-platform-for-SSE2-instructions.patch (754 Bytes) -- httsp://bugs.ruby-lang.org/