From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115412 invoked by alias); 30 Jun 2015 02:25:01 -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 115401 invoked by uid 89); 30 Jun 2015 02:25:00 -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: <1435630635.13727.195.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: <1435628280.13727.192.camel@surprise> References: <1435612102.13727.173.camel@surprise> <1435626696.13727.190.camel@surprise> <1435628280.13727.192.camel@surprise> Content-Type: multipart/mixed; boundary="=-xmUjdylOytlgHrVJ+iv0" Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-SW-Source: 2015-q2/txt/msg00142.txt.bz2 --=-xmUjdylOytlgHrVJ+iv0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Content-length: 3491 On Mon, 2015-06-29 at 21:38 -0400, David Malcolm wrote: > On Mon, 2015-06-29 at 21:11 -0400, David Malcolm wrote: > > 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. > > Definitely looks like a bug at my end. > > I've created a minimal reproducer, and filed it as > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66700. > > I plan to investigate further tomorrow. > > Sorry about this. Does the attached patch fix it for you? (it's currently a bit of a hack; hope to get it more robust tomorrow) --=-xmUjdylOytlgHrVJ+iv0 Content-Disposition: attachment; filename="set-TREE_ADDRESSABLE.patch" Content-Type: text/x-patch; name="set-TREE_ADDRESSABLE.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit Content-length: 402 diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c index 395a776..5ffc16f 100644 --- a/gcc/jit/jit-playback.c +++ b/gcc/jit/jit-playback.c @@ -1179,6 +1179,7 @@ get_address (location *loc) tree ptr = build1 (ADDR_EXPR, t_ptrtype, t_lvalue); if (loc) get_context ()->set_tree_location (ptr, loc); + TREE_ADDRESSABLE (t_lvalue) = 1; return new rvalue (get_context (), ptr); } --=-xmUjdylOytlgHrVJ+iv0--