Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jim Meyering <meyering at ascend dot com>]

"David S. Miller" <davem@dm.cobaltmicro.com> writes:

|    Date: Thu, 16 Jul 1998 05:36:32 -0700
|    From: "David S. Miller" <davem@dm.cobaltmicro.com>
|
|    I'll try to track this down further as time permits.  Thanks for the
|    report.
|
| Replying to myself...
|
| Jim, I believe i have tracked it down, so could you do some
| experiments for me?
|
| In my case I have found that the GCSE pass mis-optimizes the code in
| unexelf.c  When I recompile it with "-O2 -fno-gcse" I get a properly
| functioning emacs build.
|
| Could you try to recompile unexelf.o without any optimizations, and
| see if this allows the resulting emacs to work just fine?
|
| Using this, I can determine whether we are seeing the same bug.

Thanks!

Unfortunately, even compiling all of emacs with -g
(or with empty CFLAGS) didn't change the result:

  Loading loaddefs.el...
  Loading vc-hooks (compiled)...
  Loading ediff-hook (compiled)...
  Finding pointers to doc strings...
  Finding pointers to doc strings...done
  Dumping under names emacs and emacs-20.2.2
  414008 pure bytes used
  ./emacs -q -batch -f list-load-path-shadows
  make: *** [emacs] Segmentation Fault

I'm pretty sure that whatever it is about egcs that provokes
this was introduced in the first two weeks of June.  The 980531
snapshot compiled it fine, and the first time I noticed the problem
was about two weeks later.