From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id A098C17D93F4 for ; Tue, 15 Jul 2014 14:29:28 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [133.44.2.201]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id E7501B5D89B for ; Tue, 15 Jul 2014 14:54:04 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (localhost.nagaokaut.ac.jp [127.0.0.1]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id AEC6597A832 for ; Tue, 15 Jul 2014 14:54:06 +0900 (JST) X-Virus-Scanned: amavisd-new at nagaokaut.ac.jp Received: from funfun.nagaokaut.ac.jp ([127.0.0.1]) by funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9rQLbnDy_HW for ; Tue, 15 Jul 2014 14:54:06 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 8D10F97A82C for ; Tue, 15 Jul 2014 14:54:06 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id 8E76495243E for ; Tue, 15 Jul 2014 14:54:04 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id B1F9E120486; Tue, 15 Jul 2014 14:53:53 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTP id 74100120459 for ; Tue, 15 Jul 2014 14:53:46 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 562A2208B4; Tue, 15 Jul 2014 05:53:45 +0000 (UTC) Date: Tue, 15 Jul 2014 05:53:45 +0000 From: Eric Wong To: Ruby developers Message-ID: <20140715055345.GA32459@dcvr.yhbt.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 63722 Subject: [ruby-core:63722] Re: [ruby-trunk - Bug #10037] [Open] Since r46798 on Solaris, "[BUG] rb_vm_get_cref: unreachable" during make X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" 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.