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

[Eli Zaretskii <eliz@gnu.org>]

> From: Cyril Arnould <cyril.arnould@outlook.com>
> CC: "eliz@gnu.org" <eliz@gnu.org>, András Svraka
> 	<svraka.andras@gmail.com>, Arash Esbati <arash@gnu.org>,
> 	"63365@debbugs.gnu.org" <63365@debbugs.gnu.org>
> Date: Mon, 26 Jun 2023 22:04:19 +0000
> 
> >> 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.
> >  
> > That would be a good starting point already, I'd suggest to add comp.c
> > to the investigated set as well.
>  
> I can take a look into this, but I'm unsure as to how exactly; I'm still
> very new to the GNU Autotools. AFAIU, this would be done using
> per-target Automake variables but there's no Makefile.am...

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.