From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6475 invoked by alias); 26 Jun 2015 10:48: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 6453 invoked by uid 89); 26 Jun 2015 10:48:01 -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-f169.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=YK06JkdUZ1qNd/9AYY0t9ZC9m8m5kT7428A0nkBo6pg=; b=WgDKy2lxXbJlnjaRTNgiwxogrWRQeWheTZ835RP0XjdjVbLNZw4GKbns3wQ3HP5NHN S3l/+Cbkff+zbTesTy96ejYT5U+JFrk5QdoasukCB7LYfuUcHbkXbySQlpOcsffRaOGz ysIA7y3V7NxDa/f1A6uQwTPZ3vareh+8BuH7eiCeP3XJ4HgJg0ZEAVudbUrFFiIwPC6D 9wJRQrD4udUGh9XjYUmTn8nwkibn+VTyqSFUWUP6ml4gb7Qv3nrtE/GIKqXzwqW+gljI +eQdK2wYafqc7W7IdsKp1yB8NO3NkvS6AJiAlGOd2ozgQwzW9kb/8LPZcJ9+eUJ+VvFf amNg== X-Gm-Message-State: ALoCoQmA4/bf1kg/jH7ET0bxWykMOyglc6cOSFt0a3ZMAT06ik8eMbTtk7ZxTgbSzyk+vbzsK+U4 X-Received: by 10.13.212.147 with SMTP id w141mr1099014ywd.57.1435315676176; Fri, 26 Jun 2015 03:47:56 -0700 (PDT) MIME-Version: 1.0 From: Dibyendu Majumdar Date: Thu, 01 Jan 2015 00:00:00 -0000 Message-ID: <-5427343366145199664@unknownmsgid> Subject: RE: Compilation error involving comparison and logical operator 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/msg00115.txt.bz2 Hi Dave, Please look at file https://github.com/dibyendumajumdar/ravi/blob/master/src/ravi_gcccomp.c. Functions ravi_emit_boolean_testfalse() and ravi_emit_TEST(). RegardsFrom: David Malcolm Sent: =E2=80=8E26/=E2=80=8E06/=E2=80=8E2015 10:50 To: Dibyendu Majumdar Cc: jit@gcc.gnu.org Subject: Re: Compilation error involving comparison and logical operator On Fri, 2015-06-26 at 08:12 +0100, Dibyendu Majumdar wrote: > On 26 June 2015 at 00:57, David Malcolm wrote: > > Difficult to say without seeing the code (e.g. via > > gcc_jit_context_dump_reproducer_to_file). My guess is that the > > expression you've constructed is not what you think it is, and that > > that's what's causing the issue. > > > > Attached is the reproducer file. I tried adding casts but it still > fails. Will investigate more tonight. Thanks. Note that unlike C, libgccjit has no implicit type-coercion: anywhere you want to treat int as bool or vice versa, or convert between float and int, you need to do it explicitly via a cast (gcc_jit_context_new_cast). Sadly, "gcc_jit_context_dump_reproducer_to_file" didn't produce an actual *reproducer* for the issue. Bother. :( The problem is that gcc_jit_context_dump_reproducer_to_file only dumps API calls that succeeded, whereas API calls that fail get rejected without being recorded. Hence when I try to run the file, I get: libgccjit.so: error: unterminated block in ravif2: end_0_5 Presumably the API call you made to terminate it was rejected by the API with an error and was thus not being recorded, and thus didn't make it into the so-called "reproducer". Sorry about that. The API rejects calls that would lead to a crash later on, on the grounds that an error message at the point of the call is more user-friendly than an error message later on, or a segfault. I wonder if there's a way to update things to that it records rejected API calls in such a way that they can make it into reproducers, but without having them crash. In the meantime, that doesn't help with the issue you've run into. Can I see the code in question? I know you use github; would it be easiest if you commit-and-push to a temporary branch there? You can see the exact backtrace of where the error occurs by setting: (gdb) break gcc::jit::recording::context::add_error before running your code under the debugger. You can call fns from the debugger; in particular you can use gcc_jit_object_get_debug_string to examine things: Breakpoint 4, create_code (ctxt_0xf58f30=3D0x61d4e0, ctxt_0xfa4b40=3D0x61d640) at rdump.c:2477 (gdb) p lvalue__cl__p__k__int_0___value__i_0xf73590 $6 =3D (gcc_jit_lvalue *) 0x630270 (gdb) call gcc_jit_object_get_debug_string ($6) $7 =3D 0x630760 "(&cl->p->k[(int)0])->value_.i" and get types of rvalues: (gdb) call gcc_jit_object_get_debug_string (gcc_jit_rvalue_get_type($6)) $8 =3D 0x630380 "long long" I wonder if it would be helpful to have a designated breakpoint site for jit errors, so that users can do: (gdb) break on_gcc_jit_error or somesuch and then be able to get a backtrace etc exactly when errors are emitted. Or maybe this could be a boolean option; something like: /* For use when running under a debugger. If true, when an error occurs, signal that a breakpoint has been reached, so that e.g. a backtrace can be obtained. When not running under a debugger, the results are undefined, and likely to lead to the process terminating on errors. */ GCC_JIT_BOOL_OPTION_BREAK_ON_ERROR, or somesuch (the wording could probably be improved) [1]. Dave [1] note to self: I attempted something like this for CPython, see http://bugs.python.org/issue9635 for cross-platform implementation details.