From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 01 08:07:13 2021 Received: (at submit) by debbugs.gnu.org; 1 Mar 2021 13:07:13 +0000 Received: from localhost ([127.0.0.1]:48451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGiGX-0007J2-Cc for submit@debbugs.gnu.org; Mon, 01 Mar 2021 08:07:13 -0500 Received: from lists.gnu.org ([209.51.188.17]:44456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGiGW-0007Iv-8P for submit@debbugs.gnu.org; Mon, 01 Mar 2021 08:07:12 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50964) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lGiGW-0008Ez-3L for bug-gnu-emacs@gnu.org; Mon, 01 Mar 2021 08:07:12 -0500 Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]:33741) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lGiGU-0005rF-Fs for bug-gnu-emacs@gnu.org; Mon, 01 Mar 2021 08:07:11 -0500 Received: by mail-ot1-x32a.google.com with SMTP id 40so7973482otu.0 for ; Mon, 01 Mar 2021 05:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/3yMdq7YDKbEPgRymuQifvjpO6lt/7a6fpavKIMk51A=; b=kPQX+wVtorODPSr2bhMYa1sIfXGyCLqK/TO7cIFtDqatoAEU8SfwMvy94zAvQoH/1o sls6lKFraAiRBSlx5ueZ0+/Hj3cBlLYj2P3QWT+ratQ4gE1lP6Q3He1LYbh9h6m1k+Uu u0do9DVtXeCnzPh4au0jSjJ37UHEYTEu0XQpnyOYJCECXIW+MM1D6YmLOv3F89/wxOkh 8O6D45FIRdGbmEgnYyZ2XFcxQZviHHPn6CMhn1jyfr7T+mWRSwUPTbwKl0GuDR8CNR+3 HYGfjselOUwI+asJReGURh4Bbw4gJ7KWPkZPpLVH1MMKUjvNYOIdOd5Mb6Sbh7bhAEgK Hf+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/3yMdq7YDKbEPgRymuQifvjpO6lt/7a6fpavKIMk51A=; b=XZhMVRkRCxhY9SO4yBGY90djSvTEeRSJe8UcltcSVYgYD3yHg4Z5WW2kh4b5cDMiXM ycuRV+79ZBcIEr62hgtV6ojXweOa3fIFiB18JFvl6kVvtnTdoQilwN/17LttOG7PVq5G H8hxgTLJTxcLtplW2RbWn4Zx1/1CqyCprHVRRKfjWQMisyMHux3y9wd98J8Q82xuUNt1 qQvNrrwVfwFWFRlr7eASvbk/YFA2a09RpkCqXLzD3wBxVh51XP256+7pcXN7JyXSQTFv GihjPKMs18B0PiuQytrERE82d2a2j3V0fI0mC+51z0zSyGXzw/EWeX4zlKkxbvL0fS7s 1LIA== X-Gm-Message-State: AOAM532NqSeMGnWKe0Mwx+WSu0sqVMjZBPBNcMl7hmBzTwfBYSOymygO FCjcnurEEoyhwSkv5tfzW7CSro9ScPGscVsP/J4BQscYwukCXg== X-Google-Smtp-Source: ABdhPJzZDrF7JNGanVsvvUcBqvACbS1qt2XIQNjZ9B/SX8WZX/raNRY5WkFE5IqByDq75viQEtBl2oNyScO/9hmxW6w= X-Received: by 2002:a05:6830:1682:: with SMTP id k2mr13489910otr.154.1614604027918; Mon, 01 Mar 2021 05:07:07 -0800 (PST) MIME-Version: 1.0 From: Pip Cet Date: Mon, 1 Mar 2021 13:06:31 +0000 Message-ID: Subject: 28.0.50; [native-comp] assume pseudo-insns should be verified To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::32a; envelope-from=pipcet@gmail.com; helo=mail-ot1-x32a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is a wishlist item for the native-comp branch, though I consider the feature in question to be so essential that its absence also qualifies as a bug. The native-comp branch is emitting assume pseudo-insns. Those come in various forms, but their interpretation is clear: they express conditions which are meant to hold at runtime, and which the compiler may use to optimize code. I would like to add an optional compiler pass which asserts that the conditions are actually true at runtime. This is a basic safeguard that any assume() mechanism should have, and it's perfectly equivalent to the way eassume() becomes eassert() in debug builds of Emacs. Unfortunately, it turns out that while adding the compiler pass is easy, there are many failures because the assume pseudo-insns emitted at present are inconsistent or plain wrong. Some of these wrong assumes result in reproducible Lisp-to-native-code bugs today; others will not; for still others, we're not sure. For example, the four following bugs became a problem only because of a lack of this safeguard: bug#46843 (both bugs), bug#46812, bug#46670. Merging native-comp without such a safeguard would, I am convinced, introduce preventable, tricky, unnecessary bugs into the Emacs master branch. We shouldn't do that. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 01 15:12:20 2021 Received: (at 46847) by debbugs.gnu.org; 1 Mar 2021 20:12:20 +0000 Received: from localhost ([127.0.0.1]:50951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGotv-0003Wa-Vu for submit@debbugs.gnu.org; Mon, 01 Mar 2021 15:12:20 -0500 Received: from mx.sdf.org ([205.166.94.24]:62819) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGots-0003WR-Lz for 46847@debbugs.gnu.org; Mon, 01 Mar 2021 15:12:18 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 121KCFOh017247 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 1 Mar 2021 20:12:15 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be verified References: Date: Mon, 01 Mar 2021 20:12:15 +0000 In-Reply-To: (Pip Cet's message of "Mon, 1 Mar 2021 13:06:31 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46847 Cc: 46847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > This is a wishlist item for the native-comp branch, though I consider > the feature in question to be so essential that its absence also > qualifies as a bug. > > The native-comp branch is emitting assume pseudo-insns. Those come in > various forms, but their interpretation is clear: they express > conditions which are meant to hold at runtime, and which the compiler > may use to optimize code. > > I would like to add an optional compiler pass which asserts that the > conditions are actually true at runtime. This is a basic safeguard > that any assume() mechanism should have, and it's perfectly equivalent > to the way eassume() becomes eassert() in debug builds of Emacs. > > Unfortunately, it turns out that while adding the compiler pass is > easy, there are many failures because the assume pseudo-insns emitted > at present are inconsistent or plain wrong. Some of these wrong > assumes result in reproducible Lisp-to-native-code bugs today; others > will not; for still others, we're not sure. I think the issue might be that how assumes works has been miss-understood here. Assumes are working after SSA rename in the world of mvar ids, in contrast we render code based on slot numbers. Rendering assertions based on assumes using the slot numbers (IIUC that's what your patch did) certainly leads to inconsistencies, but that's a fundamental miss-interpretation of how assumes are working. This is probably also why you often suggests assumes are inconsistent. Anyway, for the reasons above rendering 1:1 assumes into run-time checks is not easily possible. OTOH a possible way, and that's what I want to do, would be to verify just before each (non pseudo) insn actually rendered that the slots in use there are consistent with the prediction. One could even control that with a parameter and have a mode where we just inject asserts on return insns not to bloat excessively the code. Note: I'm not aware of any compiler emitting run-time checks to verify its compile time predictions by why not. I'll take this task as sounds like good verification/development cost trade-off to me. Will follow-up on this! Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 02 01:58:31 2021 Received: (at 46847) by debbugs.gnu.org; 2 Mar 2021 06:58:31 +0000 Received: from localhost ([127.0.0.1]:51509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGyzG-0006zg-RP for submit@debbugs.gnu.org; Tue, 02 Mar 2021 01:58:31 -0500 Received: from mail-ot1-f49.google.com ([209.85.210.49]:35012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGyzB-0006zN-6q for 46847@debbugs.gnu.org; Tue, 02 Mar 2021 01:58:29 -0500 Received: by mail-ot1-f49.google.com with SMTP id r19so19083933otk.2 for <46847@debbugs.gnu.org>; Mon, 01 Mar 2021 22:58:25 -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=Dnj89hy0an6V7Jp+wLTUcNQB7/8wCp+g1c1tQcAIoTA=; b=Z2RBaUk+b3rafIjzZYiU56oaK6ApDNRt81hPIQc6isKReDltobKXoTl9ugmzmp6CbX RUU0tUPB2QWKouqbroqo9T3ZR/UW9ka6dyNoKe/ALzj1yGaD9/cM007ehpIHpzYDt23A sLS2GjYV7Vvv/L3UhXu+0m/qDFM9A1V/Lo65qo0GW4EY+mCf2xXE+9sv7Z5ePeDyC/C7 IhYsSYwer3uEIZaHXG/xKxOjwpgXRUTzg3FnIjdRhc1stR51ZcmiTTVgOPclQYoDV+hh S/zuaJwhczpSO4y4qwdfFsVvHEY+gKW4RVL/Rwh5X6zpW2lbbZRQaFPN5YhHJiYacFeF 5t3g== 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=Dnj89hy0an6V7Jp+wLTUcNQB7/8wCp+g1c1tQcAIoTA=; b=nKKpX3Rbe9LB3xTILESZ6e81xTS/hg0t4qSe4104ckHHxl+WzkAN4ebeB7nTMnS2tX olj7sR5Qd+R3AuRryDYwrvhzKVWL4XaP18nzWDOGF8UTE/5+Qjn+eLSE6hhLQRJkiO4r DCRtVbAp8eEnCtDyZIsPE/JPQKzSDYIWCveVzmjRU2HLkivgQaRiQwEMuMntOIn2eWk2 JzcqEyrnTBBBaWrTbUa2IKt1EfI/mIQSFlxNyq/4ERq9Ay1VRS4VzYG4YoWltvHXtnOV dkaa2JniZPPXUKyUc6Ea5+XvR6+LN+DQUlmp2v9llL9BmA+jGZbqQnH5IN8dOnA4gAM9 XB8A== X-Gm-Message-State: AOAM531UtCnCO0RciQXupDRp7nNNHceq74FN6cWgv+uRE+p7bBpa0p26 Jgi3m8ngFG2oW4DPfVuLo5YGxlnSWls0vnraAemLuzDviaP3TQ== X-Google-Smtp-Source: ABdhPJxefPQMLycG19HhEzkFuRb5+31ezMBuqwxfkJIRwIG1AamK6pjmImLdUi4mt2Sdai6PGfq6gsRBYciKVr4toKw= X-Received: by 2002:a05:6830:1682:: with SMTP id k2mr16922857otr.154.1614668299293; Mon, 01 Mar 2021 22:58:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pip Cet Date: Tue, 2 Mar 2021 06:57:42 +0000 Message-ID: Subject: Re: bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be verified To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46847 Cc: 46847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Mar 1, 2021 at 8:12 PM Andrea Corallo wrote: > Pip Cet writes: > > This is a wishlist item for the native-comp branch, though I consider > > the feature in question to be so essential that its absence also > > qualifies as a bug. > > > > The native-comp branch is emitting assume pseudo-insns. Those come in > > various forms, but their interpretation is clear: they express > > conditions which are meant to hold at runtime, and which the compiler > > may use to optimize code. > > > > I would like to add an optional compiler pass which asserts that the > > conditions are actually true at runtime. This is a basic safeguard > > that any assume() mechanism should have, and it's perfectly equivalent > > to the way eassume() becomes eassert() in debug builds of Emacs. > > > > Unfortunately, it turns out that while adding the compiler pass is > > easy, there are many failures because the assume pseudo-insns emitted > > at present are inconsistent or plain wrong. Some of these wrong > > assumes result in reproducible Lisp-to-native-code bugs today; others > > will not; for still others, we're not sure. > > I think the issue might be that how assumes works has been > miss-understood here. > Assumes are working after SSA rename in the world of mvar ids, in > contrast we render code based on slot numbers. If mvars introduced in assumes don't have valid slot numbers, they shouldn't have a valid slot number in the :slot slot. But in the case of the assumes emitted so far, they do have valid slot numbers, they're just not the ones that are used. > Rendering assertions > based on assumes using the slot numbers (IIUC that's what your patch > did) I merely converted the assumes into assertions. I did not use the slot numbers there. > certainly leads to inconsistencies, but that's a fundamental > miss-interpretation of how assumes are working. If there is a consistent slot number to assign to an assume-d variable, we should use it. If there isn't, we shouldn't use a slot number at all. What we do right now is to simply use a slot number that we know to be incorrect, even though a correct one is available. Again, what we emit is (assume (mvar X :slot 1) (not (mvar Y :slot 1))) (assume (mvar Z :slot 2) (and ... (mvar X :slot 1))) what we should emit is (assume (mvar X :slot 2) (not (mvar Y :slot 1))) (assume (mvar Z :slot 2) (and ... (mvar X :slot 2))) or even (assume (mvar X :slot -1) (not (mvar Y :slot 1))) (assume (mvar Z :slot 2) (and ... (mvar X :slot -1))) or whatever mechanism you're proposing to name mvars which do not refer to variables (respectfully, but that's what a metavariable is defined to be). > This is probably also why you often suggests assumes are inconsistent. No, the seven bugs we ran into so far which were caused by inconsistent assumes are why I often suggest assumes are inconsistent. > Anyway, for the reasons above rendering 1:1 assumes into run-time checks > is not easily possible. Then we should call them something else, because that's what an "assume" is. > OTOH a possible way, and that's what I want to do, would be to verify > just before each (non pseudo) insn actually rendered that the slots in > use there are consistent with the prediction. That would catch fewer bugs, and it would catch them much later, when code which uses them has been written. > One could even control that with a parameter and have a mode where we > just inject asserts on return insns not to bloat excessively the code. That seems like an entirely arbitrary place to check our assumes, to me. > Note: I'm not aware of any compiler emitting run-time checks to verify > its compile time predictions by why not. I don't know why you're unaware Emacs (pre-native-comp) and GCC both do that, but they do. Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 05 06:16:26 2021 Received: (at 46847) by debbugs.gnu.org; 5 Mar 2021 11:16:26 +0000 Received: from localhost ([127.0.0.1]:32999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lI8RV-0003Z0-0s for submit@debbugs.gnu.org; Fri, 05 Mar 2021 06:16:26 -0500 Received: from mx.sdf.org ([205.166.94.24]:55477) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lI8RS-0003Yq-Jw for 46847@debbugs.gnu.org; Fri, 05 Mar 2021 06:16:23 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 125BGKkq022084 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 5 Mar 2021 11:16:20 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be verified References: Date: Fri, 05 Mar 2021 11:16:19 +0000 In-Reply-To: (Pip Cet's message of "Tue, 2 Mar 2021 06:57:42 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46847 Cc: 46847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: [...] > (assume (mvar X :slot -1) (not (mvar Y :slot 1))) > (assume (mvar Z :slot 2) (and ... (mvar X :slot -1))) Now that we can generate temporaries this might be an option. But I think would be helpful if you could show what exactly are the 1:1 assertions you'd like to synthesize for the above assumes, otherwise this discussion will stay just too high level. [...] >> Note: I'm not aware of any compiler emitting run-time checks to verify >> its compile time predictions by why not. > > I don't know why you're unaware Emacs (pre-native-comp) and GCC both > do that, but they do. I wasn't even aware that the byte compiler is doing any value prediction and that is emitting code for to verify these, could give pointers to boths cases? Andrea From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 05 11:10:15 2021 Received: (at 46847) by debbugs.gnu.org; 5 Mar 2021 16:10:15 +0000 Received: from localhost ([127.0.0.1]:35235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lID1q-0005EX-RI for submit@debbugs.gnu.org; Fri, 05 Mar 2021 11:10:15 -0500 Received: from mail-ot1-f45.google.com ([209.85.210.45]:36589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lID1l-0005E6-6i for 46847@debbugs.gnu.org; Fri, 05 Mar 2021 11:10:09 -0500 Received: by mail-ot1-f45.google.com with SMTP id t16so2286396ott.3 for <46847@debbugs.gnu.org>; Fri, 05 Mar 2021 08:10:09 -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; bh=VN7s3cnIH+cxWFiCH0VayCulyCxglHPtZDxD6gHTsVo=; b=Wd9OdD6D+BC3MkA2rIxjl7xp4ncOLalRDDPhBXqHNocZ8T+iP5ZUGz7cN0XwY0eWpB VzWdMyPILQfJGSoS20+eY3ZCNSYQREQfTr5LCUy0A2gxtV5wvGOtYg1b8Ld8sy79sbja QeHmp6JwrUHyPGiqEs2ECj3AN3EkLA8YSENuctjS8TnBEnQjUKq2vpH+yTgtRzwZ/Xbg QElNfeN5ngTQi6/7q0wC9DqGqhWiMKfy3IPmHLXRYKR0xfHS9Abd36xwY7Mj76soYfMj pUmi6L14gXMGszXG7bRrfLrNKxLHqQY70GA6HB9VyCeTvNtFZD1UdnuPiTz118wTc5up QJ2Q== 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; bh=VN7s3cnIH+cxWFiCH0VayCulyCxglHPtZDxD6gHTsVo=; b=HHW8V8/N9szRIrmX5lV9bRg1gTJJdZCP9ibB1yt2XsrIJpyAcIKSJPvxsfY8kkkUyj Rgzjy/aZF0M3XgHv7p6du+2slnvBG4Q4eyfUz1ZHK98ppwv0ryGUXw5nyS/bBe2DzJSN w8tdIHaARCVnpRkjwn/aahoGuZPZnkI8aJaJJHTXOn8/gjwvduGwvjEsdGIshaAtuMho kIZsJbGY77T8UcA81a/+arEjMrKiVkjM0uj+gnn6tKhRaBqRBrG5OodKcpyr+0Em6KnO HT1tG0u3bTpevwjrm1+TsY+tG2V4MkWq8r+KgMqz2ManNu8EuxVedBmAyUAKvuwOGp40 MXdg== X-Gm-Message-State: AOAM532SRPVtcj1GzuS6ibAKFGnpVAOQ/k2pPpgy5z3QH0DAtjJnw2k8 UyCHa0bHsVO4l3QGgdSr2MBYWdCEXfdjiBtLbv/o5t3nzr3LYA== X-Google-Smtp-Source: ABdhPJyDXK6mPx5k/DQnQBmj7Kkku+tmlBje08vClj1V8F+blvhFZuGj2RmErygMQv6iA/8nD8Ofz8Fu1rFpu8KyffY= X-Received: by 2002:a05:6830:11d4:: with SMTP id v20mr8501012otq.287.1614960603641; Fri, 05 Mar 2021 08:10:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pip Cet Date: Fri, 5 Mar 2021 16:09:20 +0000 Message-ID: Subject: Re: bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be verified To: 46847@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46847 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Mar 1, 2021 at 1:08 PM Pip Cet wrote: > I would like to add an optional compiler pass which asserts that the > conditions are actually true at runtime. This is a basic safeguard > that any assume() mechanism should have, and it's perfectly equivalent > to the way eassume() becomes eassert() in debug builds of Emacs. I've proceeded to change things so I can assert assumes, and here's an incomplete list of the bugs I've found so far: Function types: 1. append has type (function (&rest t) t), not (function (&rest list) list) 2. aref has type (function (t fixnum) t), not (function (array fixnum) t) 3. bool-vector-count-consecutive has type (function (bool-vector boolean integer) fixnum), not (function (bool-vector bool-vector integer) fixnum)) 4. at least some of the frame-* functions accept nil parameters 5. intern-soft has type (function ((or string symbol) &optional vector) symbol), not (function (string &optional vector) symbol) 6. length has type (function (t) integer), not (function (sequence) integer) 7. at least some of the minibuffer functions can return nil as well as a window. 8. nthcdr has type (function (integer t) t), not (function (integer list) list) 9. radians-to-degrees is a macro and probably shouldn't have a function type 10. string has type (function (&rest fixnum) string), not (function (&rest fixnum) strng) 11. user-full-name has type (function (&optional integer) (or string null)), not (function (&optional integer) string) Predicate types: 1. functionp isn't equivalent to (or function symbol) Other: 1. comp-lambda-list-gen has to allow optional arguments to be nil even if explicitly specified. Furthermore, I've already reported some other bugs. So I think this is worth pursuing further. Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 05 14:37:00 2021 Received: (at 46847) by debbugs.gnu.org; 5 Mar 2021 19:37:00 +0000 Received: from localhost ([127.0.0.1]:35486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIGFv-0002Ix-RH for submit@debbugs.gnu.org; Fri, 05 Mar 2021 14:37:00 -0500 Received: from mx.sdf.org ([205.166.94.24]:61587) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIGFu-0002Ip-Py for 46847@debbugs.gnu.org; Fri, 05 Mar 2021 14:36:59 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 125JavAm020786 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 5 Mar 2021 19:36:58 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be verified References: Date: Fri, 05 Mar 2021 19:36:57 +0000 In-Reply-To: (Pip Cet's message of "Fri, 5 Mar 2021 16:09:20 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46847 Cc: 46847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Mon, Mar 1, 2021 at 1:08 PM Pip Cet wrote: >> I would like to add an optional compiler pass which asserts that the >> conditions are actually true at runtime. This is a basic safeguard >> that any assume() mechanism should have, and it's perfectly equivalent >> to the way eassume() becomes eassert() in debug builds of Emacs. > > I've proceeded to change things so I can assert assumes, and here's an > incomplete list of the bugs I've found so far: > > Function types: > 1. append has type (function (&rest t) t), not (function (&rest list) list) > 2. aref has type (function (t fixnum) t), not (function (array fixnum) t) > 3. bool-vector-count-consecutive has type (function (bool-vector > boolean integer) fixnum), not (function (bool-vector bool-vector > integer) fixnum)) > 4. at least some of the frame-* functions accept nil parameters > 5. intern-soft has type (function ((or string symbol) &optional > vector) symbol), not (function (string &optional vector) symbol) > 6. length has type (function (t) integer), not (function (sequence) integer) > 7. at least some of the minibuffer functions can return nil as well as a window. > 8. nthcdr has type (function (integer t) t), not (function (integer list) list) > 9. radians-to-degrees is a macro and probably shouldn't have a function type > 10. string has type (function (&rest fixnum) string), not (function > (&rest fixnum) strng) > 11. user-full-name has type (function (&optional integer) (or string > null)), not (function (&optional integer) string) > Predicate types: > 1. functionp isn't equivalent to (or function symbol) Thanks, patches are welcome. Andrea From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 14 17:07:51 2021 Received: (at 46847) by debbugs.gnu.org; 14 Mar 2021 21:07:52 +0000 Received: from localhost ([127.0.0.1]:34305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLXxn-0002Fz-KT for submit@debbugs.gnu.org; Sun, 14 Mar 2021 17:07:51 -0400 Received: from mx.sdf.org ([205.166.94.24]:51648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLXxl-0002Fo-H5 for 46847@debbugs.gnu.org; Sun, 14 Mar 2021 17:07:50 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12EL7lhr011546 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sun, 14 Mar 2021 21:07:47 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be verified References: Date: Sun, 14 Mar 2021 21:07:47 +0000 In-Reply-To: (Pip Cet's message of "Fri, 5 Mar 2021 16:09:20 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46847 Cc: 46847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: [...] > Function types: > 1. append has type (function (&rest t) t), not (function (&rest list) list) > 2. aref has type (function (t fixnum) t), not (function (array fixnum) t) > 3. bool-vector-count-consecutive has type (function (bool-vector > boolean integer) fixnum), not (function (bool-vector bool-vector > integer) fixnum)) > 4. at least some of the frame-* functions accept nil parameters > 5. intern-soft has type (function ((or string symbol) &optional > vector) symbol), not (function (string &optional vector) symbol) > 6. length has type (function (t) integer), not (function (sequence) integer) > 7. at least some of the minibuffer functions can return nil as well as a window. > 8. nthcdr has type (function (integer t) t), not (function (integer > list) list) > 9. radians-to-degrees is a macro and probably shouldn't have a function type > 10. string has type (function (&rest fixnum) string), not (function > (&rest fixnum) strng) > 11. user-full-name has type (function (&optional integer) (or string > null)), not (function (&optional integer) string) I've fixed most of these, please given you have already investigated this issue be more precise on points 4 and 7. > Predicate types: > 1. functionp isn't equivalent to (or function symbol) Would you suggest what's the right type specifier or the counter example that violated this so we can fix it? > Other: > 1. comp-lambda-list-gen has to allow optional arguments to be nil even > if explicitly specified. Not sure I understand, please be more precise in describing the issue so we can fix it. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 20 05:33:09 2024 Received: (at 46847-done) by debbugs.gnu.org; 20 Mar 2024 09:33:09 +0000 Received: from localhost ([127.0.0.1]:60750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmsJo-0003hs-QM for submit@debbugs.gnu.org; Wed, 20 Mar 2024 05:33:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33232) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmsJm-0003hF-UT for 46847-done@debbugs.gnu.org; Wed, 20 Mar 2024 05:33:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rmsGw-0002Qv-Gz; Wed, 20 Mar 2024 05:30:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=2GO/ruUJ21m1Lxo2kfbJ0mJ9ZDFytKs06ktkHDi6p+A=; b=jRNX5A9kix0JleGMd6zj Ar1Qd3UYRLeYZKhwFvZ1yjR1psznPfH4ijZj9X53TygtUqkO8eZU7dXq7EeQf395FHbzYBxbEEw++ I8919cGlYYkCNiKRS1H/2zKA2pM7dsCE+YUsyE/kPA0nvm9fBK/sT9JTSlmf3zDJdDQTG2hdq3/s5 STsVebj4+FiIzKBlK6RFhp57/RLHGxvu0b/yGM+kS2EQ2JqfkOzzxMq4GjHW/12/cro/CL77o3qkU U4rZrSeoekPcSvmhdh0QAaurw2uWmR4sQdurZWDW7UK3VQyljOcQGgOVuVEB9CNk+BdyLGPCR++PV sqG651yvkeYeCw==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1rmsGu-00070t-Kz; Wed, 20 Mar 2024 05:30:09 -0400 From: Andrea Corallo To: Andrea Corallo Subject: Re: bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be verified In-Reply-To: (Andrea Corallo's message of "Sun, 14 Mar 2021 21:07:47 +0000") References: Date: Wed, 20 Mar 2024 05:30:04 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 46847-done Cc: 46847-done@debbugs.gnu.org, Pip Cet X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I'm closing this old bug as with 0b0c7da8c80 I've installed a sanitizer that instruments the code in order to check that compile time value predictions of mvars are respected at runtime. Mvars verified are all mvars being tested by conditional branches, this to verify the correct CFG/execution of the program. Enabling sanitizer instrumentation and runtime verification I'm able to bootstrap the compiler and run all the compiler testsuite. We might extend this further in the future but I think for now is okay. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 20 09:11:54 2024 Received: (at 46847) by debbugs.gnu.org; 20 Mar 2024 13:11:54 +0000 Received: from localhost ([127.0.0.1]:44520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmvjW-0007q6-9Z for submit@debbugs.gnu.org; Wed, 20 Mar 2024 09:11:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmvjT-0007pM-DU for 46847@debbugs.gnu.org; Wed, 20 Mar 2024 09:11:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rmvdY-00060E-F1; Wed, 20 Mar 2024 09:05:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=gKcZO66TJZ2MPtaewisTKcWwPO7H3/iXU1mlzX+hpgs=; b=hKALYYWVYL2J zMg3NAR1HsH2LB0OZWG0xRl0yMbq8MWo9h1/4mmkt+4gmf1R3bKHF4/0qcBeXTEq6toQnioBWVHEy okPuyXy2K/VGtrh3PgS9WiRMufOVFOMUqdeyKB+wFzTBGpdqlgnnLRcspJ5KkVc9XvEbujRkJP8t5 SOsxaL8r5W8LcjDB7fG3nJ0pmX681eAmrLUyTV3TEhIsJGyOlgNkVf0QtaEMrQf6XNBV8en5XS6cu WWglSS4EbTshUj3Sycr2Q63cQTpS3dtbjdHP6wcI2NQK8CFpSh7vETPte8PFDeSsmtogjcdLYNgta 7kSvUZIez0rG2cLyj455pA==; Date: Wed, 20 Mar 2024 15:05:40 +0200 Message-Id: <86zfut2guz.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 20 Mar 2024 05:30:04 -0400) Subject: Re: bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be verified References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 46847 Cc: 46847@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Resent-To: bug-gnu-emacs@gnu.org > Cc: 46847-done@debbugs.gnu.org, Pip Cet > From: Andrea Corallo > Date: Wed, 20 Mar 2024 05:30:04 -0400 > > I'm closing this old bug as with 0b0c7da8c80 I've installed a sanitizer > that instruments the code in order to check that compile time value > predictions of mvars are respected at runtime. Mvars verified are all > mvars being tested by conditional branches, this to verify the correct > CFG/execution of the program. > > Enabling sanitizer instrumentation and runtime verification I'm able to > bootstrap the compiler and run all the compiler testsuite. > > We might extend this further in the future but I think for now is okay. Thanks, but would it be possible to document the suggested use of this sanitizer in the comments somewhere? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 20 09:59:52 2024 Received: (at 46847) by debbugs.gnu.org; 20 Mar 2024 13:59:52 +0000 Received: from localhost ([127.0.0.1]:47884 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmwTw-0001gS-0A for submit@debbugs.gnu.org; Wed, 20 Mar 2024 09:59:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33762) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmwTu-0001g4-G3 for 46847@debbugs.gnu.org; Wed, 20 Mar 2024 09:59:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rmwTB-0001Xd-Hj; Wed, 20 Mar 2024 09:59:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=lzf3nPRsT0ycYqUF2vZ3O+A/D0F7W+coe8yzeonFmrs=; b=S5llm8lg0QlVP3LSQjyu AJyUssae4CVIFxvBXp/zEtCbta1zAgUk1rNmjQeFCXIDY3yzCTDfh+YCLG1HytlNtO4k/1BOaabD9 5cydQl9whFfgilQbA5NLbwRUeo+40bEpTSjzzQ6DqUFw0vYFB1JRzvLY5ywcWL0Ee8iyz2v0n0NkV AeG5kYkI625PqitOs0Nq0PT6FzVUKeAdhGMJOPAmVorQkJysGAodueAI1D2kENa8mFS+tveYNp+kw Vc8+gR+F4dWJRPWZR3AfJdryn7jTwRY70gYLPnw3TeEsE4wfPI2O8kouwReCSzBb/3QWWwCJR5UnY IB0xKygRzSX+Pg==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1rmwT2-0001LW-3P; Wed, 20 Mar 2024 09:59:03 -0400 From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be verified In-Reply-To: <86zfut2guz.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 20 Mar 2024 15:05:40 +0200") References: <86zfut2guz.fsf@gnu.org> Date: Wed, 20 Mar 2024 09:58:53 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 46847 Cc: 46847@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> Resent-To: bug-gnu-emacs@gnu.org >> Cc: 46847-done@debbugs.gnu.org, Pip Cet >> From: Andrea Corallo >> Date: Wed, 20 Mar 2024 05:30:04 -0400 >> >> I'm closing this old bug as with 0b0c7da8c80 I've installed a sanitizer >> that instruments the code in order to check that compile time value >> predictions of mvars are respected at runtime. Mvars verified are all >> mvars being tested by conditional branches, this to verify the correct >> CFG/execution of the program. >> >> Enabling sanitizer instrumentation and runtime verification I'm able to >> bootstrap the compiler and run all the compiler testsuite. >> >> We might extend this further in the future but I think for now is okay. > > Thanks, but would it be possible to document the suggested use of this > sanitizer in the comments somewhere? Hi Eli, that's a good point. There are many usage scenarios, I just added a simple example at the beginning of the 'Sanitizer pass specific code' section. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 20 10:10:03 2024 Received: (at 46847) by debbugs.gnu.org; 20 Mar 2024 14:10:03 +0000 Received: from localhost ([127.0.0.1]:47963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmwdm-0002Ck-K5 for submit@debbugs.gnu.org; Wed, 20 Mar 2024 10:10:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmwdj-0002C5-VG for 46847@debbugs.gnu.org; Wed, 20 Mar 2024 10:10:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rmwd1-00046h-1k; Wed, 20 Mar 2024 10:09:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Du8XElGiF5iuUd7hpIekUjjsP8vljg8SsuUG7Chxq+c=; b=Ka20LAqmQPbS tu/dETnFNK+0iK1zS84jIQFrMukbBXmWvpvwVBQOjYMlAGsCr9LqfTPvtEe6l2Wg3KhxhVQjxfnrC eec/rrAtx8QPJ5W959GjEDElmxadveklGcu/vGzfPtNHUXOyztwlEMqK14LCU0h7WaUGBl4SN+sGU mi600Yffaxf4QKdMPxC209gSWhe5HjjGW2Rb1A/Hj0mesQRIcplZaUE4OudKWsi7x9PehOMhp5eLc pGovV8hjk8GahG8dMPOZZf6GK4fs5hz+fEoy5/FWg3LGNrK8T7o3tR3RDKyZQpy6X7atNd1m34h1w Y1c05xJ0TUpDvOoCDX2juA==; Date: Wed, 20 Mar 2024 16:09:12 +0200 Message-Id: <86ttl12dx3.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 20 Mar 2024 09:58:53 -0400) Subject: Re: bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be verified References: <86zfut2guz.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 46847 Cc: 46847@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Andrea Corallo > Cc: 46847@debbugs.gnu.org, pipcet@gmail.com > Date: Wed, 20 Mar 2024 09:58:53 -0400 > > Eli Zaretskii writes: > > > Thanks, but would it be possible to document the suggested use of this > > sanitizer in the comments somewhere? > > Hi Eli, > > that's a good point. > > There are many usage scenarios, I just added a simple example at the > beginning of the 'Sanitizer pass specific code' section. Thanks! From unknown Wed Sep 10 10:23:14 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 18 Apr 2024 11:26:45 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator