From: Eric Wong <normalperson@...>
Date: 2014-07-15T05:53:45+00:00
Subject: [ruby-core:63722] Re: [ruby-trunk - Bug #10037] [Open] Since r46798 on Solaris, "[BUG] rb_vm_get_cref: unreachable" during make

ngotogenome@gmail.com wrote:
> I think it is possbile that the first 8 byte (in 64-bit architecture)
> of "struct rb_iseq_struct" is sometimes used for some other purposes
> (maybe VALUE ?), and on big-endian 64-bit architecture (including
> SPARC64), it is frequently misunderstood as the other type.

That sounds strange.  I'll wait for ko1 to comment.

I tried valgrind, but that did not report errors on x86-64 when I tried
"make newline.c".  tool/transcode-tblgen.rb ran without errors.

> By the way, I think "int stack_max" is better than "uint32_t
> stack_max" because it seems that all calculations of stack_max in
> compile.c(iseq_set_sequence) and vm_insnhelper.c(vm_push_frame) are
> conducted using int.

I agree, that may be changed to int.

Since enum is also signed int type, maybe having 32-bit signed and
unsigned types next to each other is confusing the compiler?

Can you try "int stack_max"?  Thanks.