public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
* Compilation error involving comparison and logical operator
@ 2015-01-01  0:00 Dibyendu Majumdar
  2015-01-01  0:00 ` David Malcolm
  0 siblings, 1 reply; 9+ messages in thread
From: Dibyendu Majumdar @ 2015-01-01  0:00 UTC (permalink / raw)
  To: jit

Hi Dave,

I am getting an error in an expression such as this:

int bvalue_0_2;
bvalue_0_2 = &base[(int)0]->tt_ == (int)1 && &base[(int)0]->value_.b == (int)0;

Of course the expression above really is:

bvalue_0_2 = ((&base[(int)0]->tt_ == (int)1) &&
(&base[(int)0]->value_.b == (int)0));

The error I get is this:

libgccjit.so: error: gcc_jit_block_add_assignment: mismatching types:
assignment to bvalue_0_2 (type: int) from &base[(int)0]->tt_ == (int)0
(type: bool)

I notice that the error message doesn't show the full expression above
- is this just an issue with the dump or is there a problem with the
expression evaluation?

Also, I am confused by the error as I am not sure if this means I need
to store the result of the expression in a bool value. In fact if I do
that then:

libgccjit.so: error: gcc_jit_block_add_assignment: mismatching types:
assignment to bvalue_0_2 (type: bool) from &base[(int)0]->tt_ ==
(int)1 && &base[(int)0]->value_.b == (int)0 (type: int)

Now the full expression is shown but the error is different.
I will send you dumps tomorrow for this but if you could let me know
what the rules are for assigning boolean values to variables that
would be great.

Thanks and Regards

Dibyendu

^ permalink raw reply	[flat|nested] 9+ messages in thread
* RE: Compilation error involving comparison and logical operator
@ 2015-01-01  0:00 Dibyendu Majumdar
  0 siblings, 0 replies; 9+ messages in thread
From: Dibyendu Majumdar @ 2015-01-01  0:00 UTC (permalink / raw)
  To: Dibyendu Majumdar, David Malcolm; +Cc: jit

Apologies the below isn't the the one I sent you the dump from, that
version isn't committed yet.From: Dibyendu Majumdar
Sent: ‎26/‎06/‎2015 11:47
To: David Malcolm
Cc: jit@gcc.gnu.org
Subject: RE: Compilation error involving comparison and logical operator
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.

^ permalink raw reply	[flat|nested] 9+ messages in thread
* RE: Compilation error involving comparison and logical operator
@ 2015-01-01  0:00 Dibyendu Majumdar
  0 siblings, 0 replies; 9+ messages in thread
From: Dibyendu Majumdar @ 2015-01-01  0:00 UTC (permalink / raw)
  To: David Malcolm; +Cc: jit

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-06-26 20:38 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-01  0:00 Compilation error involving comparison and logical operator Dibyendu Majumdar
2015-01-01  0:00 ` David Malcolm
2015-01-01  0:00   ` Dibyendu Majumdar
2015-01-01  0:00     ` David Malcolm
2015-01-01  0:00       ` Dibyendu Majumdar
2015-01-01  0:00         ` David Malcolm
2015-01-01  0:00           ` Dibyendu Majumdar
2015-01-01  0:00 Dibyendu Majumdar
2015-01-01  0:00 Dibyendu Majumdar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).