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