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

From: Eli Zaretskii <[email-masked]>
Date: Tue, 27 Jun 2023 05:30:14 +0300

> From: Cyril Arnould <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, András Svraka
> 	<[email-masked]>, Arash Esbati <[email-masked]>,
> 	"[email-masked]" <[email-masked]>
> 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.