From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Native compiler - passing command line options to C compiler Date: Mon, 30 Aug 2021 12:59:45 +0000 Message-ID: References: <83bl5fkvky.fsf@gnu.org> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23460"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Arthur Miller , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 30 15:01:26 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 1mKgui-0005sq-Mv for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Aug 2021 15:01:24 +0200 Original-Received: from localhost ([::1]:59206 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mKguh-0001wS-Hm for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Aug 2021 09:01:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58736) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKgtE-000160-2K for emacs-devel@gnu.org; Mon, 30 Aug 2021 08:59:52 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:51491) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKgtB-0002ql-5b; Mon, 30 Aug 2021 08:59:51 -0400 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 17UCxjQN023086 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 30 Aug 2021 12:59:45 GMT In-Reply-To: <83bl5fkvky.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 30 Aug 2021 14:42:21 +0300") 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.23 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:273488 Archived-At: Eli Zaretskii writes: >> From: Arthur Miller >> Date: Sun, 29 Aug 2021 23:47:56 +0200 >> >> after the few mails the other day, I wasn't really sure if Andrea is going to >> implement it and when. I thought it was rather a tedious manual labour and maybe >> not so important, so I took me a liberty to implement this myself in my own, so >> called, personal copy of Eamcs sources. > > Thanks. > >> I am not sure if I have done it correctly though, I appreciate if Andrea have >> time to take a look; I have just mainly copied your code for backend options. It >> seems to work for me, with a minor remark: When I pass a valid option, "native", >> in place where it should go, I get an invalid option error. Gcc even lists it in >> the error message as a valid option. Another option "skylake" works just >> fine. This seems to vary between flags. I am not sure if this is some encoding >> error from Emacs to libgccjit, or if it is some bug in libgccjit, or is it just >> my brain having dumps. > > I guess -march=native is something handled by GCC itself, and here we > don't have it? If you want to be sure, ask this question on the GCC > list, or report as a bug to their Bugzilla. > >> +break your code. Use at own risk. > ^^ > Two spaces between sentences. > >> +DEFUN ("comp-native-compiler-options-effective-p", >> + Fcomp_native_compiler_options_effective_p, >> + Scomp_native_compiler_options_effective_p, >> + 0, 0, 0, >> + doc: /* Return t if `comp-native-compiler-options' is effective. */) >> + (void) >> +{ >> +#if defined (LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option) \ >> + || defined (WINDOWSNT) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> + if (gcc_jit_context_add_command_line_option) >> + return Qt; >> +#endif > > The emphasized part doesn't look right: we did that elsewhere because > the options we pass there work around bugs that happen also in > versions that don't report libgccjit version. But here this is not > needed, and the version check isn't present anyway. So the WINDOWSNT > special handling should be removed, I think. I think this "defined (WINDOWSNT)" should be there so that compiling on Windows the check over "gcc_jit_context_add_command_line_option" it is always compiled even in case the libgccjit.h provided at compile time does not define 'LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option'. A newer version of the shared library including the entry point might be provided later on and will be used at runtime. This should explain also the other mentioned points. Regards Andrea