From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode Date: Sat, 27 Feb 2021 05:06:43 +0000 Message-ID: References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26012"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46670@debbugs.gnu.org, mauricio@collares.org, Andrea Corallo To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 27 06:08:10 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 1lFrpq-0006gW-Br for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Feb 2021 06:08:10 +0100 Original-Received: from localhost ([::1]:40546 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFrpp-0003S7-FH for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Feb 2021 00:08:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43066) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lFrpi-0003Rv-Jg for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 00:08:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59727) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lFrpi-0007p9-Ci for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 00:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lFrpi-0000et-84 for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 00:08:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Feb 2021 05:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46670 X-GNU-PR-Package: emacs Original-Received: via spool by 46670-submit@debbugs.gnu.org id=B46670.16144024622497 (code B ref 46670); Sat, 27 Feb 2021 05:08:02 +0000 Original-Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 05:07:42 +0000 Original-Received: from localhost ([127.0.0.1]:43040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFrp9-0000dx-OG for submit@debbugs.gnu.org; Sat, 27 Feb 2021 00:07:42 -0500 Original-Received: from mail-oi1-f174.google.com ([209.85.167.174]:37743) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFrp7-0000dk-WE for 46670@debbugs.gnu.org; Sat, 27 Feb 2021 00:07:26 -0500 Original-Received: by mail-oi1-f174.google.com with SMTP id l133so12091860oib.4 for <46670@debbugs.gnu.org>; Fri, 26 Feb 2021 21:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p5C7XJ6mrx73/sP9d/TDbvyz15sQH+1Xe03Fbv1rG0o=; b=L3Ijvb5PblZinip3KqHrv42r88rvw/FW+qg+O0i4vqMB7GnEdRHEAa/6KLFg8+u++a c0/eXLcxnwiwjbaeUuf1dsOsGKR+tAR31e9P7z60dCwvUS0gJkKVjSdRyLLfsyrQeMOb kSca3zlPK2xTELWvexpHUsX5qfw6OaTvFiNJnx7BVw7HS+JEMA+NE0IuzCI8nmqB7F87 Xdt3AHZHmUqI7W17FaWNHDoepSeG6ZbKWAoZVhqtr1XjsBniUljR39hwvdDtfgFhmdwl kQO192vT4akibtptaPMV74zzjhED+C0qvqc8KMR8M8tW+voQiIqkwH9RdPttnJlmSP3C 1oBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p5C7XJ6mrx73/sP9d/TDbvyz15sQH+1Xe03Fbv1rG0o=; b=NIAYqML/NZODPqUYs6U7GFwyx5TDya8uC954NAd79U9AsE++fmLVKIcrdUkbQ5Mvru B22nNL015FE1+yU+b1XsbsWuRgZR+FS/a46OLzYgr7czpW7T/05Wxp4qDZnjHraMkh88 dACcmrFDbeDcsTdTdRNxFAzGQILeWg4xh3fkT+iFuWEC6HV94arN7pFw9ydGDNOCn7Ir 5uEfkk9NOoSiaL/H2qDsaO9yf4mwhjDQydOpdyRkR3dpygnl9I4G/AJI8kGix5PtoXIR jwLRvVyVLYCuypb5iN8ieQzAyTm6af3UMZW3UkZ1AFhMS4vfVgj+DdG1OWEhj62znDJ8 kZVQ== X-Gm-Message-State: AOAM532Y+BlbX8H/U/3TgwRJNQAi2pyZVze5ujVhu29WuhYWT87+CtnB zQC1U/q5Glafihg2TyCy2ENi0l2Pgo4Sbx+E/+0= X-Google-Smtp-Source: ABdhPJw4a+KvmD6UxV066KoN4HavhUZtCdk58FVDuqU9oymp93A4F54V8QVDXdVKo7vXERGoMkKAFhevJZVTTqfifUA= X-Received: by 2002:aca:6141:: with SMTP id v62mr4420507oib.30.1614402440425; Fri, 26 Feb 2021 21:07:20 -0800 (PST) In-Reply-To: <83mtvqpp15.fsf@gnu.org> 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:200913 Archived-At: On Fri, Feb 26, 2021 at 8:12 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Thu, 25 Feb 2021 20:59:41 +0000 > > Cc: 46670@debbugs.gnu.org, Mauricio Collares > > > > > On this subject I highly recommend the following, let's adopt what we > > > essentially do for GCC development: > > > > You might want to suggest that on emacs-devel, as it would be a very > > drastic change. > > AFAICT, the principles proposed by Andrea are just common sense, and > definitely not a drastic change from our existing practices. Let me try to explain a situation in which I don't think they work very well, and which may or may not be similar to the situation we're actually in: 1. We're emitting strange "assume" insns. 2. These are pseudo-insns which are not rendered into functional code. 3. We do not have a facility for converting these "assume" insns into functional code which asserts they hold at runtime. 4. We have test cases which ensure the "assume" insns are actually generated as they currently are. How, assuming for the moment that the "strange" in (1) actually means "buggy", are we supposed to fix this? A patch changing (1) will be rejected as invalid because there is no reproducer. It will also be rejected as broken because the test cases will fail. A patch changing (2) (e.g. a new compiler feature which makes use of the assumes) will be rejected as broken because it will generate incorrect code. A patch changing (3) will be rejected because the new assertions will initially fail, because of (1). A patch changing (4) will be rejected because it would mean dropping tests which appear to work. A patch changing (1), (3), and (4) at the same time will be rejected because it wouldn't be incremental. I think, but am willing to be convinced I'm wrong, that this is the situation we're in. I can prepare patches changing any combination of (1), (2), (3), and (4). Pip