From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123683 invoked by alias); 30 Jun 2015 01:19:22 -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 123665 invoked by uid 89); 30 Jun 2015 01:19:21 -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=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham 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: <1435626696.13727.190.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: <1435612102.13727.173.camel@surprise> 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.27 X-SW-Source: 2015-q2/txt/msg00139.txt.bz2 On Mon, 2015-06-29 at 22:25 +0100, Dibyendu Majumdar wrote: > On 29 June 2015 at 22:08, David Malcolm wrote: > > > 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) > > > > I am using double as lua_Number. > > > 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. > > > > I checked this - I think they match. > > > 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? > > > > Attached is a reproducer. Thanks; I'm able to run the reproducer, at least to the point of being able to invoke gcc_jit_context_compile on it. Interestingly, looking at the gimple dump (via GCC_JIT_BOOL_OPTION_DUMP_INITIAL_GIMPLE), I see: OP_RAVI_TOFLT_n_2_8.0; OP_RAVI_TOFLT_n_2_8.1; [...snip...] OP_RAVI_TOFLT_n_2_8; [...snip...] OP_RAVI_TOFLT_if_not_float_2_10: OP_RAVI_TOFLT_n_2_8.0 = OP_RAVI_TOFLT_n_2_8; printf ("number %p = %f before call to luaV_number", &OP_RAVI_TOFLT_n_2_8.0, OP_RAVI_TOFLT_n_2_8); OP_RAVI_TOFLT_n_2_8.1 = OP_RAVI_TOFLT_n_2_8; [...snip...] OP_RAVI_TOFLT_n_2_8.1 = OP_RAVI_TOFLT_n_2_8; D.392 = 0; D.393 = base + D.392; D.405 = luaV_tonumber_ (D.393, &OP_RAVI_TOFLT_n_2_8.1); ^^^^^^^^^^^^^^ here's the call ^^^^^ comparison_0_12 = D.405 == 0; if (comparison_0_12 != 0) goto OP_RAVI_TOFLT_if_conversion_failed_2_13; else goto OP_RAVI_TOFLT_if_conversion_ok_2_14; OP_RAVI_TOFLT_done_2_11: D.390 = L->ci; base = D.390->u.l.base; D.399 = 16; D.400 = base + D.399; L->top = D.400; D.394 = cl->p; D.406 = D.394->sizep; comparison_0_15 = D.406 > 0; if (comparison_0_15 != 0) goto OP_RETURN_if_sizep_gt_0_3_16; else goto OP_RETURN_else_sizep_gt_0_3_17; OP_RAVI_TOFLT_if_conversion_failed_2_13: luaG_runerror (L, "number expected"); goto OP_RAVI_TOFLT_if_conversion_ok_2_14; OP_RAVI_TOFLT_if_conversion_ok_2_14: printf ("number ok = %f", OP_RAVI_TOFLT_n_2_8); [...snip...] which, if I'm reading it right, suggests that the local has effectively been split into three locals during the conversion to gimple, and that a ptr to OP_RAVI_TOFLT_n_2_8.1 is passed to luaV_tonumber_, but OP_RAVI_TOFLT_n_2_8 is then used. This is feeling like a bug at my end; sorry. I'll continue to investigate.