RE: Compilation error involving comparison and logical operator

[Dibyendu Majumdar <mobile@majumdar.org.uk>]

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: ‎26/‎06/‎2015 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 <dmalcolm@redhat.com> 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=0x61d4e0,
ctxt_0xfa4b40=0x61d640) at rdump.c:2477

(gdb) p lvalue__cl__p__k__int_0___value__i_0xf73590
$6 = (gcc_jit_lvalue *) 0x630270
(gdb) call gcc_jit_object_get_debug_string ($6)
$7 = 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 = 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.