[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63365: 30.0.50; GCC 13.1 breaks building Emacs with native-compilati
From: |
Eli Zaretskii |
Subject: |
bug#63365: 30.0.50; GCC 13.1 breaks building Emacs with native-compilation |
Date: |
Wed, 28 Jun 2023 14:37:27 +0300 |
> From: Cyril Arnould <cyril.arnould@outlook.com>
> CC: "63365@debbugs.gnu.org" <63365@debbugs.gnu.org>,
> AndrĂ¡s Svraka <svraka.andras@gmail.com>, Andrea Corallo
> <acorallo@gnu.org>, Arash Esbati <arash@gnu.org>
> Date: Tue, 27 Jun 2023 19:28:12 +0000
>
> > $ cd src
> > $ make lread.o -W lread.c CFLAGS='-O2 -fno-optimize-sibling-calls'
> > $ make
> >
> > The last "make command will produce an emacs.exe binary where lread.c
> > is compiled without the problematic optimization.
>
> I see, thanks. Is there a reason you left out the -g3 and -gdwarf-2
> switches?
No particular reason.
> To be sure, I've tried it with and without those, but I got
> similar results so far: all of the combinations I've tried are
> failing. I'm trying to widen the search to see if I can figure out which
> file is the culprit.
Since the problem disappears under GDB, it is probably memory-related.
So it figures that it behaves like a classic heisenbug.
Unfortunately, it means more combinations to try and more time to
waste...
> >From the tests I've run it seems to me that there is absolutely no
> consistency with which lisp files cause the crashes. Each of the builds
> resulted in different lisp files failing. Now, when I run the make
> command again after a failed attempt, the *same* lisp files will keep
> failing to build over and over. However, I also noticed that if I run
> the exact same build commands again from a clean checkout, different
> lisp files will fail the second time around. Is it normal that there are
> run-to-run variations with GCC?
See above: I'm not surprised. Especially since MinGW64 uses ASLR.
However, using sequential builds, as suggested by Andrea, could
perhaps help. I'd also consider building with -Wl,--disable-dynamicbase
for example like this (when you run Make in the src directory):
make LD_SWITCH_SYSTEM='-Wl,--disable-dynamicbase'
Maybe this will make the bug less unpredictable, who knows?
- bug#63365: 30.0.50; GCC 13.1 breaks building Emacs with native-compilation, (continued)
bug#63365: 30.0.50; GCC 13.1 breaks building Emacs with native-compilation, Cyril Arnould, 2023/06/17
bug#63365: 30.0.50; GCC 13.1 breaks building Emacs with native-compilation, Cyril Arnould, 2023/06/26
bug#63365: 30.0.50; GCC 13.1 breaks building Emacs with native-compilation, Cyril Arnould, 2023/06/27
bug#63365: 30.0.50; GCC 13.1 breaks building Emacs with native-compilation, Cyril Arnould, 2023/06/28
bug#63365: 30.0.50; GCC 13.1 breaks building Emacs with native-compilation, Cyril Arnould, 2023/06/29