[Bug optimization/11386] GNU Emacs 21.3 failed to install using GCC 3.3, but GCC 3.2.3 works.

["ishikawa at yk dot rim dot or dot jp" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386



------- Additional Comments From ishikawa at yk dot rim dot or dot jp  2003-07-04 20:59 -------
Hi,
Since there are about a hundred C source files under emacs-21.3/src/, 
it will be sometime before I can pinpoint the file which caused
the problem.  (Not all of them are used for solaris port, but
it certainly takes time to check each file.)

One other thing, I am more inclined to think that
this is a subtle startup memory layout problem.
I will dig deeper into crtstuff.c, and config/sparc/* changes
between 3.2.3 and 3.3.

For those unfamiliar what unexec() does, I would suggest the following URLs.

Emacs building.
http://www.gnu.org/manual/elisp/html_node/elisp_715.html

Very early reference to the dump/unexec().
http://www.geocrawler.com/archives/3/357/1992/7/0/1995073/

XEmacs also uses unexec(). 
One XEmacs user bug report showing how a subtle change in the
output binary format breaks dumping/unexec().
http://list-archive.xemacs.org/xemacs-patches/200005/msg00064.html

Knuth's TeX used to use dump/unexec, but no longer uses it.
This is because the modern hardware is deemed fast enough to
read/load external data (macro packages) at each startup.

I agree that dumping binary image using unexec() for subsequent
faster startup is full of perils depending on the binary format
peculiarities, and indeed it breaks when a new OS is introduced, etc..

But given the popularity of UltraSparc Solaris 8, I wish
we can find a solution. 

As per suggestion, I will try to check if compiling some files -O0 solves the
problem
and in the meantime check the Emacs community to see
if someone analyzes the problem and find the root cause of the problem.

Thank you again.