From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49629 invoked by alias); 29 Jun 2015 21:16:08 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 49613 invoked by uid 89); 29 Jun 2015 21:16:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Message-ID: <1435612102.13727.173.camel@surprise> Subject: Re: Weird problem From: David Malcolm To: Dibyendu Majumdar Cc: jit@gcc.gnu.org Date: Thu, 01 Jan 2015 00:00:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-SW-Source: 2015-q2/txt/msg00133.txt.bz2 On Mon, 2015-06-29 at 21:49 +0100, Dibyendu Majumdar wrote: > Hi Dave, > > I am trying to debug a problem I am having with one piece of code. > > The generated code (snippet) is shown below: > > double OP_RAVI_TOFLT_n_2_8; > bool comparison_0_12; > comparison_0_12 = luaV_tonumber_ (&base[(int)0], > &OP_RAVI_TOFLT_n_2_8) == (int)0; > if (comparison_0_12) goto OP_RAVI_TOFLT_if_conversion_failed_2_13; > else goto OP_RAVI_TOFLT_if_conversion_ok_2_14; > > OP_RAVI_TOFLT_if_conversion_ok_2_14: > (void)printf ("number ok = %f\ > ", OP_RAVI_TOFLT_n_2_8); > > > The printf output says that value of OP_RAVI_TOFLT_n_2_8 is 0.0. > Yet the called function luaV_tonumber_() set this to a different value: > > Output from luaV_tonumber_(): > > set *0x7ffe1bb8d298 to 5.600000 > > Output from JIT code above: > > number ok = 0.000000 > > From the dump it seems that the address of the local variable > OP_RAVI_TOFLT_n_2_8 is being passed to the function. And yet the value > of the variable is its original value which was 0.0. > > Any tips on what I should be looking for? Looking at src/lvm.c, I see that the signature of luaV_tonumber and that lua_Number can be various types, including "double". int luaV_tonumber_ (const TValue *obj, lua_Number *n) Does the type signature of luaV_tonumber as compiled by the main compiler agree with that supplied by gcc_jit_context_new_function? If one of them is e.g. expecting a float *, but the other is expecting a double *, then you might get the symptoms you're seeing. It might be worth running your code under gdb and putting a breakpoint on the jitted code; see: https://gcc.gnu.org/onlinedocs/jit/topics/locations.html#faking-it and set: gcc_jit_context_set_bool_option ( ctxt, GCC_JIT_BOOL_OPTION_DEBUGINFO, 1); You can then step through it, and through the call to luaV_tonumber_ to see exactly what's being written; you can go back up the callstack to see if/when the local is modified. If that doesn't highlight a cause, maybe you're running into a libgccjit bug. If so, can you generate a reproducer and post it here so I can poke at it please? Does it help if you introduce an intermediate to hold the result of the call to luaV_tonumber_ before comparing it against zero? It *shouldn't*, but maybe we have a libgccjit bug. Dave