GNU bug report logs -
#63365
30.0.50; GCC 13.1 breaks building Emacs with native-compilation
Previous Next
Reported by: Arash Esbati <arash <at> gnu.org>
Date: Mon, 8 May 2023 08:17:02 UTC
Severity: normal
Tags: moreinfo
Merged with 65727
Found in version 30.0.50
Done: Andrea Corallo <acorallo <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
> No, that would be a waste of your time. It is much easier to do this
> by hand. To compile, say, lread.c, do this:
>
> $ 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? 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.
> Maybe we should start by narrowing the problem? E.g., which Lisp
> files cause the crashes, and which *.eln files, if any, are involved?
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?
[Message part 2 (text/html, inline)]
This bug report was last modified 1 year and 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.