From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Correct byte compiler error/warning positions. The solution! Date: Sat, 04 Dec 2021 19:22:02 +0000 Message-ID: References: <8335nfw2pe.fsf@gnu.org> <838rx4s224.fsf@gnu.org> <834k7ss172.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30275"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 04 20:23:03 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mtacg-0007jN-Cf for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Dec 2021 20:23:02 +0100 Original-Received: from localhost ([::1]:49434 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mtace-0005YS-Hm for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Dec 2021 14:23:00 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43472) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtabt-0004ro-7x for emacs-devel@gnu.org; Sat, 04 Dec 2021 14:22:13 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:60134) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtabq-0001FT-Iv; Sat, 04 Dec 2021 14:22:12 -0500 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 1B4JM2PP005466 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 4 Dec 2021 19:22:03 GMT In-Reply-To: (Alan Mackenzie's message of "Fri, 3 Dec 2021 21:05:10 +0000") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:280935 Archived-At: Alan Mackenzie writes: > 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 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. ;-) Hi Alan, > 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"); Yep something like. PS We already have 'comp.bool_type' to use. > 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 think it could be a good idea but I believe there's no need to use macros here, we could have just functions return rvalues no? I'm not a big fan of C macros and I try not to use them whem possible. >> 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? Correct. > Or is there some other method in > operation, like using the inline function in lisp.h somehow, for > example? Nope. Tip, while developing I suggest you to dump the pseudo C code generated using `native-comp-debug' > 1 to verify it looks the way it is expected. Best Regards Andrea