From unknown Sat Jun 21 03:19:57 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#46495 <46495@debbugs.gnu.org> To: bug#46495 <46495@debbugs.gnu.org> Subject: Status: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int Reply-To: bug#46495 <46495@debbugs.gnu.org> Date: Sat, 21 Jun 2025 10:19:57 +0000 retitle 46495 28.0.50; [native-comp] Build fails for 32bit --with-wide-int reassign 46495 emacs submitter 46495 Andy Moreton severity 46495 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 13 12:57:17 2021 Received: (at submit) by debbugs.gnu.org; 13 Feb 2021 17:57:17 +0000 Received: from localhost ([127.0.0.1]:34993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lAzAS-0000pl-Pz for submit@debbugs.gnu.org; Sat, 13 Feb 2021 12:57:17 -0500 Received: from lists.gnu.org ([209.51.188.17]:54894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lAzAQ-0000pd-GZ for submit@debbugs.gnu.org; Sat, 13 Feb 2021 12:57:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39586) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAzAQ-0003Ho-6N for bug-gnu-emacs@gnu.org; Sat, 13 Feb 2021 12:57:14 -0500 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]:33178) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lAzAO-0006Ka-H4 for bug-gnu-emacs@gnu.org; Sat, 13 Feb 2021 12:57:13 -0500 Received: by mail-ed1-x530.google.com with SMTP id c6so3655129ede.0 for ; Sat, 13 Feb 2021 09:57:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:subject:from:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=/wtO34aGGAp2g3F8VDv8KcqAWk25DGjNVEpZhp9C/jA=; b=j00BFeU/ss85/jpXcoKID98Eq+f/61i6yRtvOKGixDfLWJeh+OHYSQLXHzj/U7vSNf NVe4H0Mfl0J0NdM2RN/q6O3GMhq5VIM6nsScYtppS1ivXMiK3q+qX33iVayHBJ58FvuW L2xgeL7yGnjkd4/s3O1Jn7CSDzBxo++/DzDbOqs6aYvv06MTssfU61zT3UeuYm8GL9qJ 8izpDNKSPTs/U6IC7fKzaYUhm4sOp/jf1vSuHavTMqUXBIGqMscSP/hxyZRLnYeZAjfA yhz3V5Ybt4OOp7CWJFBfgNYoPz2AMIOSq8dTLqPb54DfUjC72fAQ94VkUAxlnHPhetSW ow/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:subject:from:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=/wtO34aGGAp2g3F8VDv8KcqAWk25DGjNVEpZhp9C/jA=; b=aSZlM7/V890UJAuwa0pFdsfthALrv11HXyfWdwUU5wbK4c1Pu8Rffn3VzYSXgndATo mg6EqMc56f811FBZuyQd7zbFZQ/ad5N3dW8a2Z3GFw2cBO8dRpqdJ6DlrGibUfTkgdAh SzsoH2Fgj7/JLNC6DtCisnHgXSIbabbFUsIn8dlDQjHHtTQsT2q2Lr0p/nQ+h0hNX/Iu 2UCeZJWz81URRPFUhNFEFxiB5SYqT+y3DenY5LV8z5bMMWBmbtnQ0VS8RVNZXCHSb63O kx3INPpq/21S6hsz/nZJY+1p6AOL+q5IKcCShFA6wJGU42OmrfvEVU0A57a7lJaNzlKe uifg== X-Gm-Message-State: AOAM532T9LxARF2XtTjVpd8o7bsf1CE0EnOE/0reZQKIDtO3xKyl6Y/i YWlob0Xz/mlrkh9fXv7x2t0KmIOl56Y= X-Google-Smtp-Source: ABdhPJxrQveQxiyKjCVZzL7OZJYoHDX3oXrAhMFd8u4e1r+NjpxBAk/shsx8INhHnp5pnmq8TYFo9w== X-Received: by 2002:a05:6402:1914:: with SMTP id e20mr8557846edz.89.1613239031026; Sat, 13 Feb 2021 09:57:11 -0800 (PST) Received: from [192.168.0.6] (82-69-64-228.dsl.in-addr.zen.co.uk. [82.69.64.228]) by smtp.gmail.com with ESMTPSA id kb13sm636517ejb.7.2021.02.13.09.57.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Feb 2021 09:57:10 -0800 (PST) To: bug-gnu-emacs@gnu.org Subject: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int From: Andy Moreton Message-ID: Date: Sat, 13 Feb 2021 17:57:09 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2a00:1450:4864:20::530; envelope-from=andrewjmoreton@gmail.com; helo=mail-ed1-x530.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 (--) On Windows with the mingw64 32bit toolchain, the native branch build fails when configured with "--with-nativecomp --with-wide-int". Emacs crashes during .eln compilation. Attaching gdb to the crashing emacs process does not produce a backtrace. I suspect that this problem may not be Windows-specific, and should be reproducable on Linux, but I have not tried that. AndyM From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 13 13:10:43 2021 Received: (at 46495) by debbugs.gnu.org; 13 Feb 2021 18:10:43 +0000 Received: from localhost ([127.0.0.1]:35002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lAzNT-0001Ai-DS for submit@debbugs.gnu.org; Sat, 13 Feb 2021 13:10:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lAzNS-0001AV-3d for 46495@debbugs.gnu.org; Sat, 13 Feb 2021 13:10:42 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54446) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAzNM-0001zj-VU; Sat, 13 Feb 2021 13:10:36 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4424 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lAzN2-0002j7-Ho; Sat, 13 Feb 2021 13:10:36 -0500 Date: Sat, 13 Feb 2021 20:10:16 +0200 Message-Id: <835z2vdek7.fsf@gnu.org> From: Eli Zaretskii To: Andy Moreton In-Reply-To: (message from Andy Moreton on Sat, 13 Feb 2021 17:57:09 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: 46495@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.7 (-) > From: Andy Moreton > Date: Sat, 13 Feb 2021 17:57:09 +0000 > > On Windows with the mingw64 32bit toolchain, the native branch build > fails when configured with "--with-nativecomp --with-wide-int". > > Emacs crashes during .eln compilation. Attaching gdb to the crashing > emacs process does not produce a backtrace. What does GDB produce if you attach it? Can you run a compilation from Emacs that runs under GDB? From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 13 15:25:08 2021 Received: (at submit) by debbugs.gnu.org; 13 Feb 2021 20:25:08 +0000 Received: from localhost ([127.0.0.1]:35126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lB1TY-0004Pd-74 for submit@debbugs.gnu.org; Sat, 13 Feb 2021 15:25:08 -0500 Received: from lists.gnu.org ([209.51.188.17]:44546) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lB1TV-0004PT-Ns for submit@debbugs.gnu.org; Sat, 13 Feb 2021 15:25:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40442) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lB1TV-0000Aa-IO for bug-gnu-emacs@gnu.org; Sat, 13 Feb 2021 15:25:05 -0500 Received: from ciao.gmane.io ([116.202.254.214]:36132) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lB1TU-0002W9-A3 for bug-gnu-emacs@gnu.org; Sat, 13 Feb 2021 15:25:05 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lB1TS-00095o-As for bug-gnu-emacs@gnu.org; Sat, 13 Feb 2021 21:25:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int Date: Sat, 13 Feb 2021 20:23:20 +0000 Message-ID: <868s7riuo7.fsf@gmail.com> References: <835z2vdek7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt) Cancel-Lock: sha1:CQF9bP0+xz691stI061t4eb2OiY= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.1 (/) 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: -0.9 (/) On Sat 13 Feb 2021, Eli Zaretskii wrote: >> From: Andy Moreton >> Date: Sat, 13 Feb 2021 17:57:09 +0000 >> >> On Windows with the mingw64 32bit toolchain, the native branch build >> fails when configured with "--with-nativecomp --with-wide-int". >> >> Emacs crashes during .eln compilation. Attaching gdb to the crashing >> emacs process does not produce a backtrace. > > What does GDB produce if you attach it? Nothing - the windows tra handler, followed by gdb deciding that something has died and giving up completely. > Can you run a compilation from Emacs that runs under GDB? How do I do that in a way that captures only the relevant subprocesses ? AndyM From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 14 08:24:42 2021 Received: (at submit) by debbugs.gnu.org; 14 Feb 2021 13:24:42 +0000 Received: from localhost ([127.0.0.1]:35581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBHOD-0008Ay-T0 for submit@debbugs.gnu.org; Sun, 14 Feb 2021 08:24:42 -0500 Received: from lists.gnu.org ([209.51.188.17]:60324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBHOC-0008Ar-No for submit@debbugs.gnu.org; Sun, 14 Feb 2021 08:24:41 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47928) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBHOB-0008QT-Pv for bug-gnu-emacs@gnu.org; Sun, 14 Feb 2021 08:24:40 -0500 Received: from ciao.gmane.io ([116.202.254.214]:46178) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBHOA-0003vF-HA for bug-gnu-emacs@gnu.org; Sun, 14 Feb 2021 08:24:39 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lBHO8-000A4B-W2 for bug-gnu-emacs@gnu.org; Sun, 14 Feb 2021 14:24:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int Date: Sun, 14 Feb 2021 13:24:32 +0000 Message-ID: <86y2fq93zj.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt) Cancel-Lock: sha1:4BLLL4maAMefMA3hM+kUT6MKkyE= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.1 (/) 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: -0.9 (/) On Sat 13 Feb 2021, Andy Moreton wrote: > On Windows with the mingw64 32bit toolchain, the native branch build > fails when configured with "--with-nativecomp --with-wide-int". > > Emacs crashes during .eln compilation. Attaching gdb to the crashing > emacs process does not produce a backtrace. > > I suspect that this problem may not be Windows-specific, and should be > reproducable on Linux, but I have not tried that. I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32) when configured with with "--with-nativecomp --with-wide-int", and that works. Thus this bug seems to be a problem with the MSYS2 mingw32 32bit toolchain (i686-w64-mingw32) only. AndyM From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 14 10:56:26 2021 Received: (at 46495) by debbugs.gnu.org; 14 Feb 2021 15:56:26 +0000 Received: from localhost ([127.0.0.1]:36587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBJl3-0005hX-ON for submit@debbugs.gnu.org; Sun, 14 Feb 2021 10:56:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52992) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBJl1-0005hI-G2 for 46495@debbugs.gnu.org; Sun, 14 Feb 2021 10:56:24 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40278) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lBJkv-0002zZ-Ny; Sun, 14 Feb 2021 10:56:17 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1348 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lBJku-00088p-Rw; Sun, 14 Feb 2021 10:56:17 -0500 Date: Sun, 14 Feb 2021 17:56:19 +0200 Message-Id: <83lfbqbq3g.fsf@gnu.org> From: Eli Zaretskii To: Andy Moreton In-Reply-To: <86y2fq93zj.fsf@gmail.com> (message from Andy Moreton on Sun, 14 Feb 2021 13:24:32 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: 46495@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.7 (-) > From: Andy Moreton > Date: Sun, 14 Feb 2021 13:24:32 +0000 > > > I suspect that this problem may not be Windows-specific, and should be > > reproducable on Linux, but I have not tried that. > > I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32) when > configured with with "--with-nativecomp --with-wide-int", and that > works. Thanks, that's good news. > Thus this bug seems to be a problem with the MSYS2 mingw32 32bit > toolchain (i686-w64-mingw32) only. It does seem that way, although I wonder what could that problem be... From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 14 10:59:46 2021 Received: (at 46495) by debbugs.gnu.org; 14 Feb 2021 15:59:46 +0000 Received: from localhost ([127.0.0.1]:36591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBJoI-0005mG-8P for submit@debbugs.gnu.org; Sun, 14 Feb 2021 10:59:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBJoH-0005m5-NU for 46495@debbugs.gnu.org; Sun, 14 Feb 2021 10:59:45 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40333) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lBJoB-0003sC-7U; Sun, 14 Feb 2021 10:59:40 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1554 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lBJoA-0004Go-5u; Sun, 14 Feb 2021 10:59:38 -0500 Date: Sun, 14 Feb 2021 17:59:41 +0200 Message-Id: <83k0rabpxu.fsf@gnu.org> From: Eli Zaretskii To: Andy Moreton In-Reply-To: <868s7riuo7.fsf@gmail.com> (message from Andy Moreton on Sat, 13 Feb 2021 20:23:20 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <835z2vdek7.fsf@gnu.org> <868s7riuo7.fsf@gmail.com> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: 46495@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.7 (-) > From: Andy Moreton > Date: Sat, 13 Feb 2021 20:23:20 +0000 > > > Can you run a compilation from Emacs that runs under GDB? > > How do I do that in a way that captures only the relevant subprocesses ? That's "set follow-exec-mode" in GDB, but I don't know if it works on Windows. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 14 14:26:19 2021 Received: (at 46495) by debbugs.gnu.org; 14 Feb 2021 19:26:19 +0000 Received: from localhost ([127.0.0.1]:36768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBN2B-0004ex-2p for submit@debbugs.gnu.org; Sun, 14 Feb 2021 14:26:19 -0500 Received: from mx.sdf.org ([205.166.94.24]:60978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBN27-0004ei-EI for 46495@debbugs.gnu.org; Sun, 14 Feb 2021 14:26: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 11EJQD4r023309 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sun, 14 Feb 2021 19:26:14 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> Date: Sun, 14 Feb 2021 19:26:13 +0000 In-Reply-To: <83lfbqbq3g.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 14 Feb 2021 17:56:19 +0200") 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: 46495 Cc: Andy Moreton , 46495@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 (-) Eli Zaretskii writes: >> From: Andy Moreton >> Date: Sun, 14 Feb 2021 13:24:32 +0000 >> >> > I suspect that this problem may not be Windows-specific, and should be >> > reproducable on Linux, but I have not tried that. >> >> I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32) when >> configured with with "--with-nativecomp --with-wide-int", and that >> works. > > Thanks, that's good news. > >> Thus this bug seems to be a problem with the MSYS2 mingw32 32bit >> toolchain (i686-w64-mingw32) only. > > It does seem that way, although I wonder what could that problem be... Well... I can confirm also i686-pc-linux-gnu "--with-nativecomp --with-wide-int" looks broken for me. I'm going to look into this the coming week. Andrea From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 15 04:01:32 2021 Received: (at submit) by debbugs.gnu.org; 15 Feb 2021 09:01:32 +0000 Received: from localhost ([127.0.0.1]:37241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBZl6-0007qc-Af for submit@debbugs.gnu.org; Mon, 15 Feb 2021 04:01:32 -0500 Received: from lists.gnu.org ([209.51.188.17]:34858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBZl4-0007qV-Um for submit@debbugs.gnu.org; Mon, 15 Feb 2021 04:01:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55340) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBZl4-0001Dj-Ks for bug-gnu-emacs@gnu.org; Mon, 15 Feb 2021 04:01:30 -0500 Received: from ciao.gmane.io ([116.202.254.214]:41280) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBZl3-0003Fa-38 for bug-gnu-emacs@gnu.org; Mon, 15 Feb 2021 04:01:30 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lBZkz-0007Z1-VH for bug-gnu-emacs@gnu.org; Mon, 15 Feb 2021 10:01:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int Date: Mon, 15 Feb 2021 09:01:19 +0000 Message-ID: <868s7pwvq8.fsf@gmail.com> References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt) Cancel-Lock: sha1:tcVNqM0Xas7UHOo60UoGqH+Fz+U= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.1 (/) 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: -0.9 (/) On Sun 14 Feb 2021, Eli Zaretskii wrote: >> From: Andy Moreton >> Date: Sun, 14 Feb 2021 13:24:32 +0000 >> >> > I suspect that this problem may not be Windows-specific, and should be >> > reproducable on Linux, but I have not tried that. >> >> I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32) when >> configured with with "--with-nativecomp --with-wide-int", and that >> works. > > Thanks, that's good news. > >> Thus this bug seems to be a problem with the MSYS2 mingw32 32bit >> toolchain (i686-w64-mingw32) only. > > It does seem that way, although I wonder what could that problem be... I have only just discovered this news item: https://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supported Perhaps that means that only the mingw.org (i686-w64-mingw32) toolchain should be supported for 32bit builds on Windows. AndyM From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 15 05:19:54 2021 Received: (at submit) by debbugs.gnu.org; 15 Feb 2021 10:19:54 +0000 Received: from localhost ([127.0.0.1]:37381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBayv-0001W9-T5 for submit@debbugs.gnu.org; Mon, 15 Feb 2021 05:19:54 -0500 Received: from lists.gnu.org ([209.51.188.17]:46390) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBayu-0001W2-Oi for submit@debbugs.gnu.org; Mon, 15 Feb 2021 05:19:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46204) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBayu-0006f5-IQ for bug-gnu-emacs@gnu.org; Mon, 15 Feb 2021 05:19:52 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55020) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lBayu-00043f-7u; Mon, 15 Feb 2021 05:19:52 -0500 Received: from [2a02:14f:1ff:55e2::dc4:5591] (port=59138) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1lBays-0006lX-Q9; Mon, 15 Feb 2021 05:19:51 -0500 Date: Mon, 15 Feb 2021 12:19:48 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <868s7pwvq8.fsf@gmail.com> References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int To: bug-gnu-emacs@gnu.org, Andy Moreton , 46495@debbugs.gnu.org From: Eli Zaretskii Message-ID: <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> X-Spam-Score: -2.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: -3.3 (---) On February 15, 2021 11:01:19 AM GMT+02:00, Andy Moreton wrote: > On Sun 14 Feb 2021, Eli Zaretskii wrote: >=20 > >> From: Andy Moreton > >> Date: Sun, 14 Feb 2021 13:24:32 +0000 > >>=20 > >> > I suspect that this problem may not be Windows-specific, and > should be > >> > reproducable on Linux, but I have not tried that=2E > >>=20 > >> I have also tried the mingw=2Eorg 32bit toolchain (i686-pc-mingw32) > when > >> configured with with "--with-nativecomp --with-wide-int", and that > >> works=2E > > > > Thanks, that's good news=2E > > > >> Thus this bug seems to be a problem with the MSYS2 mingw32 32bit > >> toolchain (i686-w64-mingw32) only=2E > > > > It does seem that way, although I wonder what could that problem > be=2E=2E=2E >=20 > I have only just discovered this news item: >=20 > https://www=2Emsys2=2Eorg/news/#2020-05-17-32-bit-msys2-no-longer-active= ly-supported >=20 > Perhaps that means that only the mingw=2Eorg (i686-w64-mingw32) > toolchain > should be supported for 32bit builds on Windows=2E >=20 > AndyM Right, but Andrea said there were problems on Posix systems as well with t= his configuration, so it could be that something else is at work here=2E From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 15 07:56:39 2021 Received: (at 46495) by debbugs.gnu.org; 15 Feb 2021 12:56:39 +0000 Received: from localhost ([127.0.0.1]:37644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBdQd-0007tJ-BK for submit@debbugs.gnu.org; Mon, 15 Feb 2021 07:56:39 -0500 Received: from mx.sdf.org ([205.166.94.24]:62770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBdQa-0007t9-Jd for 46495@debbugs.gnu.org; Mon, 15 Feb 2021 07:56:38 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11FCuZ8g019424 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 15 Feb 2021 12:56:35 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> Date: Mon, 15 Feb 2021 12:56:35 +0000 In-Reply-To: <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> (Eli Zaretskii's message of "Mon, 15 Feb 2021 12:19:48 +0200") 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: 46495 Cc: andrewjmoreton@gmail.com, 46495@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 (-) Eli Zaretskii writes: > On February 15, 2021 11:01:19 AM GMT+02:00, Andy Moreton wrote: >> On Sun 14 Feb 2021, Eli Zaretskii wrote: >> >> >> From: Andy Moreton >> >> Date: Sun, 14 Feb 2021 13:24:32 +0000 >> >> >> >> > I suspect that this problem may not be Windows-specific, and >> should be >> >> > reproducable on Linux, but I have not tried that. >> >> >> >> I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32) >> when >> >> configured with with "--with-nativecomp --with-wide-int", and that >> >> works. >> > >> > Thanks, that's good news. >> > >> >> Thus this bug seems to be a problem with the MSYS2 mingw32 32bit >> >> toolchain (i686-w64-mingw32) only. >> > >> > It does seem that way, although I wonder what could that problem >> be... >> >> I have only just discovered this news item: >> >> https://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supported >> >> Perhaps that means that only the mingw.org (i686-w64-mingw32) >> toolchain >> should be supported for 32bit builds on Windows. >> >> AndyM > > Right, but Andrea said there were problems on Posix systems as well with this configuration, so it could be that something else is at work here. Confirm, I see a problem compiling closures, this should be the responsible for the bootstrap to be broken (at least on my case). Yesterday I've already reduced a small reproducer so I should be on the good way to understand during the next debug session why this is happening only on wide-int. It will be interesting why is working in some configuration and not in others. Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 16 04:34:59 2021 Received: (at submit) by debbugs.gnu.org; 16 Feb 2021 09:34:59 +0000 Received: from localhost ([127.0.0.1]:39394 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBwl0-0007Ur-HX for submit@debbugs.gnu.org; Tue, 16 Feb 2021 04:34:58 -0500 Received: from lists.gnu.org ([209.51.188.17]:60450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBwky-0007Uj-RH for submit@debbugs.gnu.org; Tue, 16 Feb 2021 04:34:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37182) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBwky-00033I-KO for bug-gnu-emacs@gnu.org; Tue, 16 Feb 2021 04:34:56 -0500 Received: from mx.sdf.org ([205.166.94.24]:62919) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBwkw-0007i5-Ds; Tue, 16 Feb 2021 04:34:56 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11G9YnCr022708 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 16 Feb 2021 09:34:50 GMT From: Andrea Corallo To: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> Date: Tue, 16 Feb 2021 09:34:49 +0000 In-Reply-To: (Andrea Corallo via's message of "Mon, 15 Feb 2021 12:56:35 +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 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-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , andrewjmoreton@gmail.com, 46495@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: -2.4 (--) Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Eli Zaretskii writes: > >> On February 15, 2021 11:01:19 AM GMT+02:00, Andy Moreton wrote: >>> On Sun 14 Feb 2021, Eli Zaretskii wrote: >>> >>> >> From: Andy Moreton >>> >> Date: Sun, 14 Feb 2021 13:24:32 +0000 >>> >> >>> >> > I suspect that this problem may not be Windows-specific, and >>> should be >>> >> > reproducable on Linux, but I have not tried that. >>> >> >>> >> I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32) >>> when >>> >> configured with with "--with-nativecomp --with-wide-int", and that >>> >> works. >>> > >>> > Thanks, that's good news. >>> > >>> >> Thus this bug seems to be a problem with the MSYS2 mingw32 32bit >>> >> toolchain (i686-w64-mingw32) only. >>> > >>> > It does seem that way, although I wonder what could that problem >>> be... >>> >>> I have only just discovered this news item: >>> >>> https://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supported >>> >>> Perhaps that means that only the mingw.org (i686-w64-mingw32) >>> toolchain >>> should be supported for 32bit builds on Windows. >>> >>> AndyM >> >> Right, but Andrea said there were problems on Posix systems as well with this configuration, so it could be that something else is at work here. > > Confirm, I see a problem compiling closures, this should be the > responsible for the bootstrap to be broken (at least on my case). > > Yesterday I've already reduced a small reproducer so I should be on the > good way to understand during the next debug session why this is > happening only on wide-int. > > It will be interesting why is working in some configuration and not in > others. > > Andrea Andy could you point out the two libgccjit versions you used specifying wich one was used in the successfull / failed experiment? Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 16 10:29:36 2021 Received: (at 46495) by debbugs.gnu.org; 16 Feb 2021 15:29:36 +0000 Received: from localhost ([127.0.0.1]:41242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC2IB-0008Qp-Sc for submit@debbugs.gnu.org; Tue, 16 Feb 2021 10:29:36 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC2IA-0008Qc-8x for 46495@debbugs.gnu.org; Tue, 16 Feb 2021 10:29:34 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53166) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lC2I4-0000hz-Kz; Tue, 16 Feb 2021 10:29:28 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2100 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lC2I3-0005Qr-7M; Tue, 16 Feb 2021 10:29:28 -0500 Date: Tue, 16 Feb 2021 17:29:33 +0200 Message-Id: <83a6s49gki.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Tue, 16 Feb 2021 09:34:49 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: Eli Zaretskii , andrewjmoreton@gmail.com, > 46495@debbugs.gnu.org > Date: Tue, 16 Feb 2021 09:34:49 +0000 > > Andy could you point out the two libgccjit versions you used specifying > wich one was used in the successfull / failed experiment? Right, this is another potential reason for the difference. AFAIK, MinGW64 uses GCC 10.x, whereas mingw.org uses 9.2. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 16 11:30:53 2021 Received: (at 46495) by debbugs.gnu.org; 16 Feb 2021 16:30:53 +0000 Received: from localhost ([127.0.0.1]:41353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC3FV-0003il-BY for submit@debbugs.gnu.org; Tue, 16 Feb 2021 11:30:53 -0500 Received: from mx.sdf.org ([205.166.94.24]:53207) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC3FT-0003iZ-Jx for 46495@debbugs.gnu.org; Tue, 16 Feb 2021 11:30:52 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11GGUkTm018835 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 16 Feb 2021 16:30:47 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <83a6s49gki.fsf@gnu.org> Date: Tue, 16 Feb 2021 16:30:46 +0000 In-Reply-To: <83a6s49gki.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 16 Feb 2021 17:29:33 +0200") 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: 46495 Cc: andrewjmoreton@gmail.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: Eli Zaretskii , andrewjmoreton@gmail.com, >> 46495@debbugs.gnu.org >> Date: Tue, 16 Feb 2021 09:34:49 +0000 >> >> Andy could you point out the two libgccjit versions you used specifying >> wich one was used in the successfull / failed experiment? > > Right, this is another potential reason for the difference. AFAIK, > MinGW64 uses GCC 10.x, whereas mingw.org uses 9.2. Hi Eli, I did some GCC debugging (the crash is there) using my reduced reproducer and clearly look (for my case at least) this is a libgccjit bug that we trigger only generating code for 32bit wide-int. GCC trunk is broken but as you've anticipated 9 is working (just finished an Emacs bootstrap). This evening I'll open a bug on the GCC bugzilla and link it here. Would be nice to fix it before the end of stage4... :/ Regards Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 16 12:01:25 2021 Received: (at 46495) by debbugs.gnu.org; 16 Feb 2021 17:01:25 +0000 Received: from localhost ([127.0.0.1]:41425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC3j2-0005rC-Sj for submit@debbugs.gnu.org; Tue, 16 Feb 2021 12:01:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC3j1-0005lf-DC for 46495@debbugs.gnu.org; Tue, 16 Feb 2021 12:01:24 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55475) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lC3iv-0001eY-Qb; Tue, 16 Feb 2021 12:01:17 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3752 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lC3iu-0002yw-2u; Tue, 16 Feb 2021 12:01:16 -0500 Date: Tue, 16 Feb 2021 19:01:21 +0200 Message-Id: <83wnv87xr2.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Tue, 16 Feb 2021 16:30:46 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <83a6s49gki.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > Date: Tue, 16 Feb 2021 16:30:46 +0000 > > I did some GCC debugging (the crash is there) using my reduced > reproducer and clearly look (for my case at least) this is a libgccjit > bug that we trigger only generating code for 32bit wide-int. So GCC 10 has a bug when it generates code which manipulates 64-bit integers, is that what you are saying? > GCC trunk is broken but as you've anticipated 9 is working (just > finished an Emacs bootstrap). Thanks, this is good to know. I think we should add an entry to etc/PROBLEMS about this. Does the buggy behavior of GCC 10 happen regardless of optimization level? > This evening I'll open a bug on the GCC bugzilla and link it here. > Would be nice to fix it before the end of stage4... :/ Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 16 12:17:11 2021 Received: (at 46495) by debbugs.gnu.org; 16 Feb 2021 17:17:11 +0000 Received: from localhost ([127.0.0.1]:41450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC3yJ-0007Ae-8y for submit@debbugs.gnu.org; Tue, 16 Feb 2021 12:17:11 -0500 Received: from mx.sdf.org ([205.166.94.24]:50237) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC3yG-0007AV-Ml for 46495@debbugs.gnu.org; Tue, 16 Feb 2021 12:17:10 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11GHH7jT005440 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 16 Feb 2021 17:17:07 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <83a6s49gki.fsf@gnu.org> <83wnv87xr2.fsf@gnu.org> Date: Tue, 16 Feb 2021 17:17:07 +0000 In-Reply-To: <83wnv87xr2.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 16 Feb 2021 19:01:21 +0200") 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: 46495 Cc: andrewjmoreton@gmail.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >> Date: Tue, 16 Feb 2021 16:30:46 +0000 >> >> I did some GCC debugging (the crash is there) using my reduced >> reproducer and clearly look (for my case at least) this is a libgccjit >> bug that we trigger only generating code for 32bit wide-int. > > So GCC 10 has a bug when it generates code which manipulates 64-bit > integers, is that what you are saying? It's not strictly related to the integer size. On 32bit wide-int we indeed we generate significantly different code respect to 64bit. For one case of this GCC manage to prove that a piece of code will deference a null pointer (this code in reality is unreachable) and tries to add a call to __builtin_trap () in place. Unfortunately the libgccjit front-end is not initializing this built-in declaration. This is as far as I've analyzed the problem for now. >> GCC trunk is broken but as you've anticipated 9 is working (just >> finished an Emacs bootstrap). > > Thanks, this is good to know. I think we should add an entry to > etc/PROBLEMS about this. Will do, still wants to try 10 to be sure. > Does the buggy behavior of GCC 10 happen regardless of optimization > level? I think -O0 should spot this as copy-prop is not running. We might have a better (more narrowed) ways to work around this but I need to investigate more. Will follow-up. >> This evening I'll open a bug on the GCC bugzilla and link it here. >> Would be nice to fix it before the end of stage4... :/ > > Thanks. Welcome Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 16 14:49:25 2021 Received: (at submit) by debbugs.gnu.org; 16 Feb 2021 19:49:25 +0000 Received: from localhost ([127.0.0.1]:41644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC6Ld-0002Tb-J7 for submit@debbugs.gnu.org; Tue, 16 Feb 2021 14:49:25 -0500 Received: from lists.gnu.org ([209.51.188.17]:36812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC6Lb-0002TS-Js for submit@debbugs.gnu.org; Tue, 16 Feb 2021 14:49:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56420) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lC6Lb-000280-Bl for bug-gnu-emacs@gnu.org; Tue, 16 Feb 2021 14:49:23 -0500 Received: from mx.sdf.org ([205.166.94.24]:55885) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lC6LZ-0001Dp-ED; Tue, 16 Feb 2021 14:49: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 11GJnFsk003430 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 16 Feb 2021 19:49:15 GMT From: Andrea Corallo To: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <83a6s49gki.fsf@gnu.org> <83wnv87xr2.fsf@gnu.org> Date: Tue, 16 Feb 2021 19:49:15 +0000 In-Reply-To: (Andrea Corallo via's message of "Tue, 16 Feb 2021 17:17:07 +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 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-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , andrewjmoreton@gmail.com, 46495@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: -2.4 (--) Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Eli Zaretskii writes: > >>> From: Andrea Corallo >>> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >>> Date: Tue, 16 Feb 2021 16:30:46 +0000 >>> >>> I did some GCC debugging (the crash is there) using my reduced >>> reproducer and clearly look (for my case at least) this is a libgccjit >>> bug that we trigger only generating code for 32bit wide-int. >> >> So GCC 10 has a bug when it generates code which manipulates 64-bit >> integers, is that what you are saying? > > It's not strictly related to the integer size. On 32bit wide-int we > indeed we generate significantly different code respect to 64bit. For > one case of this GCC manage to prove that a piece of code will deference > a null pointer (this code in reality is unreachable) and tries to add a > call to __builtin_trap () in place. Unfortunately the libgccjit > front-end is not initializing this built-in declaration. This is as far > as I've analyzed the problem for now. > >>> GCC trunk is broken but as you've anticipated 9 is working (just >>> finished an Emacs bootstrap). >> >> Thanks, this is good to know. I think we should add an entry to >> etc/PROBLEMS about this. > > Will do, still wants to try 10 to be sure. > >> Does the buggy behavior of GCC 10 happen regardless of optimization >> level? > > I think -O0 should spot this as copy-prop is not running. We might have > a better (more narrowed) ways to work around this but I need to > investigate more. Will follow-up. > >>> This evening I'll open a bug on the GCC bugzilla and link it here. >>> Would be nice to fix it before the end of stage4... :/ >> >> Thanks. > > Welcome > > Andrea Here the bugzilla bug with some description more: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 I think a good work-around might be to try to switch off the 'isolate-paths' pass. Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 16 15:21:42 2021 Received: (at control) by debbugs.gnu.org; 16 Feb 2021 20:21:42 +0000 Received: from localhost ([127.0.0.1]:41709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC6qs-0003Hq-7b for submit@debbugs.gnu.org; Tue, 16 Feb 2021 15:21:42 -0500 Received: from mout.gmx.net ([212.227.15.19]:58251) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC6qr-0003He-0G for control@debbugs.gnu.org; Tue, 16 Feb 2021 15:21:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613506895; bh=0Bu3cYgnyj0+6KQTVrkJyrTTVFnAvFhKuwzg8gQR8SE=; h=X-UI-Sender-Class:Date:To:From:Subject; b=NptOOy/yyYHCL63q+SPPgHaLFNQyEwFOiCzwyPZ6ZPFPAF/cYuwGhWeJFfpQkTkOi cWUYjZxfhpgqmw337rlL1pwrvb1QCQ18NflG0X3Z5XtaZsj8LQ9OxcVtsDh0I/vti8 5QXTWPnltubJhW2tJjKo0Bl9HPyUDMAGE1hIEBcs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.145.132]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MgvrL-1lmpe73ZoD-00hO76 for ; Tue, 16 Feb 2021 21:21:35 +0100 Date: Tue, 16 Feb 2021 21:21:34 +0100 Message-Id: <87sg5vu5kh.fsf@gmx.de> To: control@debbugs.gnu.org From: Michael Albinus Subject: control message for bug #46495 X-Provags-ID: V03:K1:J8PudyGsy4jpxEPLsldCXm1rH2qc+IJ4chmrTFOCu+dAFnc3OCD aLMI/fTnDTNFO73TQrTgDHXb+xEPuk+0O1wJV5gC+q6XfIV5aHYyqNesjx5XZlIefQn1ST7 A9ENQlaH3Dv6km17fSmjgY1HdYCEgKoA1B4cNeLwk7fbu1p8ChYNnMUMK7oBOM+fIR1gm0l j2xnWV8Vy4KdztAZugyJQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:V+OGN+87zow=:VX+KdzsHwC1Q+hBV/tpcyJ ktRjd0wD8GrijMY6qHS64loCRjWupZTTkjaAaJ9KkXCtpDIZBCdimw3M6fMzgEKok2w0s7CKV uPOYZz6rnXdiG7gT9POEKXl1f438pcrQ9KP4csb2aj0tB2GN/AD1TogYgy0Z1mnz0SWCTSG8s UWPZub92pN5tf8/A1x96G7Lwo2VQnrlXAti4V/9pKEJvOHI4mncffjwvy8o4OdFA7RoFws4uR Ml+vA+CKFeXWZ5A/H2pcQk5naAKO3RE4fTt1I1RU20w5avL9hZYIJLqaVRojlUQiwpwC3mIle cT3F4tLI9/vr84D8ArLGdadRVAPnCJFJIM4K/Qwsd1/mdPY3g4MlyMA+0hjUj4raJU2L/kXDi jGTvPKHppz7e/T8lb4lvRTaOu0nUAVPqn6HFc3T5a1SPL1XzxOIRNMJUab73ADw3b87kE7fwO 3zQuGulW4Ur9BfhpMPL3HS4QYXYEXoY+fBK+6tYm2DpUFnS72GRZekZ8ZuUmoe2w1FaOOV5P0 pQa03/nYMrLEKN3jsWgZoXWS3HccEfTKh4CbWPzPeS25GlIVg5QqFulYFOm770xO8GZx9O5ht 7/br11MfSJU1pGNoWzGs0lZc+TWUVKWdrU32SmsWe9zOdy/fhLJJf0uKnUFcddv2+ORPHBXnr jIEUPcphW43qhVg8+9ZLAzxckNlCpnNBtHKzdzXCMFrnO0XvWDg1ZnPMaq3LIEVNQtfTeo06F xN4+jNfhIjLfmtA8wo/EWAgMkqSAfqAsYygS5IY+lQaJvqfiDb+nYpVENRzYyC2HRhrm2ZlAj YZLbwsn8InyowhViX6KxE7aOG2pqv49BCGwo6iNZ0V1ke77FNS56o7FACCh10WPQ6DNgMvyo+ T2ZB5LkHojqs/Nwpkz9Q== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control 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.7 (-) forwarded 46495 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 quit From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 16 16:51:34 2021 Received: (at submit) by debbugs.gnu.org; 16 Feb 2021 21:51:34 +0000 Received: from localhost ([127.0.0.1]:41868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC8Fq-0007cY-BM for submit@debbugs.gnu.org; Tue, 16 Feb 2021 16:51:34 -0500 Received: from lists.gnu.org ([209.51.188.17]:52912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lC8Fo-0007cQ-Vs for submit@debbugs.gnu.org; Tue, 16 Feb 2021 16:51:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57194) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lC8Fo-0007eO-NU for bug-gnu-emacs@gnu.org; Tue, 16 Feb 2021 16:51:32 -0500 Received: from ciao.gmane.io ([116.202.254.214]:60558) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lC8Fn-00077L-7B for bug-gnu-emacs@gnu.org; Tue, 16 Feb 2021 16:51:32 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lC8Fh-0000v7-Kc for bug-gnu-emacs@gnu.org; Tue, 16 Feb 2021 22:51:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int Date: Tue, 16 Feb 2021 21:51:19 +0000 Message-ID: <86o8gjheaw.fsf@gmail.com> References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt) Cancel-Lock: sha1:5uHIaT8mnJ9i7VtLcm9eZiwKFMQ= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 4 X-Spam_score: 0.4 X-Spam_bar: / X-Spam_report: (0.4 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.19, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.1 (/) 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: -0.9 (/) On Tue 16 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: > Andy could you point out the two libgccjit versions you used specifying > wich one was used in the successfull / failed experiment? It seems they both now fail (and I have lost the build log from the successful experiment, so I don't have a note of the commit used). mingw.org (i686-w64-mingw32) ---------------------------- I retried the mingw.org build configured with "--with-nativecomp --with-wide-int" (starting from "git clean -xdf"), and that now fails at commit 31416495ad9b2c84473f72ad99e2adc87dd66e5a. My mingw.org installation has libgccjit packages: libgccjit-9.2.0-2-mingw32-dev.tar.xz libgccjit-9.2.0-2-mingw32-dll-0.tar.xz libgccjit-9.2.0-2-mingw32-info.tar.xz These were obtained from a link on the ticket at: https://osdn.net/projects/mingw/ticket/41070 That was part of the work done after Eli requested libjcc support. MSYS2 (i686-w64-mingw32) ------------------------ Running "pacman -Qs gccjit" shows: local/mingw-w64-i686-libgccjit 10.2.0-6 (mingw-w64-i686-toolchain) GNU Compiler Collection (libgccjit) for MinGW-w64 local/mingw-w64-x86_64-libgccjit 10.2.0-6 (mingw-w64-x86_64-toolchain) GNU Compiler Collection (libgccjit) for MinGW-w64 As noted in an earlier message upthread, the MSYS2 developers have stopped support for the 32bit builds. AndyM From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 17 04:04:24 2021 Received: (at 46495) by debbugs.gnu.org; 17 Feb 2021 09:04:24 +0000 Received: from localhost ([127.0.0.1]:42438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lCIky-0005Sq-Jv for submit@debbugs.gnu.org; Wed, 17 Feb 2021 04:04:24 -0500 Received: from mx.sdf.org ([205.166.94.24]:52636) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lCIku-0005Sg-TV for 46495@debbugs.gnu.org; Wed, 17 Feb 2021 04:04: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 11H94JXQ017710 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 17 Feb 2021 09:04:20 GMT From: Andrea Corallo To: Andy Moreton Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> Date: Wed, 17 Feb 2021 09:04:19 +0000 In-Reply-To: <86o8gjheaw.fsf@gmail.com> (Andy Moreton's message of "Tue, 16 Feb 2021 21:51:19 +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: 46495 Cc: 46495@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 (-) Andy Moreton writes: > On Tue 16 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: > >> Andy could you point out the two libgccjit versions you used specifying >> wich one was used in the successfull / failed experiment? > > It seems they both now fail (and I have lost the build log from the > successful experiment, so I don't have a note of the commit used). That's odd. The culprit of the bug I've isolated is a crash in libgccjit so should be easy to recognize (we should never crash in libgccjit). Anyway I've an half cooked patch to work around this issue, I guess I'll test it this evening. Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 17 13:03:31 2021 Received: (at submit) by debbugs.gnu.org; 17 Feb 2021 18:03:31 +0000 Received: from localhost ([127.0.0.1]:44845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lCRAh-00009A-1g for submit@debbugs.gnu.org; Wed, 17 Feb 2021 13:03:31 -0500 Received: from lists.gnu.org ([209.51.188.17]:60482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lCRAf-000092-JC for submit@debbugs.gnu.org; Wed, 17 Feb 2021 13:03:29 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54710) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCRAc-00073o-I0 for bug-gnu-emacs@gnu.org; Wed, 17 Feb 2021 13:03:27 -0500 Received: from mx.sdf.org ([205.166.94.24]:49241) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCRAZ-00012t-Ko for bug-gnu-emacs@gnu.org; Wed, 17 Feb 2021 13:03:26 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11HI38e9017961 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 17 Feb 2021 18:03:09 GMT From: Andrea Corallo To: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> Date: Wed, 17 Feb 2021 18:03:08 +0000 In-Reply-To: (Andrea Corallo via's message of "Wed, 17 Feb 2021 09:04:19 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Andy Moreton , 46495@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: -2.4 (--) --=-=-= Content-Type: text/plain Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Andy Moreton writes: > >> On Tue 16 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: >> >>> Andy could you point out the two libgccjit versions you used specifying >>> wich one was used in the successfull / failed experiment? >> >> It seems they both now fail (and I have lost the build log from the >> successful experiment, so I don't have a note of the commit used). > > That's odd. The culprit of the bug I've isolated is a crash in > libgccjit so should be easy to recognize (we should never crash in > libgccjit). > > Anyway I've an half cooked patch to work around this issue, I guess I'll > test it this evening. A fix like the attached is working around the GCC bug. The only annoyance of this approach is that libgccjit for each compilation is outputting to console: "libgccjit.so: note: disable pass tree-isolate-paths for functions in the range of [0, 4294967295]" We probably also want to check at configure time and raise an error in case configuring --with-nativecomp --with-wide-int but with a (really) old libgccjit that does not provide 'gcc_jit_context_add_command_line_option'. Works for me bootstraping Emacs on i686-pc-linux-gnu + GCC10 but I can't test the Windows side, Andy would you mind giving it a try? Thanks Andrea --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=46495.patch diff --git a/src/comp.c b/src/comp.c index 5e95161030..bb3cd83036 100644 --- a/src/comp.c +++ b/src/comp.c @@ -56,6 +56,7 @@ #undef gcc_jit_block_end_with_return #undef gcc_jit_block_end_with_void_return #undef gcc_jit_context_acquire +#undef gcc_jit_context_add_command_line_option #undef gcc_jit_context_add_driver_option #undef gcc_jit_context_compile_to_file #undef gcc_jit_context_dump_reproducer_to_file @@ -124,6 +125,8 @@ DEF_DLL_FN (const char *, gcc_jit_context_get_first_error, DEF_DLL_FN (gcc_jit_block *, gcc_jit_function_new_block, (gcc_jit_function *func, const char *name)); DEF_DLL_FN (gcc_jit_context *, gcc_jit_context_acquire, (void)); +DEF_DLL_FN (void, gcc_jit_context_add_command_line_option, + (gcc_jit_context *ctxt, const char *optname)); DEF_DLL_FN (void, gcc_jit_context_add_driver_option, (gcc_jit_context *ctxt, const char *optname)); DEF_DLL_FN (gcc_jit_field *, gcc_jit_context_new_field, @@ -312,6 +315,7 @@ init_gccjit_functions (void) LOAD_DLL_FN (library, gcc_jit_struct_set_fields); LOAD_DLL_FN (library, gcc_jit_type_get_const); LOAD_DLL_FN (library, gcc_jit_type_get_pointer); + LOAD_DLL_FN_OPT (library, gcc_jit_context_add_command_line_option); LOAD_DLL_FN_OPT (library, gcc_jit_context_add_driver_option); LOAD_DLL_FN_OPT (library, gcc_jit_global_set_initializer); LOAD_DLL_FN_OPT (library, gcc_jit_version_major); @@ -330,6 +334,7 @@ #define gcc_jit_block_end_with_jump fn_gcc_jit_block_end_with_jump #define gcc_jit_block_end_with_return fn_gcc_jit_block_end_with_return #define gcc_jit_block_end_with_void_return fn_gcc_jit_block_end_with_void_return #define gcc_jit_context_acquire fn_gcc_jit_context_acquire +#define gcc_jit_context_add_command_line_option fn_gcc_jit_context_add_command_line_option #define gcc_jit_context_add_driver_option fn_gcc_jit_context_add_driver_option #define gcc_jit_context_compile_to_file fn_gcc_jit_context_compile_to_file #define gcc_jit_context_dump_reproducer_to_file fn_gcc_jit_context_dump_reproducer_to_file @@ -4400,6 +4405,15 @@ DEFUN ("comp--compile-ctxt-to-file", Fcomp__compile_ctxt_to_file, if (!EQ (HASH_VALUE (func_h, i), Qunbound)) compile_function (HASH_VALUE (func_h, i)); +#if defined (WIDE_EMACS_INT) \ + && (defined (LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option) \ + || defined (WINDOWSNT)) + Lisp_Object version = Fcomp_libgccjit_version (); + if (!NILP (version) && XFIXNUM (XCAR (version)) >= 10) + gcc_jit_context_add_command_line_option (comp.ctxt, + "-fdisable-tree-isolate-paths"); +#endif + add_driver_options (); if (comp.debug) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 18 17:36:46 2021 Received: (at submit) by debbugs.gnu.org; 18 Feb 2021 22:36:46 +0000 Received: from localhost ([127.0.0.1]:48362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lCruf-0001j5-Vc for submit@debbugs.gnu.org; Thu, 18 Feb 2021 17:36:46 -0500 Received: from lists.gnu.org ([209.51.188.17]:44892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lCrue-0001iw-UR for submit@debbugs.gnu.org; Thu, 18 Feb 2021 17:36:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47874) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCrud-0004Z2-Q1 for bug-gnu-emacs@gnu.org; Thu, 18 Feb 2021 17:36:44 -0500 Received: from ciao.gmane.io ([116.202.254.214]:46080) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCruY-0001oI-0S for bug-gnu-emacs@gnu.org; Thu, 18 Feb 2021 17:36:42 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lCruS-0002yA-D7 for bug-gnu-emacs@gnu.org; Thu, 18 Feb 2021 23:36:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int Date: Thu, 18 Feb 2021 22:36:25 +0000 Message-ID: <865z2p0zrq.fsf@gmail.com> References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt) Cancel-Lock: sha1:cM6MyXC/FQmY+iKjGoQ+XoIvXs4= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.1 (/) 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: -0.9 (/) On Wed 17 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: > Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" writes: > >> Andy Moreton writes: >> >>> On Tue 16 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: >>> >>>> Andy could you point out the two libgccjit versions you used specifying >>>> wich one was used in the successfull / failed experiment? >>> >>> It seems they both now fail (and I have lost the build log from the >>> successful experiment, so I don't have a note of the commit used). >> >> That's odd. The culprit of the bug I've isolated is a crash in >> libgccjit so should be easy to recognize (we should never crash in >> libgccjit). >> >> Anyway I've an half cooked patch to work around this issue, I guess I'll >> test it this evening. > > A fix like the attached is working around the GCC bug. > > The only annoyance of this approach is that libgccjit for each > compilation is outputting to console: > "libgccjit.so: note: disable pass tree-isolate-paths for functions in the range of [0, 4294967295]" > > We probably also want to check at configure time and raise an error in > case configuring --with-nativecomp --with-wide-int but with a (really) > old libgccjit that does not provide > 'gcc_jit_context_add_command_line_option'. > > Works for me bootstraping Emacs on i686-pc-linux-gnu + GCC10 but I can't > test the Windows side, Andy would you mind giving it a try? I tried doing clean builds (after "git clean -xdf" each time ) both without and then with this patch. The i686-pc-mingw32 toolchain is: gcc version 9.2.0 (MinGW.org GCC Build-2). Without your patch, the i686-pc-mingw32 build succeeded. As I have seen some builds succeed and some fail, there is perhaps another issue to look into after this one. With your patch, the i686-pc-mingw32 build succeeded. Running the resulting emacs still produced some crashes in the async compile processes. Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 6952.0x1e8c] 0x757bff43 in KERNELBASE!DebugBreak () from C:\WINDOWS\System32\KernelBase.dll #0 0x757bff43 in KERNELBASE!DebugBreak () from C:\WINDOWS\System32\KernelBase.dll #1 0x012d2778 in emacs_abort () at c:/emacs/git/emacs/native/src/w32fns.c:10914 #2 0x0112509c in terminate_due_to_signal (sig=11, backtrace_limit=40) at c:/emacs/git/emacs/native/src/emacs.c:416 #3 0x01158fd2 in handle_fatal_signal (sig=11) at c:/emacs/git/emacs/native/src/sysdep.c:1762 #4 0x01158fac in deliver_thread_signal (sig=11, handler=0x1158fb9 ) at c:/emacs/git/emacs/native/src/sysdep.c:1754 #5 0x01159007 in deliver_fatal_thread_signal (sig=11) at c:/emacs/git/emacs/native/src/sysdep.c:1774 #6 0x010010d1 in __register_frame_info () #7 0x012d2693 in my_exception_handler (exception_data=0xbfc764) at c:/emacs/git/emacs/native/src/w32fns.c:10862 #8 0x7581e6e2 in UnhandledExceptionFilter () from C:\WINDOWS\System32\KernelBase.dll #9 0x00bfc764 in ?? () #10 0x77364c91 in ntdll!RtlCaptureStackContext () from C:\WINDOWS\SYSTEM32\ntdll.dll #11 0x77327684 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #12 0x00000000 in ?? () From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 19 09:19:50 2021 Received: (at 46495) by debbugs.gnu.org; 19 Feb 2021 14:19:50 +0000 Received: from localhost ([127.0.0.1]:49015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lD6dK-0002ZP-Ee for submit@debbugs.gnu.org; Fri, 19 Feb 2021 09:19:50 -0500 Received: from mx.sdf.org ([205.166.94.24]:54911) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lD6dJ-0002ZH-4J for 46495@debbugs.gnu.org; Fri, 19 Feb 2021 09:19:49 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11JEJmW4009770 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 19 Feb 2021 14:19:48 GMT From: Andrea Corallo To: Andy Moreton Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> Date: Fri, 19 Feb 2021 14:19:48 +0000 In-Reply-To: <865z2p0zrq.fsf@gmail.com> (Andy Moreton's message of "Thu, 18 Feb 2021 22:36:25 +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: 46495 Cc: 46495@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 (-) Andy Moreton writes: > On Wed 17 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: > >> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of >> text editors" writes: >> >>> Andy Moreton writes: >>> >>>> On Tue 16 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: >>>> >>>>> Andy could you point out the two libgccjit versions you used specifying >>>>> wich one was used in the successfull / failed experiment? >>>> >>>> It seems they both now fail (and I have lost the build log from the >>>> successful experiment, so I don't have a note of the commit used). >>> >>> That's odd. The culprit of the bug I've isolated is a crash in >>> libgccjit so should be easy to recognize (we should never crash in >>> libgccjit). >>> >>> Anyway I've an half cooked patch to work around this issue, I guess I'll >>> test it this evening. >> >> A fix like the attached is working around the GCC bug. >> >> The only annoyance of this approach is that libgccjit for each >> compilation is outputting to console: >> "libgccjit.so: note: disable pass tree-isolate-paths for functions in the range of [0, 4294967295]" >> >> We probably also want to check at configure time and raise an error in >> case configuring --with-nativecomp --with-wide-int but with a (really) >> old libgccjit that does not provide >> 'gcc_jit_context_add_command_line_option'. >> >> Works for me bootstraping Emacs on i686-pc-linux-gnu + GCC10 but I can't >> test the Windows side, Andy would you mind giving it a try? > > I tried doing clean builds (after "git clean -xdf" each time ) both > without and then with this patch. The i686-pc-mingw32 toolchain is: > gcc version 9.2.0 (MinGW.org GCC Build-2). The patch is not affecting GCC9 as initially was reported to be working. If you suspect also 9 is affected you can trivially modify the patch to take effect on 9 too. Andrea From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 19 11:01:54 2021 Received: (at submit) by debbugs.gnu.org; 19 Feb 2021 16:01:54 +0000 Received: from localhost ([127.0.0.1]:50215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lD8E6-0007bO-7q for submit@debbugs.gnu.org; Fri, 19 Feb 2021 11:01:54 -0500 Received: from lists.gnu.org ([209.51.188.17]:59406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lD8E4-0007bG-19 for submit@debbugs.gnu.org; Fri, 19 Feb 2021 11:01:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52580) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lD8E2-0001dH-74 for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2021 11:01:51 -0500 Received: from ciao.gmane.io ([116.202.254.214]:32820) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lD8Dv-0001R6-LD for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2021 11:01:44 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lD8Ds-000AUa-24 for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2021 17:01:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int Date: Fri, 19 Feb 2021 16:01:36 +0000 Message-ID: <86pn0w59nj.fsf@gmail.com> References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt) Cancel-Lock: sha1:vPJZ8BZWADLIHtKHxV/1RoCiSwg= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.1 (/) 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: -0.9 (/) On Fri 19 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: > The patch is not affecting GCC9 as initially was reported to be working. > If you suspect also 9 is affected you can trivially modify the patch to > take effect on 9 too. I tried a clean rebuild after modifying the patch to appy for gcc9. No difference - the compile processes still crash. Debugging this further will have to wait for Eli or some other interested person who uses this platform to investigate this issue. AndyM From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 19 11:07:00 2021 Received: (at 46495) by debbugs.gnu.org; 19 Feb 2021 16:07:00 +0000 Received: from localhost ([127.0.0.1]:50220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lD8J1-0007ig-UF for submit@debbugs.gnu.org; Fri, 19 Feb 2021 11:07:00 -0500 Received: from mx.sdf.org ([205.166.94.24]:62918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lD8Iy-0007iV-6x for 46495@debbugs.gnu.org; Fri, 19 Feb 2021 11:06:58 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11JG6tom022152 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 19 Feb 2021 16:06:55 GMT From: Andrea Corallo To: Andy Moreton Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> Date: Fri, 19 Feb 2021 16:06:55 +0000 In-Reply-To: <86pn0w59nj.fsf@gmail.com> (Andy Moreton's message of "Fri, 19 Feb 2021 16:01:36 +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: 46495 Cc: 46495@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 (-) Andy Moreton writes: > On Fri 19 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: > >> The patch is not affecting GCC9 as initially was reported to be working. >> If you suspect also 9 is affected you can trivially modify the patch to >> take effect on 9 too. > > I tried a clean rebuild after modifying the patch to appy for gcc9. > No difference - the compile processes still crash. > > Debugging this further will have to wait for Eli or some other > interested person who uses this platform to investigate this issue. Agree. BTW it might be as well that a new bug was introduced with the recent changes, I'll have another 32bit wide-int try in the weekend. Andrea From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 19 12:01:00 2021 Received: (at 46495) by debbugs.gnu.org; 19 Feb 2021 17:01:00 +0000 Received: from localhost ([127.0.0.1]:50299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lD99I-0000f4-3V for submit@debbugs.gnu.org; Fri, 19 Feb 2021 12:01:00 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lD99G-0000eq-6c for 46495@debbugs.gnu.org; Fri, 19 Feb 2021 12:00:59 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52621) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lD999-0002Hh-Qb; Fri, 19 Feb 2021 12:00:52 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2757 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lD994-0003Yd-23; Fri, 19 Feb 2021 12:00:48 -0500 Date: Fri, 19 Feb 2021 19:01:00 +0200 Message-Id: <83zh000z77.fsf@gnu.org> From: Eli Zaretskii To: Andy Moreton In-Reply-To: <86pn0w59nj.fsf@gmail.com> (message from Andy Moreton on Fri, 19 Feb 2021 16:01:36 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: 46495@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.7 (-) > From: Andy Moreton > Date: Fri, 19 Feb 2021 16:01:36 +0000 > > Debugging this further will have to wait for Eli or some other > interested person who uses this platform to investigate this issue. Didn't you say the crashes didn't happen with mingw.org's libgccjit? Or did they start happening recently? From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 19 12:40:07 2021 Received: (at submit) by debbugs.gnu.org; 19 Feb 2021 17:40:07 +0000 Received: from localhost ([127.0.0.1]:50315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lD9l9-0001ZE-JD for submit@debbugs.gnu.org; Fri, 19 Feb 2021 12:40:07 -0500 Received: from lists.gnu.org ([209.51.188.17]:39228) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lD9l7-0001Z3-Ng for submit@debbugs.gnu.org; Fri, 19 Feb 2021 12:40:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49762) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lD9l6-0003ax-UZ for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2021 12:40:05 -0500 Received: from ciao.gmane.io ([116.202.254.214]:40214) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lD9l5-0005p9-JB for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2021 12:40:04 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lD9l3-0002vk-P4 for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2021 18:40:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int Date: Fri, 19 Feb 2021 17:35:46 +0000 Message-ID: <86eehc55al.fsf@gmail.com> References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83zh000z77.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt) Cancel-Lock: sha1:UL4iocESPzRph4xXQ5SFqXKFF+I= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.1 (/) 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: -0.9 (/) On Fri 19 Feb 2021, Eli Zaretskii wrote: >> From: Andy Moreton >> Date: Fri, 19 Feb 2021 16:01:36 +0000 >> >> Debugging this further will have to wait for Eli or some other >> interested person who uses this platform to investigate this issue. > > Didn't you say the crashes didn't happen with mingw.org's libgccjit? > Or did they start happening recently? Originally I thought that mingw.org's libgccjit was working, but later builds showed that not to be true. AndyM From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 19 14:36:26 2021 Received: (at 46495) by debbugs.gnu.org; 19 Feb 2021 19:36:26 +0000 Received: from localhost ([127.0.0.1]:50412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDBZi-0004Mi-7s for submit@debbugs.gnu.org; Fri, 19 Feb 2021 14:36:26 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55248) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDBZc-0004MR-PT for 46495@debbugs.gnu.org; Fri, 19 Feb 2021 14:36:24 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56518) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDBZX-0000FU-EN; Fri, 19 Feb 2021 14:36:15 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4339 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lDBZW-0003Es-RO; Fri, 19 Feb 2021 14:36:15 -0500 Date: Fri, 19 Feb 2021 21:36:29 +0200 Message-Id: <83r1lb26ki.fsf@gnu.org> From: Eli Zaretskii To: Andy Moreton In-Reply-To: <86eehc55al.fsf@gmail.com> (message from Andy Moreton on Fri, 19 Feb 2021 17:35:46 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83zh000z77.fsf@gnu.org> <86eehc55al.fsf@gmail.com> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: 46495@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.7 (-) > From: Andy Moreton > Date: Fri, 19 Feb 2021 17:35:46 +0000 > > > Didn't you say the crashes didn't happen with mingw.org's libgccjit? > > Or did they start happening recently? > > Originally I thought that mingw.org's libgccjit was working, but later > builds showed that not to be true. I see, thanks. Btw, one other way of getting GDB attach to the crashing program "just in time" is to use the Windows AeDebug support in GDB. It is described in the node "Cygwin Native" in the GDB manual, under "signal-event ID". From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 19 17:07:33 2021 Received: (at 46495) by debbugs.gnu.org; 19 Feb 2021 22:07:33 +0000 Received: from localhost ([127.0.0.1]:50559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDDvx-00080b-7x for submit@debbugs.gnu.org; Fri, 19 Feb 2021 17:07:33 -0500 Received: from mx.sdf.org ([205.166.94.24]:54189) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDDvv-00080T-Cs for 46495@debbugs.gnu.org; Fri, 19 Feb 2021 17:07:31 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11JM7UZa016576 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 19 Feb 2021 22:07:30 GMT From: Andrea Corallo To: Andy Moreton Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> Date: Fri, 19 Feb 2021 22:07:30 +0000 In-Reply-To: <86pn0w59nj.fsf@gmail.com> (Andy Moreton's message of "Fri, 19 Feb 2021 16:01:36 +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: 46495 Cc: 46495@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 (-) Andy Moreton writes: > On Fri 19 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: > >> The patch is not affecting GCC9 as initially was reported to be working. >> If you suspect also 9 is affected you can trivially modify the patch to >> take effect on 9 too. > > I tried a clean rebuild after modifying the patch to appy for gcc9. > No difference - the compile processes still crash. > > Debugging this further will have to wait for Eli or some other > interested person who uses this platform to investigate this issue. > > AndyM So with 39792cf629 I've pushed the work-around limiting it to GCC10 (as in trunk is freshly fixed). I tried again to bootstrap on 32bit wide-int and it works. The compiler testsuite is segfaulting for me... so I guess I'll have something more to debug. This might be the reason of the problem you are observing. I'll follow-up on this. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 26 06:18:59 2021 Received: (at 46495) by debbugs.gnu.org; 26 Mar 2021 10:18:59 +0000 Received: from localhost ([127.0.0.1]:40503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPjYQ-0001Bg-OZ for submit@debbugs.gnu.org; Fri, 26 Mar 2021 06:18:59 -0400 Received: from mx.sdf.org ([205.166.94.24]:60449) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPjYP-0001BY-2i for 46495@debbugs.gnu.org; Fri, 26 Mar 2021 06:18:57 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12QAItcc008602 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 26 Mar 2021 10:18:55 GMT From: Andrea Corallo To: Andy Moreton Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> Date: Fri, 26 Mar 2021 10:18:55 +0000 In-Reply-To: (Andrea Corallo's message of "Fri, 19 Feb 2021 22:07:30 +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: 46495 Cc: 46495@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 (-) Andrea Corallo writes: > Andy Moreton writes: > >> On Fri 19 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: >> >>> The patch is not affecting GCC9 as initially was reported to be working. >>> If you suspect also 9 is affected you can trivially modify the patch to >>> take effect on 9 too. >> >> I tried a clean rebuild after modifying the patch to appy for gcc9. >> No difference - the compile processes still crash. >> >> Debugging this further will have to wait for Eli or some other >> interested person who uses this platform to investigate this issue. >> >> AndyM > > So with 39792cf629 I've pushed the work-around limiting it to GCC10 (as > in trunk is freshly fixed). > > I tried again to bootstrap on 32bit wide-int and it works. > > The compiler testsuite is segfaulting for me... so I guess I'll have > something more to debug. This might be the reason of the problem you > are observing. I'll follow-up on this. I've tested now the current branch c6c7b30e4b compiling 32bit --with-wide-int. I have the impression that all 32bit --with-wide-int specific issues have been solved here or in the other related threads. All the compiler testsuite is running clean for me and I think we should classify the segfault Eli observed running `comp-tests-bootstrap' as a libgccjit bug specific to that version (libgccjit should *never* crash and if does it's a bug in the library). Eli, how do you find the current branch stability on 32bit wide-int? Is there anything left we should look into for this bug? Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 26 07:27:30 2021 Received: (at 46495) by debbugs.gnu.org; 26 Mar 2021 11:27:30 +0000 Received: from localhost ([127.0.0.1]:40526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPkck-0002zE-75 for submit@debbugs.gnu.org; Fri, 26 Mar 2021 07:27:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48554) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPkci-0002yx-Rq for 46495@debbugs.gnu.org; Fri, 26 Mar 2021 07:27:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56913) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPkcd-0005ZN-HS; Fri, 26 Mar 2021 07:27:23 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1902 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lPkcZ-00023g-P8; Fri, 26 Mar 2021 07:27:23 -0400 Date: Fri, 26 Mar 2021 14:27:21 +0300 Message-Id: <83y2eap33a.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, 46495@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.7 (-) > Cc: 46495@debbugs.gnu.org > Date: Fri, 26 Mar 2021 10:18:55 +0000 > From: Andrea Corallo via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Eli, how do you find the current branch stability on 32bit wide-int? It looks in good shape, AFAICT. One issue left, which I'm pursuing locally, is the one with strange gaps in the C backtraces. You can see the traces of that on the gdb-patches mailing list. When I finish that investigation, hopefully next week, we will be able to see whether this is some bug in the native-comp branch or just lack of debug info; in the latter case I will probably ask for changing the default debug-level in comp.el, at least on MS-Windows. Stay tuned. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 26 09:10:53 2021 Received: (at 46495) by debbugs.gnu.org; 26 Mar 2021 13:10:53 +0000 Received: from localhost ([127.0.0.1]:40614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPmEn-0003QR-L1 for submit@debbugs.gnu.org; Fri, 26 Mar 2021 09:10:53 -0400 Received: from mx.sdf.org ([205.166.94.24]:61956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPmEl-0003QG-Ex for 46495@debbugs.gnu.org; Fri, 26 Mar 2021 09:10:51 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12QDAnkK016026 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 26 Mar 2021 13:10:50 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> Date: Fri, 26 Mar 2021 13:10:49 +0000 In-Reply-To: <83y2eap33a.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Mar 2021 14:27:21 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, 46495@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 (-) Eli Zaretskii writes: >> Cc: 46495@debbugs.gnu.org >> Date: Fri, 26 Mar 2021 10:18:55 +0000 >> From: Andrea Corallo via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> Eli, how do you find the current branch stability on 32bit wide-int? > > It looks in good shape, AFAICT. Very nice. > One issue left, which I'm pursuing locally, is the one with strange > gaps in the C backtraces. You can see the traces of that on the > gdb-patches mailing list. When I finish that investigation, hopefully > next week, we will be able to see whether this is some bug in the > native-comp branch or just lack of debug info; in the latter case I > will probably ask for changing the default debug-level in comp.el, at > least on MS-Windows. > > Stay tuned. Sure, I've seen some of that (interesting reading), thanks for looking into this. Andrea From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 29 11:55:45 2021 Received: (at 46495) by debbugs.gnu.org; 29 Mar 2021 15:55:46 +0000 Received: from localhost ([127.0.0.1]:49374 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQuEz-0002bR-K1 for submit@debbugs.gnu.org; Mon, 29 Mar 2021 11:55:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQuEw-0002aX-SI for 46495@debbugs.gnu.org; Mon, 29 Mar 2021 11:55:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46741) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lQuEq-0004us-Nk; Mon, 29 Mar 2021 11:55:36 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4966 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lQuEb-0007MV-Ea; Mon, 29 Mar 2021 11:55:33 -0400 Date: Mon, 29 Mar 2021 18:55:31 +0300 Message-Id: <83lfa6kl8s.fsf@gnu.org> From: Eli Zaretskii To: akrl@sdf.org In-Reply-To: <83y2eap33a.fsf@gnu.org> (message from Eli Zaretskii on Fri, 26 Mar 2021 14:27:21 +0300) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, 46495@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.7 (-) > Date: Fri, 26 Mar 2021 14:27:21 +0300 > From: Eli Zaretskii > Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > > One issue left, which I'm pursuing locally, is the one with strange > gaps in the C backtraces. You can see the traces of that on the > gdb-patches mailing list. The GDB experts seem to indicate that the prologue of functions we produce is different from the prologue normally produced by GCC from C code on x86. See https://sourceware.org/pipermail/gdb-patches/2021-March/177334.html Is that possible? are we doing something that could affect the prologue of the natively-compiled Lisp code? From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 29 12:16:03 2021 Received: (at 46495) by debbugs.gnu.org; 29 Mar 2021 16:16:04 +0000 Received: from localhost ([127.0.0.1]:49403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQuYd-0003Aa-8l for submit@debbugs.gnu.org; Mon, 29 Mar 2021 12:16:03 -0400 Received: from mx.sdf.org ([205.166.94.24]:50966) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQuYY-00039v-DM for 46495@debbugs.gnu.org; Mon, 29 Mar 2021 12:16:01 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12TGFukp018355 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 29 Mar 2021 16:15:57 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> Date: Mon, 29 Mar 2021 16:15:56 +0000 In-Reply-To: <83lfa6kl8s.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 29 Mar 2021 18:55:31 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, 46495@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 (-) Eli Zaretskii writes: >> Date: Fri, 26 Mar 2021 14:27:21 +0300 >> From: Eli Zaretskii >> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >> >> One issue left, which I'm pursuing locally, is the one with strange >> gaps in the C backtraces. You can see the traces of that on the >> gdb-patches mailing list. > > The GDB experts seem to indicate that the prologue of functions we > produce is different from the prologue normally produced by GCC from C > code on x86. See > > https://sourceware.org/pipermail/gdb-patches/2021-March/177334.html > > Is that possible? Well if this is what you observe it certainly can be. There might very well be something in how/what libgccjit generates that is causing this difference. > are we doing something that could affect the > prologue of the natively-compiled Lisp code? I suspect this is a libgccjit thing, without knowing where the difference is coming from it's hard to predict if there's a workaround we can put in place in the Emacs codebase, but I suspect there's not. If the generated code is correct I think gdb should recognize it improving its unwinder, otherwise if this is a libgccjit bug we should open a PR on bugzilla. Perhaps if the case is the later one can try a simpler testcase to report it using the test we have in the configure or libgccjit hello world [1]. This might help also analysing how this different frame is formed. Thanks Andrea [1] From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 29 12:59:18 2021 Received: (at 46495) by debbugs.gnu.org; 29 Mar 2021 16:59:18 +0000 Received: from localhost ([127.0.0.1]:49470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQvEU-0004Hk-EJ for submit@debbugs.gnu.org; Mon, 29 Mar 2021 12:59:18 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQvEQ-0004HV-RX for 46495@debbugs.gnu.org; Mon, 29 Mar 2021 12:59:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48094) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lQvEK-0000RJ-Az; Mon, 29 Mar 2021 12:59:08 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4933 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lQvEI-0003Rs-DD; Mon, 29 Mar 2021 12:59:07 -0400 Date: Mon, 29 Mar 2021 19:59:17 +0300 Message-Id: <83h7ktlwuy.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo , David Malcolm In-Reply-To: (message from Andrea Corallo on Mon, 29 Mar 2021 16:15:56 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > Date: Mon, 29 Mar 2021 16:15:56 +0000 > > > https://sourceware.org/pipermail/gdb-patches/2021-March/177334.html > > > > Is that possible? > > Well if this is what you observe it certainly can be. There might very > well be something in how/what libgccjit generates that is causing this > difference. David, can you please chime in and help us understand what is going on here? > > are we doing something that could affect the > > prologue of the natively-compiled Lisp code? > > I suspect this is a libgccjit thing, without knowing where the > difference is coming from it's hard to predict if there's a workaround > we can put in place in the Emacs codebase, but I suspect there's not. > > If the generated code is correct I think gdb should recognize it > improving its unwinder, otherwise if this is a libgccjit bug we should > open a PR on bugzilla. GDB's native platform is ELF-based, so its unwinders' support for COFF-PE format used by MS-Windows is known to be less thorough. > Perhaps if the case is the later one can try a simpler testcase to > report it using the test we have in the configure or libgccjit hello > world [1]. This might help also analysing how this different frame is > formed. I think if David doesn't show us the light, my best bet is to recompile the Lisp code with debug info and see if that resolves the problem and/or allows us to understand why the code with no debug info produces these effects. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 29 14:11:42 2021 Received: (at 46495) by debbugs.gnu.org; 29 Mar 2021 18:11:42 +0000 Received: from localhost ([127.0.0.1]:49536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQwMY-000891-FW for submit@debbugs.gnu.org; Mon, 29 Mar 2021 14:11:42 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:43294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQwMU-00088s-WE for 46495@debbugs.gnu.org; Mon, 29 Mar 2021 14:11:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617041498; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pnLlF6HJHRpMwr+XtS3yHKhjHhk0WtaZrZdTd/yIWx4=; b=EVtdQ041nMqVOs1fxGNA/wgeoMpuwBVEwMQ8VR5bKfyku0QZNizCg0l1z67dRLiGJGnaqr v3iMrN6cu4JWQG5Cvj5kboi5AkqY6MAD7bUlpiWlLvNf4d/bfq/6B3MbgloekvIclSK2wS R+Qzi+Fw5IZX/icXGiNGjF4bD8kvI7Y= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-535-0nXoI3n0P4OYvsMWLhAlHg-1; Mon, 29 Mar 2021 14:11:34 -0400 X-MC-Unique: 0nXoI3n0P4OYvsMWLhAlHg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5370E802B4F; Mon, 29 Mar 2021 18:11:33 +0000 (UTC) Received: from t14s.localdomain (ovpn-112-18.phx2.redhat.com [10.3.112.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id B95095D9F0; Mon, 29 Mar 2021 18:11:32 +0000 (UTC) Message-ID: <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int From: David Malcolm To: Eli Zaretskii , Andrea Corallo Date: Mon, 29 Mar 2021 14:11:28 -0400 In-Reply-To: <83h7ktlwuy.fsf@gnu.org> References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> User-Agent: Evolution 3.38.3 (3.38.3-1.fc33) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmalcolm@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, 46495@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.7 (-) On Mon, 2021-03-29 at 19:59 +0300, Eli Zaretskii wrote: > > From: Andrea Corallo > > Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > > Date: Mon, 29 Mar 2021 16:15:56 +0000 > > > > >   > > > https://sourceware.org/pipermail/gdb-patches/2021-March/177334.html > > > > > > Is that possible? > > > > Well if this is what you observe it certainly can be.  There might > > very > > well be something in how/what libgccjit generates that is causing > > this > > difference. > > David, can you please chime in and help us understand what is going > on > here? In theory, libgccjit uses the same code-generation code and the same debuginfo-generation code as a regular gcc invocation. Some ideas: (a) Is libgccjit being invoked multiple times in-process? If so, I wonder if you're running into a latent bug in state-handling in libgccjit that's affecting either code generation or debuginfo generation. Maybe something isn't being reset that should have been? Is there a way to get emacs to only do one libgccjit context compilation per process, and see if that affects things? (b) Alternatively, maybe a simple bug in libgccjit that affects the first in-process invocation? (c) Alternatively, maybe a bug in the emacs jit stuff that's corrupting the stack somehow? Some debugging hooks are here: https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#debugging > > > are we doing something that could affect the > > > prologue of the natively-compiled Lisp code? > > > > I suspect this is a libgccjit thing, without knowing where the > > difference is coming from it's hard to predict if there's a > > workaround > > we can put in place in the Emacs codebase, but I suspect there's > > not. > > > > If the generated code is correct I think gdb should recognize it > > improving its unwinder, otherwise if this is a libgccjit bug we > > should > > open a PR on bugzilla. In particular, this may be helpful for that: https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#c.gcc_jit_context_dump_reproducer_to_file > GDB's native platform is ELF-based, so its unwinders' support for > COFF-PE format used by MS-Windows is known to be less thorough. > > > Perhaps if the case is the later one can try a simpler testcase to > > report it using the test we have in the configure or libgccjit > > hello > > world [1].  This might help also analysing how this different frame > > is > > formed. > > I think if David doesn't show us the light, my best bet is to > recompile the Lisp code with debug info and see if that resolves the > problem and/or allows us to understand why the code with no debug > info > produces these effects. I'd try turning on debuginfo generation to see if that helps. Hope this is helpful Dave From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 29 16:46:32 2021 Received: (at 46495) by debbugs.gnu.org; 29 Mar 2021 20:46:32 +0000 Received: from localhost ([127.0.0.1]:49728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQymN-0005Yh-OV for submit@debbugs.gnu.org; Mon, 29 Mar 2021 16:46:32 -0400 Received: from mx.sdf.org ([205.166.94.24]:54879) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQymK-0005YY-P7 for 46495@debbugs.gnu.org; Mon, 29 Mar 2021 16:46:30 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12TKkRqR023921 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 29 Mar 2021 20:46:27 GMT From: Andrea Corallo To: David Malcolm Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> Date: Mon, 29 Mar 2021 20:46:27 +0000 In-Reply-To: <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> (David Malcolm's message of "Mon, 29 Mar 2021 14:11:28 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46495 Cc: Eli Zaretskii , andrewjmoreton@gmail.com, 46495@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 (-) David Malcolm writes: > On Mon, 2021-03-29 at 19:59 +0300, Eli Zaretskii wrote: >> > From: Andrea Corallo >> > Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >> > Date: Mon, 29 Mar 2021 16:15:56 +0000 >> >=20 >> > > =C2=A0=20 >> > > https://sourceware.org/pipermail/gdb-patches/2021-March/177334.html >> > >=20 >> > > Is that possible? >> >=20 >> > Well if this is what you observe it certainly can be.=C2=A0 There might >> > very >> > well be something in how/what libgccjit generates that is causing >> > this >> > difference. >>=20 >> David, can you please chime in and help us understand what is going >> on >> here? > > In theory, libgccjit uses the same code-generation code and the same > debuginfo-generation code as a regular gcc invocation. > > Some ideas: > > (a) Is libgccjit being invoked multiple times in-process? > If so, I wonder if you're running into a latent bug in state-handling > in libgccjit that's affecting either code generation or debuginfo > generation. Maybe something isn't being reset that should have been? > > Is there a way to get emacs to only do one libgccjit context > compilation per process, and see if that affects things? Hi Dave, libgccjit here is invoked once. > (b) Alternatively, maybe a simple bug in libgccjit that affects the > first in-process invocation? Shouldn't this likely affect configurations other than Windows i386? > (c) Alternatively, maybe a bug in the emacs jit stuff that's corrupting > the stack somehow? I think as suggested compiling a simple function on Eli's system like the hello word may give a strong indication on if this is Emacs related or not. Regards Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 30 03:50:05 2021 Received: (at 46495) by debbugs.gnu.org; 30 Mar 2021 07:50:05 +0000 Received: from localhost ([127.0.0.1]:50309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lR98W-0003Cv-L0 for submit@debbugs.gnu.org; Tue, 30 Mar 2021 03:50:05 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46160) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lR98T-0003CJ-B6 for 46495@debbugs.gnu.org; Tue, 30 Mar 2021 03:50:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:32993) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lR98M-0000cJ-So; Tue, 30 Mar 2021 03:49:54 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4181 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lR98M-0002K6-50; Tue, 30 Mar 2021 03:49:54 -0400 Date: Tue, 30 Mar 2021 10:50:05 +0300 Message-Id: <837dlpkrma.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Mon, 29 Mar 2021 20:46:27 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: Eli Zaretskii , andrewjmoreton@gmail.com, > 46495@debbugs.gnu.org > Date: Mon, 29 Mar 2021 20:46:27 +0000 > > > (c) Alternatively, maybe a bug in the emacs jit stuff that's corrupting > > the stack somehow? > > I think as suggested compiling a simple function on Eli's system like > the hello word may give a strong indication on if this is Emacs related > or not. I have the hello world example from the libgccjit tutorial compiled here, but I'm not sure what would you like me to test there. Here's what I did: . compiled the example with -gdwarf-4 -g3 . started GDB and ran the program until it calls the 'greet' function . used "si" and "ni" commands to step into 'greet' and through the functions it calls The below is the transcript of that GDB session. Note how a valid backtrace sometimes become incomplete and uses "??" for some functions that are correctly identified by their names at other times. Does this provide the evidence you wanted to see? Does it mean that GDB is sometimes unable to determine the beginning of libgccjit generated functions, at least on MS-Windows? D:\usr\eli\libgccjit>gdb ./tut01-hello-world_d.exe GNU gdb (GDB) 10.1 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-mingw32". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./tut01-hello-world_d.exe... (gdb) start Temporary breakpoint 1 at 0x4015c2: file tut01-hello-world.c, line 81. Starting program: D:\usr\eli\libgccjit\tut01-hello-world_d.exe Temporary breakpoint 1, main (argc=1, argv=0x3e2978) at tut01-hello-world.c:81 81 ctxt = gcc_jit_context_acquire (); (gdb) until 117 main (argc=1, argv=0x3e2978) at tut01-hello-world.c:117 117 greet ("world"); (gdb) si 0x004016d3 117 greet ("world"); (gdb) 0x004016d7 117 greet ("world"); (gdb) 0x66a41280 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so (gdb) bt #0 0x66a41280 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so #1 0x004016d9 in main (argc=1, argv=0x3e2978) at tut01-hello-world.c:117 (gdb) ni 0x66a41281 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so (gdb) 0x66a41283 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so (gdb) si 0x66a41286 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so (gdb) si 0x66a41289 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so (gdb) si 0x66a4128d in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so (gdb) si 0x66a41294 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so (gdb) 0x66a41ad8 in printf () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so (gdb) bt #0 0x66a41ad8 in printf () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so #1 0x66a41299 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so #2 0x004016d9 in main (argc=1, argv=0x3e2978) at tut01-hello-world.c:117 (gdb) si 0x77c4186a in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c4186c in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c41871 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c37420 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c37425 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3742b in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3742c in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c37430 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c37434 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c37438 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3743a in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3743b in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3743c in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3743d in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c37440 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c37443 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c37444 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) bt #0 0x77c37444 in strerror () from C:\WINDOWS\system32\msvcrt.dll #1 0x66a41299 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so #2 0x004016d9 in main (argc=1, argv=0x3e2978) at tut01-hello-world.c:117 (gdb) si 0x77c37447 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3744e in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c37451 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c37454 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3745a in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c41876 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c4187b in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c4187c in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c4187e in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3b914 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3b916 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3b917 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3b919 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3b91c in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3b91f in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3b921 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) bt #0 0x77c3b921 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll #1 0x77c41883 in printf () from C:\WINDOWS\system32\msvcrt.dll #2 0x00000001 in ?? () #3 0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll #4 0x00000000 in ?? () (gdb) si 0x77c3b924 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3b925 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3a5bb in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3a5bd in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3a5be in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3a5c0 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3a5c3 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3a5c4 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3a5cb in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3a5ce in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3a5e3 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x77c3a5e5 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) si 0x7c901000 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) bt #0 0x7c901000 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll #1 0x77c3a5eb in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll #2 0x77c3b92a in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll #3 0x77c41883 in printf () from C:\WINDOWS\system32\msvcrt.dll #4 0x00000001 in ?? () #5 0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll #6 0x00000000 in ?? () (gdb) ni 0x7c901007 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c90100b in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c90100f in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c901060 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c901063 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c901066 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c901080 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c901083 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c901088 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c90108d in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c901092 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c901094 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c901097 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c90109e in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c9010a1 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c9010a4 in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c9010ab in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x7c9010ad in ntdll!RtlEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) ni 0x77c3a5eb in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) bt #0 0x77c3a5eb in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll #1 0x77c3b92a in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll #2 0x77c41883 in printf () from C:\WINDOWS\system32\msvcrt.dll #3 0x00000001 in ?? () #4 0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll #5 0x00000000 in ?? () (gdb) ni 0x77c3a5ec in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c3a5ed in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c3b92a in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) bt #0 0x77c3b92a in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll #1 0x77c41883 in printf () from C:\WINDOWS\system32\msvcrt.dll #2 0x00000001 in ?? () #3 0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll #4 0x00000000 in ?? () (gdb) ni 0x77c3b92b in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c3b92c in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c41883 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) bt #0 0x77c41883 in printf () from C:\WINDOWS\system32\msvcrt.dll #1 0x00000001 in ?? () #2 0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll #3 0x00000000 in ?? () (gdb) ni 0x77c41884 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c41885 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c41889 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c4188a in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c4188f in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) bt #0 0x77c4188f in printf () from C:\WINDOWS\system32\msvcrt.dll #1 0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll #2 0x00000000 in ?? () (gdb) ni 0x77c41892 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c41895 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c41896 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c41899 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c4189a in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c4189f in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c418a2 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c418a3 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c418a6 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni hello world 0x77c418ab in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) bt #0 0x77c418ab in printf () from C:\WINDOWS\system32\msvcrt.dll #1 0x00000001 in ?? () #2 0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll #3 0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll #4 0x66a43044 in ?? () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so #5 0x66a41299 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so #6 0x004016d9 in main (argc=1, argv=0x3e2978) at tut01-hello-world.c:117 (gdb) ni 0x77c418ae in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c418b2 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c418b7 in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c418ba in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c3745b in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) bt #0 0x77c3745b in strerror () from C:\WINDOWS\system32\msvcrt.dll #1 0x66a41299 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so #2 0x004016d9 in main (argc=1, argv=0x3e2978) at tut01-hello-world.c:117 (gdb) ni 0x77c3745e in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c37465 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c37466 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c37467 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c37468 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c37469 in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c3746a in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c3746b in strerror () from C:\WINDOWS\system32\msvcrt.dll (gdb) ni 0x77c418bf in printf () from C:\WINDOWS\system32\msvcrt.dll (gdb) bt #0 0x77c418bf in printf () from C:\WINDOWS\system32\msvcrt.dll #1 0x66a41299 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so #2 0x004016d9 in main (argc=1, argv=0x3e2978) at tut01-hello-world.c:117 (gdb) ni 0x66a41299 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so (gdb) bt #0 0x66a41299 in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so #1 0x004016d9 in main (argc=1, argv=0x3e2978) at tut01-hello-world.c:117 (gdb) ni 0x66a4129a in greet () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-wf9bcr\fake.so (gdb) ni main (argc=1, argv=0x3e2978) at tut01-hello-world.c:118 118 fflush (stdout); (gdb) bt #0 main (argc=1, argv=0x3e2978) at tut01-hello-world.c:118 (gdb) c Continuing. [Inferior 1 (process 7076) exited normally] (gdb) From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 30 05:06:39 2021 Received: (at 46495) by debbugs.gnu.org; 30 Mar 2021 09:06:39 +0000 Received: from localhost ([127.0.0.1]:50393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRAKd-0005ID-9J for submit@debbugs.gnu.org; Tue, 30 Mar 2021 05:06:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRAKZ-0005Hw-4J for 46495@debbugs.gnu.org; Tue, 30 Mar 2021 05:06:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33892) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRAKT-0004HW-9G; Tue, 30 Mar 2021 05:06:29 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4948 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRAKS-0003UU-AE; Tue, 30 Mar 2021 05:06:28 -0400 Date: Tue, 30 Mar 2021 12:06:38 +0300 Message-Id: <834kgtko2p.fsf@gnu.org> From: Eli Zaretskii To: dmalcolm@redhat.com In-Reply-To: <837dlpkrma.fsf@gnu.org> (message from Eli Zaretskii on Tue, 30 Mar 2021 10:50:05 +0300) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <837dlpkrma.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: 46495@debbugs.gnu.org, andrewjmoreton@gmail.com, akrl@sdf.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.7 (-) > Date: Tue, 30 Mar 2021 10:50:05 +0300 > From: Eli Zaretskii > Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org > > Here's what I did: > > . compiled the example with -gdwarf-4 -g3 > . started GDB and ran the program until it calls the 'greet' > function > . used "si" and "ni" commands to step into 'greet' and through the > functions it calls I have now compiled a slightly modified version of the hello world example, after adding this to the source: gcc_jit_context_set_bool_option ( ctxt, GCC_JIT_BOOL_OPTION_DEBUGINFO, 1); The results under debugger are slightly better, for example, the arguments to JIT functions are shown: (gdb) bt #0 0x6ac81280 in greet (name=0x406088 "world") from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-0z6iua\fake.so However, the "??" thingies and the incomplete backtraces are still present, here are two examples: #0 0x77c418ab in printf () from C:\WINDOWS\system32\msvcrt.dll #1 0x00000001 in ?? () #2 0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll #3 0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll #4 0x6ac83044 in ?? () from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-0z6iua\fake.so #5 0x6ac81299 in greet (name=0x406088 "world") from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-0z6iua\fake.so #6 0x004016f5 in main (argc=1, argv=0x3e2978) at tut01d-hello-world.c:121 #0 0x77c41883 in printf () from C:\WINDOWS\system32\msvcrt.dll #1 0x00000001 in ?? () #2 0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll #3 0x00000000 in ?? () This is quite disappointing. It probably means that debugging Emacs with natively-compiled Lisp will be much harder on MS-Windows, if you happen to be in a situation (whose causes are still unclear to me, probably some minor variations of the prologue code?) with these incomplete backtraces. I also have 3 followup questions: 1) When GCC_JIT_BOOL_OPTION_DEBUGINFO is used, what kind of debug info is generated by libgccjit? is it DWARF2 or stabs or something else? Using "objdump -W", it looks like DWARF2, but if so, why isn't GDB able to produce a decent backtrace? 2) If the debug info created under GCC_JIT_BOOL_OPTION_DEBUGINFO is not DWARF2, is it possible to use gcc_jit_context_add_command_line_option to request "-gdwarf-4" or similar, like we do with the command-line GCC, so that the debug info for the JIT code is more detailed and accurate? 3) I see in my temporary directory subdirectories, created when I run the example program, with files fake.s and fake.so. Are they supposed to be left there, or are they supposed to be deleted when the program exits? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 30 05:22:42 2021 Received: (at 46495) by debbugs.gnu.org; 30 Mar 2021 09:22:42 +0000 Received: from localhost ([127.0.0.1]:50408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRAaA-0005gr-Im for submit@debbugs.gnu.org; Tue, 30 Mar 2021 05:22:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRAa7-0005ga-Tl for 46495@debbugs.gnu.org; Tue, 30 Mar 2021 05:22:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34056) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRAa2-0005kL-CC; Tue, 30 Mar 2021 05:22:34 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1962 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRAa1-0006O3-1a; Tue, 30 Mar 2021 05:22:34 -0400 Date: Tue, 30 Mar 2021 12:22:43 +0300 Message-Id: <8335wdknbw.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Mon, 29 Mar 2021 20:46:27 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) Andrea, if I want to recompile the Lisp files with comp-debug set to 1, is there a better way than removing the existing *.eln files, then compiling them again with a command such as (for preloaded files): emacs -batch -l comp -eval "(setq comp-debug 1)" -f batch-byte-native-compile-for-bootstrap FILE and for non-preloaded ones: emacs -batch -l comp -eval "(setq comp-debug 1)" -f batch-native-compile FILE Is that the right procedure? And another question: if the preloaded files are recompiled as above, do I also need to re-dump Emacs, or will the existing emacs.pdmp still be valid for running Emacs? And finally, in what directory will the pseudo C code files be dumped, when using comp-debug = 1? in the same directory as the corresponding .eln files, or somewhere else? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 30 10:33:10 2021 Received: (at 46495) by debbugs.gnu.org; 30 Mar 2021 14:33:10 +0000 Received: from localhost ([127.0.0.1]:52514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRFQc-0001Kp-4z for submit@debbugs.gnu.org; Tue, 30 Mar 2021 10:33:10 -0400 Received: from mx.sdf.org ([205.166.94.24]:56152) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRFQY-0001Kc-C7 for 46495@debbugs.gnu.org; Tue, 30 Mar 2021 10:33:08 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12UEX47j005307 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 30 Mar 2021 14:33:05 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> Date: Tue, 30 Mar 2021 14:33:04 +0000 In-Reply-To: <8335wdknbw.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 Mar 2021 12:22:43 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Eli Zaretskii writes: > Andrea, if I want to recompile the Lisp files with comp-debug set to > 1, is there a better way than removing the existing *.eln files, then > compiling them again with a command such as (for preloaded files): > > emacs -batch -l comp -eval "(setq comp-debug 1)" -f batch-byte-native-compile-for-bootstrap FILE > > and for non-preloaded ones: > > emacs -batch -l comp -eval "(setq comp-debug 1)" -f batch-native-compile FILE > > Is that the right procedure? Removing the .eln should not be necessary, thinking about actually if it's removed I guess emacs will not be able to start and recompile the file as not able to resurrect from dump. `batch-native-compile' or `batch-byte-native-compile-for-bootstrap' should be equivalent here as the second is just a way to do only byte compilation for non dumped files when we are not using NATIVE_FULL_AOT. > And another question: if the preloaded files are recompiled as above, > do I also need to re-dump Emacs, or will the existing emacs.pdmp still > be valid for running Emacs? Dump is needed if the .eln file changes position or content (compiled functions) so generally speaking yes, redumping is a good idea. > And finally, in what directory will the pseudo C code files be dumped, > when using comp-debug = 1? in the same directory as the corresponding > .eln files, or somewhere else? Correct, same directory of the eln. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 30 10:37:27 2021 Received: (at 46495) by debbugs.gnu.org; 30 Mar 2021 14:37:27 +0000 Received: from localhost ([127.0.0.1]:52536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRFUl-0001TI-Bq for submit@debbugs.gnu.org; Tue, 30 Mar 2021 10:37:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRFUj-0001T3-IT for 46495@debbugs.gnu.org; Tue, 30 Mar 2021 10:37:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38395) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRFUb-0004Tf-TF; Tue, 30 Mar 2021 10:37:19 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1403 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRFUZ-0005j8-RA; Tue, 30 Mar 2021 10:37:16 -0400 Date: Tue, 30 Mar 2021 17:37:28 +0300 Message-Id: <83im58k8rb.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Tue, 30 Mar 2021 14:33:04 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: dmalcolm@redhat.com, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > Date: Tue, 30 Mar 2021 14:33:04 +0000 > > Removing the .eln should not be necessary, thinking about actually if > it's removed I guess emacs will not be able to start and recompile the > file as not able to resurrect from dump. > > `batch-native-compile' or `batch-byte-native-compile-for-bootstrap' > should be equivalent here as the second is just a way to do only byte > compilation for non dumped files when we are not using NATIVE_FULL_AOT. Then I guess I'm missing something: how does Emacs know whether a given .eln file should be saved in native-lisp/ or in ~/.emacs.d/eln-cache/? > > And finally, in what directory will the pseudo C code files be dumped, > > when using comp-debug = 1? in the same directory as the corresponding > > .eln files, or somewhere else? > > Correct, same directory of the eln. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 30 15:19:18 2021 Received: (at 46495) by debbugs.gnu.org; 30 Mar 2021 19:19:18 +0000 Received: from localhost ([127.0.0.1]:52855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRJtW-0002BF-Bj for submit@debbugs.gnu.org; Tue, 30 Mar 2021 15:19:18 -0400 Received: from mx.sdf.org ([205.166.94.24]:64473) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRJtS-0002B3-79 for 46495@debbugs.gnu.org; Tue, 30 Mar 2021 15:19:16 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12UJJC2g007613 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 30 Mar 2021 19:19:12 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> Date: Tue, 30 Mar 2021 19:19:12 +0000 In-Reply-To: <83im58k8rb.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 Mar 2021 17:37:28 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: dmalcolm@redhat.com, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >> Date: Tue, 30 Mar 2021 14:33:04 +0000 >> >> Removing the .eln should not be necessary, thinking about actually if >> it's removed I guess emacs will not be able to start and recompile the >> file as not able to resurrect from dump. >> >> `batch-native-compile' or `batch-byte-native-compile-for-bootstrap' >> should be equivalent here as the second is just a way to do only byte >> compilation for non dumped files when we are not using NATIVE_FULL_AOT. > > Then I guess I'm missing something: how does Emacs know whether a > given .eln file should be saved in native-lisp/ or in > ~/.emacs.d/eln-cache/? Ops apologies you are correct, `batch-byte-native-compile-for-bootstrap' also select as destination folder the `native-lisp' directory in the build tree. It is correct to invoke `batch-byte-native-compile-for-bootstrap' if we want the .eln to be deposed there. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 04:07:18 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 08:07:18 +0000 Received: from localhost ([127.0.0.1]:53432 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRVsj-00014w-SM for submit@debbugs.gnu.org; Wed, 31 Mar 2021 04:07:18 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRVsg-00014h-4u for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 04:07:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55807) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRVsa-0004Gd-9A; Wed, 31 Mar 2021 04:07:08 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2678 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRVsZ-0007J8-AR; Wed, 31 Mar 2021 04:07:08 -0400 Date: Wed, 31 Mar 2021 11:07:20 +0300 Message-Id: <83o8eziw5j.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Tue, 30 Mar 2021 19:19:12 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: dmalcolm@redhat.com, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > Date: Tue, 30 Mar 2021 19:19:12 +0000 > > >> `batch-native-compile' or `batch-byte-native-compile-for-bootstrap' > >> should be equivalent here as the second is just a way to do only byte > >> compilation for non dumped files when we are not using NATIVE_FULL_AOT. > > > > Then I guess I'm missing something: how does Emacs know whether a > > given .eln file should be saved in native-lisp/ or in > > ~/.emacs.d/eln-cache/? > > Ops apologies you are correct, `batch-byte-native-compile-for-bootstrap' > also select as destination folder the `native-lisp' directory in the > build tree. It is correct to invoke > `batch-byte-native-compile-for-bootstrap' if we want the .eln to be > deposed there. OK, thanks. Another nit: the doc string of comp-debug says: 0 no debugging output. This is the recommended value unless you are debugging the compiler itself. 1 emit debug symbols and dump pseudo C code. 2 dump gcc passes and libgccjit log file. 3 dump libgccjit reproducers. But comp.c does this: if (comp.debug) gcc_jit_context_set_bool_option (comp.ctxt, GCC_JIT_BOOL_OPTION_DEBUGINFO, 1); if (comp.debug > 2) { logfile = emacs_fopen ("libgccjit.log", "w"); gcc_jit_context_set_logfile (comp.ctxt, logfile, 0, 0); gcc_jit_context_set_bool_option (comp.ctxt, GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES, 1); gcc_jit_context_set_bool_option (comp.ctxt, GCC_JIT_BOOL_OPTION_DUMP_EVERYTHING, 1); } [...] if (comp.debug) gcc_jit_context_dump_to_file (comp.ctxt, format_string ("%s.c", SSDATA (ebase_name)), 1); AFAIU, this means the libgccjit log file is only output with comp-debug 3 and higher? Also, does comp-debug = 3 indeed cause the reproducer to be written, or is that controlled independently by comp-libgccjit-reproducer? And finally, what do you think about moving the gcc_jit_context_dump_to_file call to comp-debug 2 or higher? IOW, make level 1 just add debug info to the *.eln files? Especially if we are going to make comp-debug = 1 the default (as I think we should), wouldn't it be better than the current setup? Or maybe we should introduce an intermediate debug level between the current 0 and 1? And if we make that change, do we also need to bump the ABI number? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 04:13:47 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 08:13:47 +0000 Received: from localhost ([127.0.0.1]:53446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRVz1-0001Ea-J5 for submit@debbugs.gnu.org; Wed, 31 Mar 2021 04:13:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36478) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRVz0-0001EO-69 for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 04:13:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55985) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRVyu-0000G6-St; Wed, 31 Mar 2021 04:13:40 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3088 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRVyu-0007oa-8d; Wed, 31 Mar 2021 04:13:40 -0400 Date: Wed, 31 Mar 2021 11:13:56 +0300 Message-Id: <83mtujivuj.fsf@gnu.org> From: Eli Zaretskii To: dmalcolm@redhat.com In-Reply-To: <834kgtko2p.fsf@gnu.org> (message from Eli Zaretskii on Tue, 30 Mar 2021 12:06:38 +0300) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <837dlpkrma.fsf@gnu.org> <834kgtko2p.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: 46495@debbugs.gnu.org, andrewjmoreton@gmail.com, akrl@sdf.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.7 (-) > Date: Tue, 30 Mar 2021 12:06:38 +0300 > From: Eli Zaretskii > Cc: akrl@sdf.org, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > > 3) I see in my temporary directory subdirectories, created when I run > the example program, with files fake.s and fake.so. Are they > supposed to be left there, or are they supposed to be deleted > when the program exits? These temporary files behave strangely, to say the least. Just running the tut01-hello-world example program produces a new temporary directory each time, and deposits a fake.so file there. If I run a variant of that which I built after adding gcc_jit_context_set_bool_option ( ctxt, GCC_JIT_BOOL_OPTION_DEBUGINFO, 1); then the temporary directory isn't created, or maybe it's deleted when the program exits. I think the latter is the case, because the directory is visible if I step through the program with a debugger, but disappears when the program exits. David, what's the story with these temporary directories? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 04:47:44 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 08:47:44 +0000 Received: from localhost ([127.0.0.1]:53460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRWVr-00021a-S6 for submit@debbugs.gnu.org; Wed, 31 Mar 2021 04:47:44 -0400 Received: from mx.sdf.org ([205.166.94.24]:56277) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRWVo-00021Q-9Y for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 04:47:42 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12V8lb1U000288 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 08:47:39 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83o8eziw5j.fsf@gnu.org> Date: Wed, 31 Mar 2021 08:47:37 +0000 In-Reply-To: <83o8eziw5j.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 31 Mar 2021 11:07:20 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: dmalcolm@redhat.com, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >> Date: Tue, 30 Mar 2021 19:19:12 +0000 >> >> >> `batch-native-compile' or `batch-byte-native-compile-for-bootstrap' >> >> should be equivalent here as the second is just a way to do only byte >> >> compilation for non dumped files when we are not using NATIVE_FULL_AOT. >> > >> > Then I guess I'm missing something: how does Emacs know whether a >> > given .eln file should be saved in native-lisp/ or in >> > ~/.emacs.d/eln-cache/? >> >> Ops apologies you are correct, `batch-byte-native-compile-for-bootstrap' >> also select as destination folder the `native-lisp' directory in the >> build tree. It is correct to invoke >> `batch-byte-native-compile-for-bootstrap' if we want the .eln to be >> deposed there. > > OK, thanks. > > Another nit: the doc string of comp-debug says: > > 0 no debugging output. > This is the recommended value unless you are debugging the compiler itself. > 1 emit debug symbols and dump pseudo C code. > 2 dump gcc passes and libgccjit log file. > 3 dump libgccjit reproducers. > > But comp.c does this: > > if (comp.debug) > gcc_jit_context_set_bool_option (comp.ctxt, > GCC_JIT_BOOL_OPTION_DEBUGINFO, > 1); > if (comp.debug > 2) > { > logfile = emacs_fopen ("libgccjit.log", "w"); > gcc_jit_context_set_logfile (comp.ctxt, > logfile, > 0, 0); > gcc_jit_context_set_bool_option (comp.ctxt, > GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES, > 1); > gcc_jit_context_set_bool_option (comp.ctxt, > GCC_JIT_BOOL_OPTION_DUMP_EVERYTHING, > 1); > } > [...] > if (comp.debug) > gcc_jit_context_dump_to_file (comp.ctxt, > format_string ("%s.c", SSDATA (ebase_name)), > 1); > > AFAIU, this means the libgccjit log file is only output with > comp-debug 3 and higher? Correct, the docstring wasn't correct :/ aa159bf696 should update it to reflect the current situation. > Also, does comp-debug = 3 indeed cause the > reproducer to be written, or is that controlled independently by > comp-libgccjit-reproducer? The reproducer is controlled independently by `comp-libgccjit-reproducer', the idea behind this is that we want to be able to produce reproducers independently from the debug settings (we might have a ligccjit bug that is related to one debug option). > > And finally, what do you think about moving the > gcc_jit_context_dump_to_file call to comp-debug 2 or higher? IOW, > make level 1 just add debug info to the *.eln files? Especially if we > are going to make comp-debug = 1 the default (as I think we should), > wouldn't it be better than the current setup? Or maybe we should > introduce an intermediate debug level between the current 0 and 1? My proposal would be like: 0 none 1 debug symbols 2 debug symbols + pseudo C file 3 debug symbols + pseudo C file + GCC passes + libgccjit log file I think the backtrace issue you are facing is clearly a gdb unwinder limitation on Windows that should be fixed in gdb. OTOH I understand we can't update gdb for all users that might want to help debugging an issue, but I don't like very much the idea to have comp-debug 1 as default on every system. What about having 1 as default only on Windows? WDYT? > And if we make that change, do we also need to bump the ABI number? I should not be necessary. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 06:01:33 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 10:01:33 +0000 Received: from localhost ([127.0.0.1]:53509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRXfJ-0003l8-DG for submit@debbugs.gnu.org; Wed, 31 Mar 2021 06:01:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60656) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRXfG-0003kv-P6 for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 06:01:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56978) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRXf9-0006p0-D9; Wed, 31 Mar 2021 06:01:23 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1989 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRXf8-0000n7-8l; Wed, 31 Mar 2021 06:01:22 -0400 Date: Wed, 31 Mar 2021 13:01:36 +0300 Message-Id: <83lfa3iqv3.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Tue, 30 Mar 2021 19:19:12 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: dmalcolm@redhat.com, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > Date: Tue, 30 Mar 2021 19:19:12 +0000 > > >> `batch-native-compile' or `batch-byte-native-compile-for-bootstrap' > >> should be equivalent here as the second is just a way to do only byte > >> compilation for non dumped files when we are not using NATIVE_FULL_AOT. > > > > Then I guess I'm missing something: how does Emacs know whether a > > given .eln file should be saved in native-lisp/ or in > > ~/.emacs.d/eln-cache/? > > Ops apologies you are correct, `batch-byte-native-compile-for-bootstrap' > also select as destination folder the `native-lisp' directory in the > build tree. It is correct to invoke > `batch-byte-native-compile-for-bootstrap' if we want the .eln to be > deposed there. For some reason, compiling files with batch-native-compile does NOT produce the message that I'm used to see with batch-byte-native-compile-for-bootstrap: libgccjit-0.dll: note: disable pass tree-isolate-paths for functions in the range of [0, 4294967295] Why is that? is that normal, or does it indicate some subtle problem with compiling by this method? The exact command I used is, for example, emacs -batch -l comp -eval "(setq comp-debug 1)" -f batch-native-compile ../lisp/emacs-lisp/seq.el Am I doing something wrong? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 06:19:12 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 10:19:12 +0000 Received: from localhost ([127.0.0.1]:53528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRXwN-0004Ak-5J for submit@debbugs.gnu.org; Wed, 31 Mar 2021 06:19:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRXwM-0004AZ-90 for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 06:19:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57157) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRXwE-0000ak-F6; Wed, 31 Mar 2021 06:19:02 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3081 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRXwD-00089i-QE; Wed, 31 Mar 2021 06:19:02 -0400 Date: Wed, 31 Mar 2021 13:19:16 +0300 Message-Id: <83k0pniq1n.fsf@gnu.org> From: Eli Zaretskii To: akrl@sdf.org In-Reply-To: <83lfa3iqv3.fsf@gnu.org> (message from Eli Zaretskii on Wed, 31 Mar 2021 13:01:36 +0300) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > Date: Wed, 31 Mar 2021 13:01:36 +0300 > From: Eli Zaretskii > Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org > > For some reason, compiling files with batch-native-compile does NOT > produce the message that I'm used to see with > batch-byte-native-compile-for-bootstrap: > > libgccjit-0.dll: note: disable pass tree-isolate-paths for functions in the range of [0, 4294967295] Oh, I see: it's because batch-native-compile runs the final compilation phase in a subprocess. But doesn't that mean the non-default setting of comp-debug will not have its effect in this case? Btw, I find the doc strings of the various top-level native-compile functions not very helpful when I need to understand under what circumstances they run the compilation asynchronously. I always need to read the code, and read it carefully, to figure that out. Can this please be improved? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 06:24:57 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 10:24:57 +0000 Received: from localhost ([127.0.0.1]:53539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRY1x-0004JX-4S for submit@debbugs.gnu.org; Wed, 31 Mar 2021 06:24:57 -0400 Received: from mx.sdf.org ([205.166.94.24]:64646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRY1v-0004JP-BH for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 06:24:55 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12VAOsnM017539 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 10:24:54 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> Date: Wed, 31 Mar 2021 10:24:54 +0000 In-Reply-To: <83lfa3iqv3.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 31 Mar 2021 13:01:36 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: dmalcolm@redhat.com, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >> Date: Tue, 30 Mar 2021 19:19:12 +0000 >> >> >> `batch-native-compile' or `batch-byte-native-compile-for-bootstrap' >> >> should be equivalent here as the second is just a way to do only byte >> >> compilation for non dumped files when we are not using NATIVE_FULL_AOT. >> > >> > Then I guess I'm missing something: how does Emacs know whether a >> > given .eln file should be saved in native-lisp/ or in >> > ~/.emacs.d/eln-cache/? >> >> Ops apologies you are correct, `batch-byte-native-compile-for-bootstrap' >> also select as destination folder the `native-lisp' directory in the >> build tree. It is correct to invoke >> `batch-byte-native-compile-for-bootstrap' if we want the .eln to be >> deposed there. > > For some reason, compiling files with batch-native-compile does NOT > produce the message that I'm used to see with > batch-byte-native-compile-for-bootstrap: > > libgccjit-0.dll: note: disable pass tree-isolate-paths for functions in the range of [0, 4294967295] I think is probably because `batch-native-compile' run the compilation as a subprocess so even if GCC is printing to stderr (or stdout) you don't see it in your terminal. Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 06:33:47 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 10:33:47 +0000 Received: from localhost ([127.0.0.1]:53555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRYAV-0004ga-C4 for submit@debbugs.gnu.org; Wed, 31 Mar 2021 06:33:47 -0400 Received: from mx.sdf.org ([205.166.94.24]:64161) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRYAT-0004gS-Nb for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 06:33:46 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12VAXhbt000570 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 10:33:43 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> Date: Wed, 31 Mar 2021 10:33:43 +0000 In-Reply-To: <83k0pniq1n.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 31 Mar 2021 13:19:16 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Eli Zaretskii writes: >> Date: Wed, 31 Mar 2021 13:01:36 +0300 >> From: Eli Zaretskii >> Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org >> >> For some reason, compiling files with batch-native-compile does NOT >> produce the message that I'm used to see with >> batch-byte-native-compile-for-bootstrap: >> >> libgccjit-0.dll: note: disable pass tree-isolate-paths for functions in the range of [0, 4294967295] > > Oh, I see: it's because batch-native-compile runs the final > compilation phase in a subprocess. But doesn't that mean the > non-default setting of comp-debug will not have its effect in this > case? `comp-debug' at that point is captured in the compilation context `comp-ctxt', we have a slot for that in the structure. > Btw, I find the doc strings of the various top-level native-compile > functions not very helpful when I need to understand under what > circumstances they run the compilation asynchronously. I always need > to read the code, and read it carefully, to figure that out. Can this > please be improved? Sure, if you have a list of the one that you have found troublesome (and/or some suggestion) I'll try to improve them. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 06:55:44 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 10:55:44 +0000 Received: from localhost ([127.0.0.1]:53569 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRYVj-0005Hx-Ln for submit@debbugs.gnu.org; Wed, 31 Mar 2021 06:55:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44338) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRYVf-0005Hf-QJ for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 06:55:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57577) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRYVZ-0004IL-BX; Wed, 31 Mar 2021 06:55:33 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1338 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRYVR-0006JH-Hn; Wed, 31 Mar 2021 06:55:28 -0400 Date: Wed, 31 Mar 2021 13:55:41 +0300 Message-Id: <83im57iocy.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 31 Mar 2021 10:33:43 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org > Date: Wed, 31 Mar 2021 10:33:43 +0000 > > >> libgccjit-0.dll: note: disable pass tree-isolate-paths for functions in the range of [0, 4294967295] > > > > Oh, I see: it's because batch-native-compile runs the final > > compilation phase in a subprocess. But doesn't that mean the > > non-default setting of comp-debug will not have its effect in this > > case? > > `comp-debug' at that point is captured in the compilation context > `comp-ctxt', we have a slot for that in the structure. OK, thanks. > > Btw, I find the doc strings of the various top-level native-compile > > functions not very helpful when I need to understand under what > > circumstances they run the compilation asynchronously. I always need > > to read the code, and read it carefully, to figure that out. Can this > > please be improved? > > Sure, if you have a list of the one that you have found troublesome > (and/or some suggestion) I'll try to improve them. I think these: comp--native-compile, native-compile, batch-native-compile, batch-byte-native-compile-for-bootstrap The first of these is an internal function, but it's used a lot, and its doc string describes most of what it does -- except the async aspect. One question I have, that perhaps will be answered by the enhanced doc strings, is this: how to run a batch compilation of a non-preloaded file such that no subprocesses at all are used? There's comp-async-jobs-number, but a zero value doesn't disable async compilation, it means something else. Another question is: the documentation sometimes mentions async compilation and sometimes mentions deferred compilation -- but these are not the same, right? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 07:10:24 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 11:10:25 +0000 Received: from localhost ([127.0.0.1]:53582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRYjw-0005h5-Mg for submit@debbugs.gnu.org; Wed, 31 Mar 2021 07:10:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRYjv-0005gs-0p for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 07:10:23 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57696) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRYjo-0004W4-NK; Wed, 31 Mar 2021 07:10:16 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2244 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRYjn-0002IR-6D; Wed, 31 Mar 2021 07:10:15 -0400 Date: Wed, 31 Mar 2021 14:10:28 +0300 Message-Id: <83h7krinob.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 31 Mar 2021 10:33:43 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org > Date: Wed, 31 Mar 2021 10:33:43 +0000 > > > Oh, I see: it's because batch-native-compile runs the final > > compilation phase in a subprocess. But doesn't that mean the > > non-default setting of comp-debug will not have its effect in this > > case? > > `comp-debug' at that point is captured in the compilation context > `comp-ctxt', we have a slot for that in the structure. Each FILE compiled via batch-native-compile leaves in my temp directory a file whose name is emacs-int-compile-FILE-XXXXX-YYYYY-NNNNN.el. I see this file created in comp-final, but where is it deleted? Should we delete it once call-process returns? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 07:41:13 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 11:41:13 +0000 Received: from localhost ([127.0.0.1]:53666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRZDk-0000A8-OF for submit@debbugs.gnu.org; Wed, 31 Mar 2021 07:41:13 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57990) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRZDi-00009v-QT for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 07:41:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58179) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRZDb-0007by-2B; Wed, 31 Mar 2021 07:41:03 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4121 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRZDU-0001ca-Ho; Wed, 31 Mar 2021 07:41:02 -0400 Date: Wed, 31 Mar 2021 14:41:10 +0300 Message-Id: <83ft0bim95.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 31 Mar 2021 08:47:37 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83o8eziw5j.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: dmalcolm@redhat.com, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > Date: Wed, 31 Mar 2021 08:47:37 +0000 > > > AFAIU, this means the libgccjit log file is only output with > > comp-debug 3 and higher? > > Correct, the docstring wasn't correct :/ aa159bf696 should update it to > reflect the current situation. Thanks. > > Also, does comp-debug = 3 indeed cause the > > reproducer to be written, or is that controlled independently by > > comp-libgccjit-reproducer? > > The reproducer is controlled independently by > `comp-libgccjit-reproducer', the idea behind this is that we want to be > able to produce reproducers independently from the debug settings (we > might have a ligccjit bug that is related to one debug option). Right, so comp-debug = 3 alone doesn't trigger the reproducer, right? > My proposal would be like: > > 0 none > 1 debug symbols > 2 debug symbols + pseudo C file > 3 debug symbols + pseudo C file + GCC passes + libgccjit log file > > I think the backtrace issue you are facing is clearly a gdb unwinder > limitation on Windows that should be fixed in gdb. It's more like a missing feature in GDB on platforms that don't use ELF binary format. I don't hold my breath to have the situation improved, since this is so far a rare situation when debugging programs: no one expects debugging code without debug symbols to be easy. > OTOH I understand we can't update gdb for all users that might want > to help debugging an issue, but I don't like very much the idea to > have comp-debug 1 as default on every system. What about having 1 > as default only on Windows? WDYT? In general, I'd prefer these settings to be the same on all platforms, although it isn't a strong feeling in this case. But I'm curious why you are so against doing that by default on other systems. Can you explain? Anyway, I've compiled the relevant files with comp-debug = 1, and the problems with backtraces are now completely gone. So I think we can more or less close this issue (modulo changing the meanings of comp-debug and the decision regarding the default value). From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 08:16:21 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 12:16:21 +0000 Received: from localhost ([127.0.0.1]:53713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRZlk-00010S-NM for submit@debbugs.gnu.org; Wed, 31 Mar 2021 08:16:21 -0400 Received: from mx.sdf.org ([205.166.94.24]:55600) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRZli-00010G-6i for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 08:16:19 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12VCGElj005836 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 12:16:15 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83o8eziw5j.fsf@gnu.org> <83ft0bim95.fsf@gnu.org> Date: Wed, 31 Mar 2021 12:16:14 +0000 In-Reply-To: <83ft0bim95.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 31 Mar 2021 14:41:10 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: dmalcolm@redhat.com, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >> Date: Wed, 31 Mar 2021 08:47:37 +0000 >> >> > AFAIU, this means the libgccjit log file is only output with >> > comp-debug 3 and higher? >> >> Correct, the docstring wasn't correct :/ aa159bf696 should update it to >> reflect the current situation. > > Thanks. > >> > Also, does comp-debug = 3 indeed cause the >> > reproducer to be written, or is that controlled independently by >> > comp-libgccjit-reproducer? >> >> The reproducer is controlled independently by >> `comp-libgccjit-reproducer', the idea behind this is that we want to be >> able to produce reproducers independently from the debug settings (we >> might have a ligccjit bug that is related to one debug option). > > Right, so comp-debug = 3 alone doesn't trigger the reproducer, right? That's correct. >> My proposal would be like: >> >> 0 none >> 1 debug symbols >> 2 debug symbols + pseudo C file >> 3 debug symbols + pseudo C file + GCC passes + libgccjit log file >> >> I think the backtrace issue you are facing is clearly a gdb unwinder >> limitation on Windows that should be fixed in gdb. > > It's more like a missing feature in GDB on platforms that don't use > ELF binary format. I don't hold my breath to have the situation > improved, since this is so far a rare situation when debugging > programs: no one expects debugging code without debug symbols to be > easy. > >> OTOH I understand we can't update gdb for all users that might want >> to help debugging an issue, but I don't like very much the idea to >> have comp-debug 1 as default on every system. What about having 1 >> as default only on Windows? WDYT? > > In general, I'd prefer these settings to be the same on all platforms, > although it isn't a strong feeling in this case. But I'm curious why > you are so against doing that by default on other systems. Can you > explain? Nothing special, just that that as on GNU/Linux we can produce backtraces without debug symbols so seams to me it would be a waste of space to have them always present just for this reason. > Anyway, I've compiled the relevant files with comp-debug = 1, and the > problems with backtraces are now completely gone. So I think we can > more or less close this issue (modulo changing the meanings of > comp-debug and the decision regarding the default value). Sounds good, if my proposal of the new 4 values is acceptable for you and we decide on the default one I can proceed with that. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 08:24:11 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 12:24:11 +0000 Received: from localhost ([127.0.0.1]:53741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRZtL-0001DF-HU for submit@debbugs.gnu.org; Wed, 31 Mar 2021 08:24:11 -0400 Received: from mx.sdf.org ([205.166.94.24]:54920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRZtJ-0001D6-S1 for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 08:24:10 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12VCO8bG023865 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 12:24:08 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83im57iocy.fsf@gnu.org> Date: Wed, 31 Mar 2021 12:24:07 +0000 In-Reply-To: <83im57iocy.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 31 Mar 2021 13:55:41 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org >> Date: Wed, 31 Mar 2021 10:33:43 +0000 >> >> >> libgccjit-0.dll: note: disable pass tree-isolate-paths for functions in the range of [0, 4294967295] >> > >> > Oh, I see: it's because batch-native-compile runs the final >> > compilation phase in a subprocess. But doesn't that mean the >> > non-default setting of comp-debug will not have its effect in this >> > case? >> >> `comp-debug' at that point is captured in the compilation context >> `comp-ctxt', we have a slot for that in the structure. > > OK, thanks. > >> > Btw, I find the doc strings of the various top-level native-compile >> > functions not very helpful when I need to understand under what >> > circumstances they run the compilation asynchronously. I always need >> > to read the code, and read it carefully, to figure that out. Can this >> > please be improved? >> >> Sure, if you have a list of the one that you have found troublesome >> (and/or some suggestion) I'll try to improve them. > > I think these: > > comp--native-compile, native-compile, batch-native-compile, > batch-byte-native-compile-for-bootstrap > > The first of these is an internal function, but it's used a lot, and > its doc string describes most of what it does -- except the async > aspect. > > One question I have, that perhaps will be answered by the enhanced doc > strings, is this: how to run a batch compilation of a non-preloaded > file such that no subprocesses at all are used? ATM there's no way. The idea is that we typically don't want to run in the same process as libgccjit leaks memory (and contribute to memory fragmentation). We do it only for `batch-byte-native-compile-for-bootstrap' as we know that the Emacs process will not last long. > There's > comp-async-jobs-number, but a zero value doesn't disable async > compilation, it means something else. > > Another question is: the documentation sometimes mentions async > compilation and sometimes mentions deferred compilation -- but these > are not the same, right? I'd say: - async compilation is the mechanism that allow for compiling asynchronously. - deferred is the mechanism that allow for loading bytecode, triggering an async compilation and eventually perform the swap of the function definition when the async compilation is done. Regards Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 08:25:55 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 12:25:55 +0000 Received: from localhost ([127.0.0.1]:53746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRZv1-0001Fq-0V for submit@debbugs.gnu.org; Wed, 31 Mar 2021 08:25:55 -0400 Received: from mx.sdf.org ([205.166.94.24]:54801) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRZuz-0001Fi-Bi for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 08:25:53 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12VCPqSj007523 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 12:25:52 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> Date: Wed, 31 Mar 2021 12:25:52 +0000 In-Reply-To: <83h7krinob.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 31 Mar 2021 14:10:28 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org >> Date: Wed, 31 Mar 2021 10:33:43 +0000 >> >> > Oh, I see: it's because batch-native-compile runs the final >> > compilation phase in a subprocess. But doesn't that mean the >> > non-default setting of comp-debug will not have its effect in this >> > case? >> >> `comp-debug' at that point is captured in the compilation context >> `comp-ctxt', we have a slot for that in the structure. > > Each FILE compiled via batch-native-compile leaves in my temp > directory a file whose name is > emacs-int-compile-FILE-XXXXX-YYYYY-NNNNN.el. I see this file created > in comp-final, but where is it deleted? Should we delete it once > call-process returns? Is the application responsible for cleaning up temporary files in '/tmp? If yes then yes... I guess we should :) Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 08:27:43 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 12:27:43 +0000 Received: from localhost ([127.0.0.1]:53758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRZwl-0001Ir-67 for submit@debbugs.gnu.org; Wed, 31 Mar 2021 08:27:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRZwj-0001Ia-Hh for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 08:27:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58869) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRZwc-0000JT-65; Wed, 31 Mar 2021 08:27:36 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3038 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRZwZ-0007Gh-Ju; Wed, 31 Mar 2021 08:27:32 -0400 Date: Wed, 31 Mar 2021 15:27:46 +0300 Message-Id: <83eefvik3h.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 31 Mar 2021 12:16:14 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83o8eziw5j.fsf@gnu.org> <83ft0bim95.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: dmalcolm@redhat.com, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > Date: Wed, 31 Mar 2021 12:16:14 +0000 > > >> OTOH I understand we can't update gdb for all users that might want > >> to help debugging an issue, but I don't like very much the idea to > >> have comp-debug 1 as default on every system. What about having 1 > >> as default only on Windows? WDYT? > > > > In general, I'd prefer these settings to be the same on all platforms, > > although it isn't a strong feeling in this case. But I'm curious why > > you are so against doing that by default on other systems. Can you > > explain? > > Nothing special, just that that as on GNU/Linux we can produce > backtraces without debug symbols so seams to me it would be a waste of > space to have them always present just for this reason. Well, using comp-debug = 1 produces minor improvements also on GNU/Linux, as it shows the values of arguments of the natively-compiled functions instead of just "()". Example: #75 0x01260cad in funcall_subr (subr=0x1730200 , numargs=3, args=0x82f028) at eval.c:3064 #76 0x01260805 in Ffuncall (nargs=4, args=0x82f020) at eval.c:3009 #77 0x0125f238 in Fapply (nargs=3, args=0x82f1a8) at eval.c:2639 #78 0x01250e54 in Fcall_interactively (function=XIL(0x44e24ec), record_flag=XIL(0), keys=XIL(0xa00000000678d168)) at callint.c:353 #79 0x70f1ae41 in F636f6d6d616e642d65786563757465_command_execute_0 ( par_0=72230124, par_1=0, par_2=0, par_3=0) <<<<<<<<<<<<<<<<<<<<<<<<< at d:/gnu/git/emacs/native-comp/native-lisp/28.0.50-c99426db/simple-fab5b0cf-db78b289.c:23993 But I'm okay with leaving it at zero except on Windows for now, we can always revisit this later. > > Anyway, I've compiled the relevant files with comp-debug = 1, and the > > problems with backtraces are now completely gone. So I think we can > > more or less close this issue (modulo changing the meanings of > > comp-debug and the decision regarding the default value). > > Sounds good, if my proposal of the new 4 values is acceptable for you > and we decide on the default one I can proceed with that. Yes, let's make that change. Please also look into the issue with temporary *.el files I reported earlier. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 08:32:56 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 12:32:56 +0000 Received: from localhost ([127.0.0.1]:53776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRa1o-0001SS-AA for submit@debbugs.gnu.org; Wed, 31 Mar 2021 08:32:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRa1m-0001SF-Le for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 08:32:55 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58932) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRa1g-0003Nb-Cy; Wed, 31 Mar 2021 08:32:48 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3363 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRa1d-0001R3-Ra; Wed, 31 Mar 2021 08:32:48 -0400 Date: Wed, 31 Mar 2021 15:33:02 +0300 Message-Id: <83blazijup.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 31 Mar 2021 12:25:52 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org > Date: Wed, 31 Mar 2021 12:25:52 +0000 > > > Each FILE compiled via batch-native-compile leaves in my temp > > directory a file whose name is > > emacs-int-compile-FILE-XXXXX-YYYYY-NNNNN.el. I see this file created > > in comp-final, but where is it deleted? Should we delete it once > > call-process returns? > > Is the application responsible for cleaning up temporary files in '/tmp? > If yes then yes... I guess we should :) I think it's good practice, yes. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 08:41:33 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 12:41:33 +0000 Received: from localhost ([127.0.0.1]:53788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRaA9-0001f0-B1 for submit@debbugs.gnu.org; Wed, 31 Mar 2021 08:41:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43302) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRaA7-0001en-UM for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 08:41:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59015) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRaA2-0000SR-Jy; Wed, 31 Mar 2021 08:41:26 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3888 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRaA0-0007q3-Bi; Wed, 31 Mar 2021 08:41:25 -0400 Date: Wed, 31 Mar 2021 15:41:38 +0300 Message-Id: <83a6qjijgd.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 31 Mar 2021 12:24:07 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83im57iocy.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org > Date: Wed, 31 Mar 2021 12:24:07 +0000 > > > One question I have, that perhaps will be answered by the enhanced doc > > strings, is this: how to run a batch compilation of a non-preloaded > > file such that no subprocesses at all are used? > > ATM there's no way. The idea is that we typically don't want to run in > the same process as libgccjit leaks memory (and contribute to memory > fragmentation). We do it only for > `batch-byte-native-compile-for-bootstrap' as we know that the Emacs > process will not last long. But batch-native-compile is also going to exit once the compilation ends, won't it? Or is the difference that batch-byte-native-compile-for-bootstrap only ever compiles a single file? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 08:53:35 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 12:53:35 +0000 Received: from localhost ([127.0.0.1]:53800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRaLn-0001wE-3J for submit@debbugs.gnu.org; Wed, 31 Mar 2021 08:53:35 -0400 Received: from mx.sdf.org ([205.166.94.24]:53095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRaLj-0001w4-AB for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 08:53:34 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12VCrTOx029853 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 12:53:30 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83im57iocy.fsf@gnu.org> <83a6qjijgd.fsf@gnu.org> Date: Wed, 31 Mar 2021 12:53:29 +0000 In-Reply-To: <83a6qjijgd.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 31 Mar 2021 15:41:38 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org >> Date: Wed, 31 Mar 2021 12:24:07 +0000 >> >> > One question I have, that perhaps will be answered by the enhanced doc >> > strings, is this: how to run a batch compilation of a non-preloaded >> > file such that no subprocesses at all are used? >> >> ATM there's no way. The idea is that we typically don't want to run in >> the same process as libgccjit leaks memory (and contribute to memory >> fragmentation). We do it only for >> `batch-byte-native-compile-for-bootstrap' as we know that the Emacs >> process will not last long. > > But batch-native-compile is also going to exit once the compilation > ends, won't it? Or is the difference that > batch-byte-native-compile-for-bootstrap only ever compiles a single > file? Originally I created `batch-byte-native-compile-for-bootstrap' only to integrate with the build system and support the NATIVE_FULL_AOT thing while `batch-native-compile' is supposed to be more of a general purpose one. Your point is correct tho. Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 09:03:45 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 13:03:45 +0000 Received: from localhost ([127.0.0.1]:53805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRaVc-0002BL-Ec for submit@debbugs.gnu.org; Wed, 31 Mar 2021 09:03:45 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:46136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRaVb-0002BC-4y for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 09:03:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617195822; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lMYDV1Dif+V7j+5NoYnC812VC8AvW8kdvXfO6DGLKi0=; b=LDdOmLim8BSFV/Sxj7mWhi2R65GNUbmkGYH2zHmdQSEEPMTBPHEYAheE2aKUazWd9Tja/d q6AEgKnInMai23shXxx027huv4CYY/VRXOFMrtr6VdmAjccXQYDw0oAmHd4WlR0VtDi7Su ljbUTwUrwyGll2H/YtvBxyGfbkPpHzo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-96-iLEWvrF3Pgeg_N0vaoxjMA-1; Wed, 31 Mar 2021 09:03:38 -0400 X-MC-Unique: iLEWvrF3Pgeg_N0vaoxjMA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 58D5010082E8; Wed, 31 Mar 2021 13:03:37 +0000 (UTC) Received: from t14s.localdomain (ovpn-112-76.phx2.redhat.com [10.3.112.76]) by smtp.corp.redhat.com (Postfix) with ESMTP id 59387669F3; Wed, 31 Mar 2021 13:03:34 +0000 (UTC) Message-ID: <6e8b54e5d93d4e311b9db56adb538ae6aa848c60.camel@redhat.com> Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int From: David Malcolm To: Eli Zaretskii Date: Wed, 31 Mar 2021 09:03:33 -0400 In-Reply-To: <83mtujivuj.fsf@gnu.org> References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <837dlpkrma.fsf@gnu.org> <834kgtko2p.fsf@gnu.org> <83mtujivuj.fsf@gnu.org> User-Agent: Evolution 3.38.3 (3.38.3-1.fc33) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmalcolm@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: 46495@debbugs.gnu.org, andrewjmoreton@gmail.com, akrl@sdf.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.7 (-) On Wed, 2021-03-31 at 11:13 +0300, Eli Zaretskii wrote: > > Date: Tue, 30 Mar 2021 12:06:38 +0300 > > From: Eli Zaretskii > > Cc: akrl@sdf.org, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > > > >  3) I see in my temporary directory subdirectories, created when I > > run > >     the example program, with files fake.s and fake.so.  Are they > >     supposed to be left there, or are they supposed to be deleted > >     when the program exits? > > These temporary files behave strangely, to say the least.  Just > running the tut01-hello-world example program produces a new > temporary > directory each time, and deposits a fake.so file there.  If I run a > variant of that which I built after adding > >   gcc_jit_context_set_bool_option ( >                                    ctxt, >                                    GCC_JIT_BOOL_OPTION_DEBUGINFO, >                                    1); > > then the temporary directory isn't created, or maybe it's deleted > when > the program exits.  I think the latter is the case, because the > directory is visible if I step through the program with a debugger, > but disappears when the program exits. > > David, what's the story with these temporary directories? They're meant to be cleaned up automatically by libgccjit: on gcc_jit_result_release for a successful compilation, or at the end of gcc_jit_context_compile* for a failed compilation. The removal code is in gcc::jit::tempdir::~tempdir in gcc/jit/jit- tempdir.c, maybe there's a bug there? (perhaps only affecting Windows?) It calls unlink on everything it "knows" about, and them rmdir on the directory. I see now that I'm not checking for errors on those unlink and rmdir calls. Is the code setting GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES to true, perhaps? That forcibly keeps them around: https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#c.GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES Dave From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 09:13:43 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 13:13:43 +0000 Received: from localhost ([127.0.0.1]:53817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRafG-0002Po-TC for submit@debbugs.gnu.org; Wed, 31 Mar 2021 09:13:43 -0400 Received: from mx.sdf.org ([205.166.94.24]:51934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRafF-0002Pe-9v for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 09:13:42 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12VDDdQT023175 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 13:13:39 GMT From: Andrea Corallo To: David Malcolm Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <837dlpkrma.fsf@gnu.org> <834kgtko2p.fsf@gnu.org> <83mtujivuj.fsf@gnu.org> <6e8b54e5d93d4e311b9db56adb538ae6aa848c60.camel@redhat.com> Date: Wed, 31 Mar 2021 13:13:39 +0000 In-Reply-To: <6e8b54e5d93d4e311b9db56adb538ae6aa848c60.camel@redhat.com> (David Malcolm's message of "Wed, 31 Mar 2021 09:03:33 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46495 Cc: Eli Zaretskii , andrewjmoreton@gmail.com, 46495@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 (-) David Malcolm writes: > On Wed, 2021-03-31 at 11:13 +0300, Eli Zaretskii wrote: >> > Date: Tue, 30 Mar 2021 12:06:38 +0300 >> > From: Eli Zaretskii >> > Cc: akrl@sdf.org, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >> >=20 >> > =C2=A03) I see in my temporary directory subdirectories, created when I >> > run >> > =C2=A0=C2=A0=C2=A0 the example program, with files fake.s and fake.so.= =C2=A0 Are they >> > =C2=A0=C2=A0=C2=A0 supposed to be left there, or are they supposed to = be deleted >> > =C2=A0=C2=A0=C2=A0 when the program exits? >>=20 >> These temporary files behave strangely, to say the least.=C2=A0 Just >> running the tut01-hello-world example program produces a new >> temporary >> directory each time, and deposits a fake.so file there.=C2=A0 If I run a >> variant of that which I built after adding >>=20 >> =C2=A0 gcc_jit_context_set_bool_option ( >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ctxt, >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GCC_JIT_BOOL_OPTI= ON_DEBUGINFO, >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1); >>=20 >> then the temporary directory isn't created, or maybe it's deleted >> when >> the program exits.=C2=A0 I think the latter is the case, because the >> directory is visible if I step through the program with a debugger, >> but disappears when the program exits. >>=20 >> David, what's the story with these temporary directories? > > They're meant to be cleaned up automatically by libgccjit: on > gcc_jit_result_release for a successful compilation, or at the end of > gcc_jit_context_compile* for a failed compilation. I suspect we are just missing the call to 'gcc_jit_result_release'. I'm having a look. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 09:33:52 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 13:33:52 +0000 Received: from localhost ([127.0.0.1]:53853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRayl-0002wm-SK for submit@debbugs.gnu.org; Wed, 31 Mar 2021 09:33:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55242) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRayj-0002wa-QU for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 09:33:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59837) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRaye-00068P-8c; Wed, 31 Mar 2021 09:33:44 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3167 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRayd-0005eJ-Cf; Wed, 31 Mar 2021 09:33:44 -0400 Date: Wed, 31 Mar 2021 16:33:57 +0300 Message-Id: <837dlnih16.fsf@gnu.org> From: Eli Zaretskii To: David Malcolm In-Reply-To: <6e8b54e5d93d4e311b9db56adb538ae6aa848c60.camel@redhat.com> (message from David Malcolm on Wed, 31 Mar 2021 09:03:33 -0400) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86y2fq93zj.fsf@gmail.com> <83lfbqbq3g.fsf@gnu.org> <868s7pwvq8.fsf@gmail.com> <28FB9567-61E6-4083-8711-6CF6C8A493F4@gnu.org> <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <837dlpkrma.fsf@gnu.org> <834kgtko2p.fsf@gnu.org> <83mtujivuj.fsf@gnu.org> <6e8b54e5d93d4e311b9db56adb538ae6aa848c60.camel@redhat.com> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: 46495@debbugs.gnu.org, andrewjmoreton@gmail.com, akrl@sdf.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.7 (-) > From: David Malcolm > Cc: akrl@sdf.org, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > Date: Wed, 31 Mar 2021 09:03:33 -0400 > > > David, what's the story with these temporary directories? > > They're meant to be cleaned up automatically by libgccjit: on > gcc_jit_result_release for a successful compilation, or at the end of > gcc_jit_context_compile* for a failed compilation. > > The removal code is in gcc::jit::tempdir::~tempdir in gcc/jit/jit- > tempdir.c, maybe there's a bug there? (perhaps only affecting Windows?) > It calls unlink on everything it "knows" about, and them rmdir on the > directory. I see now that I'm not checking for errors on those unlink > and rmdir calls. maybe you are relying on the Posix semantics whereby you can remove files that are still in use, and the OS will remove them when the last user closes the file? That's not going to work on Windows, you need to close first and remove later. When does the object go out of scope, and its destructor called? > Is the code setting GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES to true, > perhaps? No. the code is just tut01d-hello-world.c as it is given here: https://gcc.gnu.org/onlinedocs/jit/intro/tutorial01.html The only variation (as described in my previous messages) is that I added gcc_jit_context_set_bool_option ( ctxt, GCC_JIT_BOOL_OPTION_DEBUGINFO, 1); in one of the variants I compiled. But the variant with the above added actually behaves correctly and removes the temporary directory upon exit. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 09:35:49 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 13:35:49 +0000 Received: from localhost ([127.0.0.1]:53863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRb0e-00030r-OI for submit@debbugs.gnu.org; Wed, 31 Mar 2021 09:35:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRb0d-00030f-FW for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 09:35:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59865) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRb0Y-0007PE-95; Wed, 31 Mar 2021 09:35:42 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3291 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRb0W-0001An-CL; Wed, 31 Mar 2021 09:35:41 -0400 Date: Wed, 31 Mar 2021 16:35:55 +0300 Message-Id: <835z17igxw.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 31 Mar 2021 13:13:39 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86o8gjheaw.fsf@gmail.com> <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <837dlpkrma.fsf@gnu.org> <834kgtko2p.fsf@gnu.org> <83mtujivuj.fsf@gnu.org> <6e8b54e5d93d4e311b9db56adb538ae6aa848c60.camel@redhat.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: Eli Zaretskii , andrewjmoreton@gmail.com, > 46495@debbugs.gnu.org > Date: Wed, 31 Mar 2021 13:13:39 +0000 > > >>   gcc_jit_context_set_bool_option ( > >>                                    ctxt, > >>                                    GCC_JIT_BOOL_OPTION_DEBUGINFO, > >>                                    1); > >> > >> then the temporary directory isn't created, or maybe it's deleted > >> when > >> the program exits.  I think the latter is the case, because the > >> directory is visible if I step through the program with a debugger, > >> but disappears when the program exits. > >> > >> David, what's the story with these temporary directories? > > > > They're meant to be cleaned up automatically by libgccjit: on > > gcc_jit_result_release for a successful compilation, or at the end of > > gcc_jit_context_compile* for a failed compilation. > > I suspect we are just missing the call to 'gcc_jit_result_release'. I'm > having a look. The tutorial does call gcc_jit_result_release. I think this only happens in the tutorial example, not in Emacs. Sorry if that was unclear. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 14:26:21 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 18:26:21 +0000 Received: from localhost ([127.0.0.1]:55503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRfXo-0004Ti-Ui for submit@debbugs.gnu.org; Wed, 31 Mar 2021 14:26:21 -0400 Received: from mx.sdf.org ([205.166.94.24]:58541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRfXm-0004TZ-KX for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 14:26:20 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12VIQH6f001830 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 18:26:17 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <865z2p0zrq.fsf@gmail.com> <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83o8eziw5j.fsf@gnu.org> <83ft0bim95.fsf@gnu.org> <83eefvik3h.fsf@gnu.org> Date: Wed, 31 Mar 2021 18:26:17 +0000 In-Reply-To: <83eefvik3h.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 31 Mar 2021 15:27:46 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: dmalcolm@redhat.com, andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >> Date: Wed, 31 Mar 2021 12:16:14 +0000 >> >> >> OTOH I understand we can't update gdb for all users that might want >> >> to help debugging an issue, but I don't like very much the idea to >> >> have comp-debug 1 as default on every system. What about having 1 >> >> as default only on Windows? WDYT? >> > >> > In general, I'd prefer these settings to be the same on all platforms, >> > although it isn't a strong feeling in this case. But I'm curious why >> > you are so against doing that by default on other systems. Can you >> > explain? >> >> Nothing special, just that that as on GNU/Linux we can produce >> backtraces without debug symbols so seams to me it would be a waste of >> space to have them always present just for this reason. > > Well, using comp-debug = 1 produces minor improvements also on > GNU/Linux, as it shows the values of arguments of the > natively-compiled functions instead of just "()". Example: > > #75 0x01260cad in funcall_subr (subr=0x1730200 , > numargs=3, args=0x82f028) at eval.c:3064 > #76 0x01260805 in Ffuncall (nargs=4, args=0x82f020) at eval.c:3009 > #77 0x0125f238 in Fapply (nargs=3, args=0x82f1a8) at eval.c:2639 > #78 0x01250e54 in Fcall_interactively (function=XIL(0x44e24ec), > record_flag=XIL(0), keys=XIL(0xa00000000678d168)) at callint.c:353 > #79 0x70f1ae41 in F636f6d6d616e642d65786563757465_command_execute_0 ( > par_0=72230124, par_1=0, par_2=0, par_3=0) <<<<<<<<<<<<<<<<<<<<<<<<< > at d:/gnu/git/emacs/native-comp/native-lisp/28.0.50-c99426db/simple-fab5b0cf-db78b289.c:23993 > > But I'm okay with leaving it at zero except on Windows for now, we can > always revisit this later. > >> > Anyway, I've compiled the relevant files with comp-debug = 1, and the >> > problems with backtraces are now completely gone. So I think we can >> > more or less close this issue (modulo changing the meanings of >> > comp-debug and the decision regarding the default value). >> >> Sounds good, if my proposal of the new 4 values is acceptable for you >> and we decide on the default one I can proceed with that. > > Yes, let's make that change. Okay 53ca0d9844 reworks the levels and change the default value on Windows, I think `comp-debug' should do what we want now. > > Please also look into the issue with temporary *.el files I reported > earlier. Yep coming on that. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 14:52:59 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 18:52:59 +0000 Received: from localhost ([127.0.0.1]:55520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRfxa-00057Z-UL for submit@debbugs.gnu.org; Wed, 31 Mar 2021 14:52:59 -0400 Received: from mx.sdf.org ([205.166.94.24]:56123) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRfxZ-00057P-0i for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 14:52:57 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12VIqtbU005289 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 18:52:56 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> Date: Wed, 31 Mar 2021 18:52:55 +0000 In-Reply-To: <83blazijup.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 31 Mar 2021 15:33:02 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org >> Date: Wed, 31 Mar 2021 12:25:52 +0000 >> >> > Each FILE compiled via batch-native-compile leaves in my temp >> > directory a file whose name is >> > emacs-int-compile-FILE-XXXXX-YYYYY-NNNNN.el. I see this file created >> > in comp-final, but where is it deleted? Should we delete it once >> > call-process returns? >> >> Is the application responsible for cleaning up temporary files in '/tmp? >> If yes then yes... I guess we should :) > > I think it's good practice, yes. 8e524f4591 fix this. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 15:16:24 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 19:16:24 +0000 Received: from localhost ([127.0.0.1]:55538 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRgKG-0005iL-BL for submit@debbugs.gnu.org; Wed, 31 Mar 2021 15:16:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43988) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRgKF-0005i5-H9 for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 15:16:23 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38321) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRgKA-0003dX-5Y; Wed, 31 Mar 2021 15:16:18 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4419 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRgK8-00081T-Tz; Wed, 31 Mar 2021 15:16:17 -0400 Date: Wed, 31 Mar 2021 22:16:01 +0300 Message-Id: <83y2e3gmmm.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 31 Mar 2021 18:52:55 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <86pn0w59nj.fsf@gmail.com> <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org > Date: Wed, 31 Mar 2021 18:52:55 +0000 > > >> Is the application responsible for cleaning up temporary files in '/tmp? > >> If yes then yes... I guess we should :) > > > > I think it's good practice, yes. > > 8e524f4591 fix this. Thanks, confirmed. Btw, I have now 3 different *.eln files for comp.el in the same subdirectory of native-lisp: comp-7672a6ed-ad0cbb8b.eln comp-7672a6ed-58fb0518.eln comp-7672a6ed-9f0b1563.eln Is this expected? What does the second hash depend on? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 15:22:59 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 19:22:59 +0000 Received: from localhost ([127.0.0.1]:55546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRgQd-0005t4-9I for submit@debbugs.gnu.org; Wed, 31 Mar 2021 15:22:59 -0400 Received: from mx.sdf.org ([205.166.94.24]:53489) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRgQb-0005su-NW for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 15:22:58 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12VJMs4E025091 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 19:22:54 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> Date: Wed, 31 Mar 2021 19:22:54 +0000 In-Reply-To: <83y2e3gmmm.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 31 Mar 2021 22:16:01 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org >> Date: Wed, 31 Mar 2021 18:52:55 +0000 >> >> >> Is the application responsible for cleaning up temporary files in '/tmp? >> >> If yes then yes... I guess we should :) >> > >> > I think it's good practice, yes. >> >> 8e524f4591 fix this. > > Thanks, confirmed. > > Btw, I have now 3 different *.eln files for comp.el in the same > subdirectory of native-lisp: > > comp-7672a6ed-ad0cbb8b.eln > comp-7672a6ed-58fb0518.eln > comp-7672a6ed-9f0b1563.eln > > Is this expected? What does the second hash depend on? The second hash is the one based on the source file content. I see why, every time we compile a new eln we call `comp-clean-up-stale-eln' to remove the old .eln. But we exclude from the clean-up the eln system directory (the last in `comp-eln-laod-path'). I don't remember if the reason is that when Emacs is installed this is typically read only or there's some other reason. Probably we should remove this limitation and handle correctly the case where we are not able of removing the file if necessary. Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 15:35:59 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 19:35:59 +0000 Received: from localhost ([127.0.0.1]:55566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRgdD-0006EU-Be for submit@debbugs.gnu.org; Wed, 31 Mar 2021 15:35:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48082) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRgdB-0006EG-SO for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 15:35:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38601) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRgd6-0004fT-IV; Wed, 31 Mar 2021 15:35:52 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1640 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRgd4-00053r-VW; Wed, 31 Mar 2021 15:35:52 -0400 Date: Wed, 31 Mar 2021 22:35:30 +0300 Message-Id: <83wntnglq5.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 31 Mar 2021 19:22:54 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org > Date: Wed, 31 Mar 2021 19:22:54 +0000 > > > comp-7672a6ed-ad0cbb8b.eln > > comp-7672a6ed-58fb0518.eln > > comp-7672a6ed-9f0b1563.eln > > > > Is this expected? What does the second hash depend on? > > The second hash is the one based on the source file content. > > I see why, every time we compile a new eln we call > `comp-clean-up-stale-eln' to remove the old .eln. But we exclude from > the clean-up the eln system directory (the last in > `comp-eln-laod-path'). So with these 3 files in that directory, which one will be loaded by Emacs, and how will Emacs know which to load? > I don't remember if the reason is that when Emacs is installed this is > typically read only or there's some other reason. Probably we should > remove this limitation and handle correctly the case where we are not > able of removing the file if necessary. Probably. But didn't you try that recently and found that something broke as result? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 15:40:30 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 19:40:30 +0000 Received: from localhost ([127.0.0.1]:55570 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRgha-0006LD-06 for submit@debbugs.gnu.org; Wed, 31 Mar 2021 15:40:30 -0400 Received: from mx.sdf.org ([205.166.94.24]:52043) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRghY-0006L4-8g for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 15:40:28 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12VJeQX5018478 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 19:40:27 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> Date: Wed, 31 Mar 2021 19:40:26 +0000 In-Reply-To: (Andrea Corallo via's message of "Wed, 31 Mar 2021 19:22:54 +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: 46495 Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@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 (-) Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Eli Zaretskii writes: > >>> From: Andrea Corallo >>> Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org >>> Date: Wed, 31 Mar 2021 18:52:55 +0000 >>> >>> >> Is the application responsible for cleaning up temporary files in '/tmp? >>> >> If yes then yes... I guess we should :) >>> > >>> > I think it's good practice, yes. >>> >>> 8e524f4591 fix this. >> >> Thanks, confirmed. >> >> Btw, I have now 3 different *.eln files for comp.el in the same >> subdirectory of native-lisp: >> >> comp-7672a6ed-ad0cbb8b.eln >> comp-7672a6ed-58fb0518.eln >> comp-7672a6ed-9f0b1563.eln >> >> Is this expected? What does the second hash depend on? > > The second hash is the one based on the source file content. > > I see why, every time we compile a new eln we call > `comp-clean-up-stale-eln' to remove the old .eln. But we exclude from > the clean-up the eln system directory (the last in > `comp-eln-laod-path'). > > I don't remember if the reason is that when Emacs is installed this is > typically read only or there's some other reason. Probably we should > remove this limitation and handle correctly the case where we are not > able of removing the file if necessary. Okay apparently we did it already in the past (be22cda7be) but I reverted the commit with d0280ce1b1. The commit message for this says: "Older binaries might still need those .eln if they where preloaded." I guess the issue is clear now and we should be able to better tackle it once we depose the preloaded .eln in the preloaded subfolder (I think I'll be on that this weekend). Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 31 15:43:21 2021 Received: (at 46495) by debbugs.gnu.org; 31 Mar 2021 19:43:21 +0000 Received: from localhost ([127.0.0.1]:55575 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRgkL-0006PU-Fr for submit@debbugs.gnu.org; Wed, 31 Mar 2021 15:43:21 -0400 Received: from mx.sdf.org ([205.166.94.24]:51872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRgkJ-0006PL-63 for 46495@debbugs.gnu.org; Wed, 31 Mar 2021 15:43:19 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12VJhHKs008353 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 31 Mar 2021 19:43:18 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> <83wntnglq5.fsf@gnu.org> Date: Wed, 31 Mar 2021 19:43:17 +0000 In-Reply-To: <83wntnglq5.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 31 Mar 2021 22:35:30 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org >> Date: Wed, 31 Mar 2021 19:22:54 +0000 >> >> > comp-7672a6ed-ad0cbb8b.eln >> > comp-7672a6ed-58fb0518.eln >> > comp-7672a6ed-9f0b1563.eln >> > >> > Is this expected? What does the second hash depend on? >> >> The second hash is the one based on the source file content. >> >> I see why, every time we compile a new eln we call >> `comp-clean-up-stale-eln' to remove the old .eln. But we exclude from >> the clean-up the eln system directory (the last in >> `comp-eln-laod-path'). > > So with these 3 files in that directory, which one will be loaded by > Emacs, and how will Emacs know which to load? Emacs will scan and hash the source file and load the correct one if present. >> I don't remember if the reason is that when Emacs is installed this is >> typically read only or there's some other reason. Probably we should >> remove this limitation and handle correctly the case where we are not >> able of removing the file if necessary. > > Probably. But didn't you try that recently and found that something > broke as result? Yeah, you see now how terrible is my memory :) please see my other mail on this. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 01 02:38:08 2021 Received: (at 46495) by debbugs.gnu.org; 1 Apr 2021 06:38:08 +0000 Received: from localhost ([127.0.0.1]:55957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRqy0-0005VU-KM for submit@debbugs.gnu.org; Thu, 01 Apr 2021 02:38:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49444) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRqxy-0005V0-9a for 46495@debbugs.gnu.org; Thu, 01 Apr 2021 02:38:06 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49016) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRqxs-000687-EC; Thu, 01 Apr 2021 02:38:00 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2475 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRqxr-0000nw-80; Thu, 01 Apr 2021 02:38:00 -0400 Date: Thu, 01 Apr 2021 09:37:43 +0300 Message-Id: <83v996h5mw.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 31 Mar 2021 19:43:17 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <83y2eap33a.fsf@gnu.org> <83lfa6kl8s.fsf@gnu.org> <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> <83wntnglq5.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > Date: Wed, 31 Mar 2021 19:43:17 +0000 > > > So with these 3 files in that directory, which one will be loaded by > > Emacs, and how will Emacs know which to load? > > Emacs will scan and hash the source file and load the correct one if > present. And if the source file isn't available? In any case, AFAIU I can safely delete the 2 older *.eln files because they will never be used, right? From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 01 03:07:58 2021 Received: (at 46495) by debbugs.gnu.org; 1 Apr 2021 07:07:59 +0000 Received: from localhost ([127.0.0.1]:55988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRrQs-0006Cs-Kr for submit@debbugs.gnu.org; Thu, 01 Apr 2021 03:07:58 -0400 Received: from mx.sdf.org ([205.166.94.24]:61853) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRrQq-0006Cj-Fq for 46495@debbugs.gnu.org; Thu, 01 Apr 2021 03:07:57 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 13177rdg008078 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 1 Apr 2021 07:07:54 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> <83wntnglq5.fsf@gnu.org> <83v996h5mw.fsf@gnu.org> Date: Thu, 01 Apr 2021 07:07:53 +0000 In-Reply-To: <83v996h5mw.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 01 Apr 2021 09:37:43 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >> Date: Wed, 31 Mar 2021 19:43:17 +0000 >> >> > So with these 3 files in that directory, which one will be loaded by >> > Emacs, and how will Emacs know which to load? >> >> Emacs will scan and hash the source file and load the correct one if >> present. > > And if the source file isn't available? No eln will be loaded. > In any case, AFAIU I can safely delete the 2 older *.eln files because > they will never be used, right? Correct, unless you have another binary that is using one of these eln as preloaded, indeed this should not be the case as comp.el is not preloaded. Andrea From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 01 03:43:25 2021 Received: (at 46495) by debbugs.gnu.org; 1 Apr 2021 07:43:26 +0000 Received: from localhost ([127.0.0.1]:56026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRrzB-00078I-KW for submit@debbugs.gnu.org; Thu, 01 Apr 2021 03:43:25 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRrz9-000784-RN for 46495@debbugs.gnu.org; Thu, 01 Apr 2021 03:43:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49598) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRrz3-0004yT-IK; Thu, 01 Apr 2021 03:43:17 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2503 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRrz2-0005MY-PA; Thu, 01 Apr 2021 03:43:17 -0400 Date: Thu, 01 Apr 2021 10:42:59 +0300 Message-Id: <83k0pmh2m4.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Thu, 01 Apr 2021 07:07:53 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <83h7ktlwuy.fsf@gnu.org> <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> <83wntnglq5.fsf@gnu.org> <83v996h5mw.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > Date: Thu, 01 Apr 2021 07:07:53 +0000 > > Eli Zaretskii writes: > > >> From: Andrea Corallo > >> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > >> Date: Wed, 31 Mar 2021 19:43:17 +0000 > >> > >> > So with these 3 files in that directory, which one will be loaded by > >> > Emacs, and how will Emacs know which to load? > >> > >> Emacs will scan and hash the source file and load the correct one if > >> present. > > > > And if the source file isn't available? > > No eln will be loaded. Ouch! That's a general issue, then, not just when there are multiple copies of *.eln for the same .el file, right? IOW, if Emacs is installed such that the *.el files are not available, it will not load the *.eln files, only the *.elc files. I think we should at least produce a run-time warning about that. If the .el file is available, but was compressed, will Emacs scan it after uncompressing to verify the signature? This is the usual way Emacs is installed: we compress all the *.el files. > > In any case, AFAIU I can safely delete the 2 older *.eln files because > > they will never be used, right? > > Correct, unless you have another binary that is using one of these eln > as preloaded, indeed this should not be the case as comp.el is not > preloaded. But even if the file is preloaded, the fact that it is in the same hashed subdirectory of native-lisp/ means it can be used with any binary whose ABI is compatible. Right? Or are you saying that the source-content hash of the .eln file is recorded in the .pdmp file? From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 01 04:18:14 2021 Received: (at 46495) by debbugs.gnu.org; 1 Apr 2021 08:18:14 +0000 Received: from localhost ([127.0.0.1]:56232 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRsWs-0008G5-BO for submit@debbugs.gnu.org; Thu, 01 Apr 2021 04:18:14 -0400 Received: from mx.sdf.org ([205.166.94.24]:58125) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRsWn-0008Fv-U4 for 46495@debbugs.gnu.org; Thu, 01 Apr 2021 04:18:13 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 1318I85V021629 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 1 Apr 2021 08:18:09 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> <83wntnglq5.fsf@gnu.org> <83v996h5mw.fsf@gnu.org> <83k0pmh2m4.fsf@gnu.org> Date: Thu, 01 Apr 2021 08:18:08 +0000 In-Reply-To: <83k0pmh2m4.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 01 Apr 2021 10:42:59 +0300") 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: 46495 Cc: andrewjmoreton@gmail.com, 46495@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 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >> Date: Thu, 01 Apr 2021 07:07:53 +0000 >> >> Eli Zaretskii writes: >> >> >> From: Andrea Corallo >> >> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >> >> Date: Wed, 31 Mar 2021 19:43:17 +0000 >> >> >> >> > So with these 3 files in that directory, which one will be loaded by >> >> > Emacs, and how will Emacs know which to load? >> >> >> >> Emacs will scan and hash the source file and load the correct one if >> >> present. >> > >> > And if the source file isn't available? >> >> No eln will be loaded. > > Ouch! That's a general issue, then, not just when there are multiple > copies of *.eln for the same .el file, right? IOW, if Emacs is > installed such that the *.el files are not available, it will not load > the *.eln files, only the *.elc files. I think we should at least > produce a run-time warning about that. Correct, okay the warning should not be a problem (taking note into my todo). Do we really have installations with no source code? > If the .el file is available, but was compressed, will Emacs > scan it after uncompressing to verify the signature? This is the > usual way Emacs is installed: we compress all the *.el files. Yes it does that :) (I tipically use Emacs installed). >> > In any case, AFAIU I can safely delete the 2 older *.eln files because >> > they will never be used, right? >> >> Correct, unless you have another binary that is using one of these eln >> as preloaded, indeed this should not be the case as comp.el is not >> preloaded. > > But even if the file is preloaded, the fact that it is in the same > hashed subdirectory of native-lisp/ means it can be used with any > binary whose ABI is compatible. Right? Or are you saying that the > source-content hash of the .eln file is recorded in the .pdmp file? When the file was preloaded when reviving from dump it is looked-up using its filename, as you suggests includes the `comp-abi-hash' in it. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 01 04:43:36 2021 Received: (at 46495) by debbugs.gnu.org; 1 Apr 2021 08:43:36 +0000 Received: from localhost ([127.0.0.1]:56262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRsvQ-0000Qn-8w for submit@debbugs.gnu.org; Thu, 01 Apr 2021 04:43:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49008) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRsvO-0000QZ-8X for 46495@debbugs.gnu.org; Thu, 01 Apr 2021 04:43:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50541) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRsvI-0000I6-Uu; Thu, 01 Apr 2021 04:43:28 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2263 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRsvH-0003j4-PT; Thu, 01 Apr 2021 04:43:28 -0400 Date: Thu, 01 Apr 2021 11:43:10 +0300 Message-Id: <83eefugztt.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Thu, 01 Apr 2021 08:18:08 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <65e12b1d547420e10a19cdad6a33198926abb527.camel@redhat.com> <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> <83wntnglq5.fsf@gnu.org> <83v996h5mw.fsf@gnu.org> <83k0pmh2m4.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495 Cc: andrewjmoreton@gmail.com, 46495@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.7 (-) > From: Andrea Corallo > Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > Date: Thu, 01 Apr 2021 08:18:08 +0000 > > > Ouch! That's a general issue, then, not just when there are multiple > > copies of *.eln for the same .el file, right? IOW, if Emacs is > > installed such that the *.el files are not available, it will not load > > the *.eln files, only the *.elc files. I think we should at least > > produce a run-time warning about that. > > Correct, okay the warning should not be a problem (taking note into my > todo). > > Do we really have installations with no source code? Good question. I don't know the answer, but I guess we will learn, when the warning is implemented. > > But even if the file is preloaded, the fact that it is in the same > > hashed subdirectory of native-lisp/ means it can be used with any > > binary whose ABI is compatible. Right? Or are you saying that the > > source-content hash of the .eln file is recorded in the .pdmp file? > > When the file was preloaded when reviving from dump it is looked-up > using its filename, as you suggests includes the `comp-abi-hash' in it. Right, noted. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 01 10:16:55 2021 Received: (at submit) by debbugs.gnu.org; 1 Apr 2021 14:16:56 +0000 Received: from localhost ([127.0.0.1]:58157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRy7z-0000uT-Ju for submit@debbugs.gnu.org; Thu, 01 Apr 2021 10:16:55 -0400 Received: from lists.gnu.org ([209.51.188.17]:41012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRy7x-0000t0-UN for submit@debbugs.gnu.org; Thu, 01 Apr 2021 10:16:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54788) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lRy7x-0007bd-PI for bug-gnu-emacs@gnu.org; Thu, 01 Apr 2021 10:16:53 -0400 Received: from taper.sei.cmu.edu ([147.72.252.16]:50410) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lRy7v-0008Uc-My; Thu, 01 Apr 2021 10:16:53 -0400 Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 131EGWsS019689; Thu, 1 Apr 2021 10:16:32 -0400 Received: from lx-birch.ad.sei.cmu.edu (lx-birch.ad.sei.cmu.edu [10.64.53.120]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 131EGSGS010286; Thu, 1 Apr 2021 10:16:28 -0400 Received: from lx-birch.ad.sei.cmu.edu (localhost [127.0.0.1]) by lx-birch.ad.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 131EGSQ3004528; Thu, 1 Apr 2021 10:16:28 -0400 Received: (from mwd@localhost) by lx-birch.ad.sei.cmu.edu (8.14.7/8.14.7) id 131EGQsm004525; Thu, 1 Apr 2021 10:16:26 -0400 X-Authentication-Warning: lx-birch.ad.sei.cmu.edu: mwd set sender to mwd@cert.org using -f From: Michael Welsh Duggan To: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int In-Reply-To: (Andrea Corallo via's message of "Thu, 01 Apr 2021 08:18:08 +0000") Date: Thu, 01 Apr 2021 10:16:11 -0400 Message-ID: <87wntmt7is.fsf@md5i.com> References: <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> <83wntnglq5.fsf@gnu.org> <83v996h5mw.fsf@gnu.org> <83k0pmh2m4.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=147.72.252.16; envelope-from=mwd@cert.org; helo=taper.sei.cmu.edu X-Spam_score_int: -39 X-Spam_score: -4.0 X-Spam_bar: ---- X-Spam_report: (-4.0 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , 46495@debbugs.gnu.org, andrewjmoreton@gmail.com, Andrea Corallo 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.4 (--) Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Eli Zaretskii writes: > >>> From: Andrea Corallo >>> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >>> Date: Thu, 01 Apr 2021 07:07:53 +0000 >>> >>> Eli Zaretskii writes: >>> >>> >> From: Andrea Corallo >>> >> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >>> >> Date: Wed, 31 Mar 2021 19:43:17 +0000 >>> >> >>> >> > So with these 3 files in that directory, which one will be loaded by >>> >> > Emacs, and how will Emacs know which to load? >>> >> >>> >> Emacs will scan and hash the source file and load the correct one if >>> >> present. >>> > >>> > And if the source file isn't available? >>> >>> No eln will be loaded. >> >> Ouch! That's a general issue, then, not just when there are multiple >> copies of *.eln for the same .el file, right? IOW, if Emacs is >> installed such that the *.el files are not available, it will not load >> the *.eln files, only the *.elc files. I think we should at least >> produce a run-time warning about that. > > Correct, okay the warning should not be a problem (taking note into my > todo). > > Do we really have installations with no source code? At least in the Debian distribution, the package containing the .el files are not a direct dependency but a recommended dependency. -- Michael Welsh Duggan (md5i@md5i.com) From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 01 15:52:19 2021 Received: (at 46495) by debbugs.gnu.org; 1 Apr 2021 19:52:19 +0000 Received: from localhost ([127.0.0.1]:58726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lS3MZ-0001sm-HF for submit@debbugs.gnu.org; Thu, 01 Apr 2021 15:52:19 -0400 Received: from mx.sdf.org ([205.166.94.24]:49866) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lS3MW-0001sc-QM for 46495@debbugs.gnu.org; Thu, 01 Apr 2021 15:52:17 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 131JqE6p006262 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 1 Apr 2021 19:52:14 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> <83wntnglq5.fsf@gnu.org> <83v996h5mw.fsf@gnu.org> <83k0pmh2m4.fsf@gnu.org> Date: Thu, 01 Apr 2021 19:52:14 +0000 In-Reply-To: (Andrea Corallo via's message of "Thu, 01 Apr 2021 08:18:08 +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: 46495 Cc: andrewjmoreton@gmail.com, 46495@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 (-) Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Eli Zaretskii writes: > >>> From: Andrea Corallo >>> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >>> Date: Thu, 01 Apr 2021 07:07:53 +0000 >>> >>> Eli Zaretskii writes: >>> >>> >> From: Andrea Corallo >>> >> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >>> >> Date: Wed, 31 Mar 2021 19:43:17 +0000 >>> >> >>> >> > So with these 3 files in that directory, which one will be loaded by >>> >> > Emacs, and how will Emacs know which to load? >>> >> >>> >> Emacs will scan and hash the source file and load the correct one if >>> >> present. >>> > >>> > And if the source file isn't available? >>> >>> No eln will be loaded. >> >> Ouch! That's a general issue, then, not just when there are multiple >> copies of *.eln for the same .el file, right? IOW, if Emacs is >> installed such that the *.el files are not available, it will not load >> the *.eln files, only the *.elc files. I think we should at least >> produce a run-time warning about that. > > Correct, okay the warning should not be a problem (taking note into my > todo). Okay dc393517ca adds the warning emittion. I've also added a customize `comp-warning-on-missing-source' to silence that in case. Andrea From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 10 12:49:19 2021 Received: (at 46495) by debbugs.gnu.org; 10 Apr 2021 16:49:19 +0000 Received: from localhost ([127.0.0.1]:53156 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVGnO-0005Di-Pf for submit@debbugs.gnu.org; Sat, 10 Apr 2021 12:49:19 -0400 Received: from mx.sdf.org ([205.166.94.24]:50079) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVGnM-0005DY-6W for 46495@debbugs.gnu.org; Sat, 10 Apr 2021 12:49:16 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 13AGnFei007152 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 10 Apr 2021 16:49:15 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> <83wntnglq5.fsf@gnu.org> <83v996h5mw.fsf@gnu.org> <83k0pmh2m4.fsf@gnu.org> Date: Sat, 10 Apr 2021 16:49:15 +0000 In-Reply-To: (Andrea Corallo's message of "Thu, 01 Apr 2021 19:52:14 +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: 46495 Cc: andrewjmoreton@gmail.com, 46495@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 (-) Andrea Corallo writes: > Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" writes: > >> Eli Zaretskii writes: >> >>>> From: Andrea Corallo >>>> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >>>> Date: Thu, 01 Apr 2021 07:07:53 +0000 >>>> >>>> Eli Zaretskii writes: >>>> >>>> >> From: Andrea Corallo >>>> >> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org >>>> >> Date: Wed, 31 Mar 2021 19:43:17 +0000 >>>> >> >>>> >> > So with these 3 files in that directory, which one will be loaded by >>>> >> > Emacs, and how will Emacs know which to load? >>>> >> >>>> >> Emacs will scan and hash the source file and load the correct one if >>>> >> present. >>>> > >>>> > And if the source file isn't available? >>>> >>>> No eln will be loaded. >>> >>> Ouch! That's a general issue, then, not just when there are multiple >>> copies of *.eln for the same .el file, right? IOW, if Emacs is >>> installed such that the *.el files are not available, it will not load >>> the *.eln files, only the *.elc files. I think we should at least >>> produce a run-time warning about that. >> >> Correct, okay the warning should not be a problem (taking note into my >> todo). > > Okay dc393517ca adds the warning emittion. I've also added a customize > `comp-warning-on-missing-source' to silence that in case. > > Andrea Not an expert of the bug tracker here but I think this is still open. In case should we close it? Andrea From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 10 13:39:04 2021 Received: (at 46495-done) by debbugs.gnu.org; 10 Apr 2021 17:39:04 +0000 Received: from localhost ([127.0.0.1]:53191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVHZY-0006Of-0j for submit@debbugs.gnu.org; Sat, 10 Apr 2021 13:39:04 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVHZV-0006OA-6l for 46495-done@debbugs.gnu.org; Sat, 10 Apr 2021 13:39:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47958) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVHZQ-00008k-0A; Sat, 10 Apr 2021 13:38:56 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4095 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lVHZM-0008DP-Jr; Sat, 10 Apr 2021 13:38:55 -0400 Date: Sat, 10 Apr 2021 20:38:39 +0300 Message-Id: <837dla59b4.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Sat, 10 Apr 2021 16:49:15 +0000) Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int References: <8335wdknbw.fsf@gnu.org> <83im58k8rb.fsf@gnu.org> <83lfa3iqv3.fsf@gnu.org> <83k0pniq1n.fsf@gnu.org> <83h7krinob.fsf@gnu.org> <83blazijup.fsf@gnu.org> <83y2e3gmmm.fsf@gnu.org> <83wntnglq5.fsf@gnu.org> <83v996h5mw.fsf@gnu.org> <83k0pmh2m4.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46495-done Cc: 46495-done@debbugs.gnu.org, andrewjmoreton@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: -1.7 (-) > From: Andrea Corallo > Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org > Date: Sat, 10 Apr 2021 16:49:15 +0000 > > > Okay dc393517ca adds the warning emittion. I've also added a customize > > `comp-warning-on-missing-source' to silence that in case. > > > > Andrea > > Not an expert of the bug tracker here but I think this is still open. > In case should we close it? Right, closing. From unknown Sat Jun 21 03:19:57 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 09 May 2021 11:24:11 +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