From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93331 invoked by alias); 30 Jun 2015 07:56:49 -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 93318 invoked by uid 89); 30 Jun 2015 07:56:48 -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.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW 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: mail-yk0-f170.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=83IPvgvOTLrK9cn51tNChFEN7dTMmuhOQPSg85KdmrQ=; b=XQUlMlbwpXrXWskQKRtgdfXb57hfWq+GthrHog/tLhy4RmGzEX+DR5WNebh1egl1Lh 7jyRl/K6B2D/ikP5bS9iAhduHYqsw96Uw+sQCQIaM3kYUPifRHTl8EmMktSbm3Xob2x9 jwDEwWKkZ5ph/ig8cJDQp95mJgQHWEKl5mnW+arOXMrNQhsoBBes9uQRrgGAOXuXELEC e9Tuqf2p4Q1hk6pAmTBbEQPMI/KePfF19elHLMD+JB9SDIaJiUgar1pwHlKDCXN1k73A +QIhvhfviGz7hDQl8epK4CrEZi9X4DCStiQyvoP371mGwowVmXYrLriRy8xoBKMlms9k n2cQ== X-Gm-Message-State: ALoCoQmuelrHDBigsWPHA1q0CvlQwVBn5HXQE4r9LaXph9565OfzM0gTrDriKndJH0Tx4NQSj8zu X-Received: by 10.170.91.133 with SMTP id i127mr23717679yka.83.1435651004206; Tue, 30 Jun 2015 00:56:44 -0700 (PDT) MIME-Version: 1.0 From: Dibyendu Majumdar Date: Thu, 01 Jan 2015 00:00:00 -0000 Message-ID: <555165081136725637@unknownmsgid> Subject: RE: Weird problem To: David Malcolm Cc: "jit@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-q2/txt/msg00144.txt.bz2 Thanks, will test tonight.From: David Malcolm Sent: =E2=80=8E30/=E2=80=8E06/=E2=80=8E2015 03:24 To: Dibyendu Majumdar Cc: jit@gcc.gnu.org Subject: Re: Weird problem 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 libg= ccjit > > > > 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 =3D OP_RAVI_TOFLT_n_2_8; > > printf ("number %p =3D %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 =3D OP_RAVI_TOFLT_n_2_8; > > [...snip...] > > OP_RAVI_TOFLT_n_2_8.1 =3D OP_RAVI_TOFLT_n_2_8; > > D.392 =3D 0; > > D.393 =3D base + D.392; > > D.405 =3D luaV_tonumber_ (D.393, &OP_RAVI_TOFLT_n_2_8.1); > > ^^^^^^^^^^^^^^ here's the call ^^^^^ > > comparison_0_12 =3D D.405 =3D=3D 0; > > if (comparison_0_12 !=3D 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 =3D L->ci; > > base =3D D.390->u.l.base; > > D.399 =3D 16; > > D.400 =3D base + D.399; > > L->top =3D D.400; > > D.394 =3D cl->p; > > D.406 =3D D.394->sizep; > > comparison_0_15 =3D D.406 > 0; > > if (comparison_0_15 !=3D 0) goto OP_RETURN_if_sizep_gt_0_3_16; else g= oto > > 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 =3D %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=3D66700. > > 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)