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: The emacs-28 release branch has been created Date: Mon, 04 Oct 2021 19:38:43 +0000 Message-ID: References: <83lf3dgbl3.fsf@gnu.org> <6c7a9f1a-bf2d-4213-b954-2025eee1f282@cornell.edu> <838rzaa264.fsf@gnu.org> <2434455f-34f5-3e6b-b26f-db7b66cf8f3d@cornell.edu> <83ee9287ef.fsf@gnu.org> <83a6jq84wu.fsf@gnu.org> <10401c4a-1d0a-817c-942e-f08ab3130552@cornell.edu> <834k9y814j.fsf@gnu.org> <83tuhx7w54.fsf@gnu.org> <30b78a17-2b95-5d0c-fb46-10c37ee91638@cornell.edu> <96912815-d275-8b54-9ba8-cc4fd5b0fe91@cornell.edu> <83v92c6f4n.fsf@gnu.org> <83sfxg6ehc.fsf@gnu.org> <83r1d06dry.fsf@gnu.org> <83h7dw681k.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="36488"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: kbrown@cornell.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 04 21:39:25 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 1mXTo4-0009Ho-0P for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Oct 2021 21:39:24 +0200 Original-Received: from localhost ([::1]:33688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mXTo3-0001ja-0a for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Oct 2021 15:39:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38236) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXTnY-000134-4O for emacs-devel@gnu.org; Mon, 04 Oct 2021 15:38:52 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:59841) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXTnW-0006xN-08; Mon, 04 Oct 2021 15:38: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 194JchhY021185 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 4 Oct 2021 19:38:44 GMT In-Reply-To: <83h7dw681k.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 04 Oct 2021 19:58:47 +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:276258 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: kbrown@cornell.edu, emacs-devel@gnu.org >> Date: Mon, 04 Oct 2021 16:15:35 +0000 >> >> Okay I see what's the issue. In `comp-final' we spawn a child process >> to run the final pass or not discriminating on the `byte+native-compile' >> var. This is wrong cause this is not bound when using >> `batch-native-compile'. >> >> When spawning the sub-process we print the limple dump in a file and this >> gets in this case truncated (still to be understood why) leading to the >> error. >> >> Will come with patch after dinner. > > Thanks. Attached. Ok for emacs-28? > I'd appreciate if you could later describe how you debugged this > problem and how did you arrive to the root cause. We desperately need > to become more proficient in debugging problems with > native-compilation, and perhaps develop tools and techniques to > support that. Sure even tho in this case the process was not much sophisticated :) - I reduced the reproducer searching manually by bissection in the file for the function causing the ICE - Once identified the function I removed pieces of it to make it the smallest function still ICing the compiler - I read carefully the stack trace of the compiler (after having posted it here :/ ) and saw that the reader error was not on file being compiled but on the file that we use to drive the native compilation happening in the subprocess (the one generated by `comp-final'). - I looked into one of these files and I saw clearly in the limple dump a constant vector that is truncated (not sure why maybe we have to bind some other print-something var in comp final?). - Wondered why we are trying to spawn a child process for running the final pass if we are doing a batch compilation and found the issue reading the code. Regards Andrea