Re: Correct byte compiler error/warning positions. The solution!

[Alan Mackenzie]

Hello, Andrea.

On Thu, Dec 02, 2021 at 20:35:50 +0000, Alan Mackenzie wrote:
> On Thu, Dec 02, 2021 at 16:31:55 +0000, Andrea Corallo wrote:
> > Alan Mackenzie <acm@muc.de> writes:

> > Hi Alan,

[ .... ]

> > The modifications needed are all and only going into comp.c.

> OK.

> > The function you have to extend is 'emit_EQ'.  You'll see we have an
> > emit_* function for each corresponding macro/inline function used, ex:
> > 'emit_XLI', 'emit_XCONS' etc...

> OK.

> > You'll have to define all the new one needed in order to use them use
> > them in the new 'emit_EQ'.

> Thanks.  I'm currently going through the tutorial at
> https://gcc.gnu.org/onlinedocs/jit/intro/tutorial....html, so it may be a
> day or two before I start asking you questions.  ;-)

For extending emit_EQ, I've got the following embryonic scheme:

1/- Import the C variable symbols_with_pos_enabled:

 gcc_jit_lvalue *syms_with_pos_enabled =
               gcc_jit_context_new_global
                 (comp.ctxt, NULL,
                  GCC_JIT_GLOBAL_IMPORTED,
                  gcc_jit_get_type (comp.ctxt, GCC_JIT_TYPE_BOOL),
                  "symbols_with_pos_enabled");

2/- Extend emit_EQ with lots of nested gcc_jit_context_new_comparison's
containing GCC_JIT_BINARY_OP_LOGICAL_OR/ANDs, something like this:

  emit_EQ (gcc_jit_rvalue *x, gcc_jit_rvalue *y)
  {
    emit_comment ("EQ");

    return gcc_jit_context_new_comparison (
             comp.ctxt,
             NULL,
             GIT_JIT_BINARY_OP_LOGICAL_OR (
               gcc_jit_context_new_comparison
                 (comp.ctxt,
                  NULL,
                  GCC_JIT_COMPARISON_EQ,
                  emit_XLI (x),
                  emit_XLI (y)),
               syms_with_pos_enabled
                 ....
                 ....
               ) ;
  }

2a/- I think I would need C macros called something like ELN_AND and
ELN_OR to make this half-way readable.

3/- Have several fragments of gcc_jit code which could be plugged into
the above, things representing BARE_SYMBOL_P (x), SYMBOL_WITH_POS_P (x),
and so on.

Can you let me know what you think of this approach, please?  That is,
before I put a lot of work into it.  Is it broadly a good way of doing
the job?

> I can see already I'll need an emit_BASE_EQ (a renaming of the current
> emit_EQ), and one or two others.

> Hopefully, we'll get this up and running in a few days, or a week or two
> at most.

I can't help noticing the lack of anything like SYMBOLP in comp.c.  Is
this just because nothing needs it?  Or is there some other method in
operation, like using the inline function in lisp.h somehow, for
example?

> > Best Regards

> >   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).