From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: --with-native-compilation build failure on 32-bit systems Date: Thu, 18 Aug 2022 16:42:24 +0000 Message-ID: References: <86k07nl9qe.fsf@phe.ftfl.ca> <87bksyc36k.fsf@gnus.org> <83h72lvf8g.fsf@gnu.org> <838rnmceq7.fsf@gnu.org> <83lermarzk.fsf@gnu.org> <83ilmpc2bi.fsf@gnu.org> <83h729c07k.fsf@gnu.org> <83fshtbsy0.fsf@gnu.org> <83k075fx6r.fsf@gnu.org> <83fshtfstd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22935"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: larsi@gnus.org, jrm@ftfl.ca, emacs-devel@gnu.org, emacs@FreeBSD.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 18 18:43:57 2022 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 1oOicf-0005lI-4i for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Aug 2022 18:43:57 +0200 Original-Received: from localhost ([::1]:60690 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOice-00046B-1r for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Aug 2022 12:43:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47842) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOibI-0003Da-8h for emacs-devel@gnu.org; Thu, 18 Aug 2022 12:42:32 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:62560) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOibF-0003Tn-2V; Thu, 18 Aug 2022 12:42:32 -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 27IGgOar028684 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 18 Aug 2022 16:42:24 GMT In-Reply-To: <83fshtfstd.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 18 Aug 2022 18:57:18 +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, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:293615 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: larsi@gnus.org, jrm@ftfl.ca, emacs-devel@gnu.org, emacs@FreeBSD.org >> Date: Thu, 18 Aug 2022 14:50:23 +0000 >> >> Eli Zaretskii writes: >> >> >> From: Andrea Corallo >> >> Cc: larsi@gnus.org, jrm@ftfl.ca, emacs-devel@gnu.org, emacs@FreeBSD.org >> >> Date: Thu, 18 Aug 2022 14:09:45 +0000 >> >> >> >> Eli Zaretskii writes: >> >> >> >> >> From: Andrea Corallo >> >> >> Cc: larsi@gnus.org, jrm@ftfl.ca, emacs-devel@gnu.org, emacs@FreeBSD.org >> >> >> Date: Thu, 18 Aug 2022 11:08:32 +0000 >> >> >> >> >> >> On 64bit I get: >> >> >> >> >> >> emacs:0:Pure Lisp storage overflow (approx. 3366891 bytes needed) >> >> >> >> >> >> On 32: >> >> >> >> >> >> emacs:0:Pure Lisp storage overflow (approx. 2549794 bytes needed) >> >> > >> >> > That's soooo strange! If I start Emacs under GDB and print the value >> >> > of PURESIZE, I get 6000000 bytes in a 64-bit build and 4480000 bytes >> >> > in a 32-bit build --with-wide-int. What values do you see? >> >> > >> >> > Maybe the problem happens only in --without-x builds? >> >> >> >> I get 2000000 on the 32bit build and 3333333 on 64 bit. Both are indeed >> >> --without-x. According a to comment in puresize.h this has an effect. >> > >> > What is the value of SYSTEM_PURESIZE_EXTRA in both cases? >> >> Zero in both cases. > > I'm confused. puresize.h says > > #define BASE_PURESIZE (2750000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA) > [...] > #define PURESIZE (BASE_PURESIZE * PURESIZE_RATIO * PURESIZE_CHECKING_RATIO) > > So even if PURESIZE_RATIO and PURESIZE_CHECKING_RATIO are both 1, how > come you get 2000000 in the 32-bit build, when SYSTEM_PURESIZE_EXTRA > is zero? I must be missing something. It's 2000000 as my testbed for this bug as mentioned it is based on aff5961274 (a master around the time the bug was reported), so before your e46668847d. Your commit changed the constant we add for computing BASE_PURESIZE from 2000000 to 2750000. This also indeed explains why Joseph reported the build to be again working even without my fixes to the nativecomp side. Thanks Andrea