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

[Eli Zaretskii <eliz@gnu.org>]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: arash@gnu.org,  cyril.arnould@outlook.com,  63365@debbugs.gnu.org,
>   svraka.andras@gmail.com
> Date: Sun, 25 Jun 2023 14:11:15 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Maybe someone should compare the two binaries (with and without
> >> -foptimize-sibling-calls) to understand which compilation unit (and
> >> which function) differs in details.
> >
> > How does one compare binaries in a useful way?  The Emacs binary is
> > AFAIR around 20MB even when stripped of all symbols.
> 
> That's a good question, for elf there are specific tools for that, even
> just readelf can output function sizes and that's a good starting point.
> 
> For Windows I've idea (I'm assuming Windows is not elf based).

No, Windows doesn't use ELF.

Maybe we should start by narrowing the problem?  E.g., which Lisp
files cause the crashes, and which *.eln files, if any, are involved?

The C files more or less directly involved in byte-compilation are, I
think, eval.c, data.c, alloc.c, lread.c, bytecode.c.  If we think one
of these could be involved, it would be nice to find the one(s) that
cause the problem, for example, by selectively compiling only those
with -fno-optimize-sibling-calls, then removing them one by one from
the set of files compiled like that.

The investigation if this bug is harder because the problem doesn't
happen when running Emacs under GDB, and conversion of backtrace
addresses to file names and line numbers for some reason also doesn't
work.  So we need every smart idea we can come up with.