From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.bugs Subject: bug#63365: bug#65727: 30.0.50; Build failure in MSYS2 when --with-native-compilation Date: Fri, 17 May 2024 08:06:56 -0400 Message-ID: References: <86wn1jtezk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18429"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: "63365@debbugs.gnu.org" <63365@debbugs.gnu.org>, "eliz@gnu.org" , 65727@debbugs.gnu.org, Arash Esbati , =?UTF-8?Q?Andr=C3=A1s?= Svraka To: Cyril Arnould Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri May 17 14:08:19 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s7wNn-0004W6-Ap for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 May 2024 14:08:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s7wNX-0005zp-C9; Fri, 17 May 2024 08:08:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s7wNV-0005zX-Jc for bug-gnu-emacs@gnu.org; Fri, 17 May 2024 08:08:01 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s7wNV-00033u-3y for bug-gnu-emacs@gnu.org; Fri, 17 May 2024 08:08:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s7wNW-0000Lp-Id for bug-gnu-emacs@gnu.org; Fri, 17 May 2024 08:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 May 2024 12:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63365 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 63365-submit@debbugs.gnu.org id=B63365.17159476351326 (code B ref 63365); Fri, 17 May 2024 12:08:02 +0000 Original-Received: (at 63365) by debbugs.gnu.org; 17 May 2024 12:07:15 +0000 Original-Received: from localhost ([127.0.0.1]:54825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s7wMk-0000LH-EG for submit@debbugs.gnu.org; Fri, 17 May 2024 08:07:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44310) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s7wMg-0000L1-Gi; Fri, 17 May 2024 08:07:12 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s7wMX-0002rf-Tz; Fri, 17 May 2024 08:07:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=/xhr5bZv1I/HGtRpEPQvq7KJ1JTvHDgV34qighEYkwI=; b=Q453TR5yY7EVYx8Z0bGe Yy7f4LTFy+HDX3AzhSEsfshiBv7FGcBAX6/b65q1iWlsQJk31PH5WUQxfBs1Nv7tbmYm+gOSpW6tu Thx7t5O+7A5Q9hNTHhElAQARvlx/Dy1WU1+LK3nI0MeRXbWwIzIBYniZVPDwV/9xz+Ecmvl4uShif 8PGNa4lEPDnz5by8BvbIZFRXO48HdhnGjM00eCcq+HvyXBvuGkhIYY8HI9MMhsxfXufQmjxVENc5/ f+swVxKIxQE24uqw5jNS/OvgOqldenrZV9jgkHUqCQTUWPT0fF22r7Btb3l13ZFPD+dnlgsFPNiqM k6cy3pDZOBS5Ig==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1s7wMT-0007AY-6r; Fri, 17 May 2024 08:07:00 -0400 In-Reply-To: (Andrea Corallo's message of "Fri, 17 May 2024 00:42:24 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:285233 Archived-At: Andrea Corallo writes: > Cyril Arnould writes: > >>> it would be great if you could: >>> >>> $ cd src >>> $ touch thread.c >>> $ make thread.o V=3D1 >>> >>> Get the exact GCC invocation and add there "-E -o thread.i". This way >>> we are sure we are looking at the right thing. >> >> I did as you asked, but a diff with the previously sent files shows >> that the new ones are identical. > > That's very good, is important we are sure we look at the right thing. > I'll digest them later tomorrow and report then =F0=9F=98=83 Okay it's finally clear what is going on here. In Emacs we use (in order to have all callee saved registers pushed on the stack before entering in the garbage collector) '__builtin_unwind_init'. Our code reduced looks like this: test.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D extern void flush_stack_call_func1 (void (*func) (void *arg), void *arg); extern void mark_threads (void); extern void mark_threads_callback (void *ignore); static inline void flush_stack_call_func (void (*func) (void *arg), void *arg) { __builtin_unwind_init (); flush_stack_call_func1 (func, arg); } void mark_threads (void) { flush_stack_call_func (mark_threads_callback, ((void *)0)); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We want to call 'flush_stack_call_func1' being sure that all callee saved registers are pushed on the stack (so that the GC can scan the whole stack correctly). The idea in pseudo asm is like: mark_threads: [...] push # these pushs are from 'builtin_unwind_init' push push [...] call flush_stack_call_func1 pop # these pops are from 'builtin_unwind_init' pop pop ret Sibling call optimization makes this: mark_threads: [...] push push push [...] pop pop pop jmp flush_stack_call_func1 Which indeed does not work for us. I believe this is a GCC bug as the sibling call optimizer should not run in functions making use of 'builtin_unwind_init', even if this one is undocumented (otherwise I can't see its reason of being =F0=9F=99=82). So I filed a GCC bug [1]. Despite the fact that this will or not be recognized as a bug (and in case fixed), I think we'll have to fix this on our codebase disabling the sibling call optimizations on the sentive function(s). Also note, this bug is not a native-comp specifc one, it's just most likely non triggerable on most configuration. IOW I think we see it only on mingw+nativecomp by chance. Thanks Andrea [1]