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 "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#45817: 28.0.50; Native fails Date: Thu, 14 Jan 2021 14:31:30 +0000 Message-ID: References: <8D26BD1C-F176-4F8F-9D95-3035DBD9FB0C@korins.ky> <968E34D7-5E68-4365-A742-735CD8379ACB@korins.ky> <83wnwgb3d9.fsf@gnu.org> <83sg73bomx.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="13376"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 45817@debbugs.gnu.org, kirill@korins.ky To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 14 15:32:31 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1l03fq-0003ND-Mm for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Jan 2021 15:32:30 +0100 Original-Received: from localhost ([::1]:49878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l03fp-0006yD-Ln for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Jan 2021 09:32:29 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38640) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l03fQ-0006wl-4a for bug-gnu-emacs@gnu.org; Thu, 14 Jan 2021 09:32:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54290) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l03fP-0004Cc-T3 for bug-gnu-emacs@gnu.org; Thu, 14 Jan 2021 09:32:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l03fP-0006rD-P1 for bug-gnu-emacs@gnu.org; Thu, 14 Jan 2021 09:32:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jan 2021 14:32:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45817 X-GNU-PR-Package: emacs Original-Received: via spool by 45817-submit@debbugs.gnu.org id=B45817.161063469825023 (code B ref 45817); Thu, 14 Jan 2021 14:32:03 +0000 Original-Received: (at 45817) by debbugs.gnu.org; 14 Jan 2021 14:31:38 +0000 Original-Received: from localhost ([127.0.0.1]:37601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l03ez-0006VD-Gc for submit@debbugs.gnu.org; Thu, 14 Jan 2021 09:31:38 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:55752) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l03ev-0006PI-RH for 45817@debbugs.gnu.org; Thu, 14 Jan 2021 09:31:34 -0500 Original-Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 10EEVUu8003850 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 Jan 2021 14:31:30 GMT In-Reply-To: <83sg73bomx.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Jan 2021 16:04:54 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:197950 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: "Kirill A. Korinsky" , 45817@debbugs.gnu.org >> Date: Thu, 14 Jan 2021 09:33:48 +0000 >> >> > Is this specific to macOS? >> > >> > In any case, if it's known that specific versions of GCC cause >> > problems on specific platforms, we should reject those versions (for >> > the libgccjit usage purposes) in configure, I think. >> >> We do, not based on the version but (even better I think) we run a >> functional test at configure time. The test use libgccjit to produce a >> shared, then this is loaded and used to ensure all the complete >> mechanism is functional. > > Yes, but such tests can only verify that the basics work, whereas the > OP seemed to indicate that it generally works, but fails in some > subtle situation. If libgccjit you are testing at configure time only > "mostly" works, you will be unable to detect that with simple tests. > For such subtly broken versions of libgccjit, we have no practical > means but looking at their version. I agree, but so far I've no information of a broken libgccjit version that we don't manage to work around. I'm talking about if compiled and installed from source code. Some distros showed to have issues with certain packaged versions, but those fails immediately with the configure test we have. If we find a libgccjit version we know we can't work with I agree we should reject the version. For this specific purpose I've introduced (in GCC10) an entry point in libgccjit that is returning the version. This is exposed to Lisp as `comp-libgccjit-version' so for GCC>=10 we can control this also dynamically and not only at configure time. Andrea