bug#63365: 30.0.50; GCC 13.1 breaks building Emacs with native-compilation

[Cyril Arnould <cyril.arnould@outlook.com>]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

> 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?

[-- Attachment #2: Type: text/html, Size: 3281 bytes --]