Anyone built Emacs with gcc-3.3?

Anyone built Emacs with gcc-3.3?

[Marshall, Simon]

I've tried to build emacs-21.3 and 21.1.90 with gcc-3.3 on solaris-2.8
but without success.  Emacs builds but coredumps on exit, see bug #11386
at GCC Bugzilla via http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386.

Have any of you guys built with gcc-3.3 or any snapshot prior to its
release?  I ask because the bug looks like it might be tricky to track
down; the gcc guy dealing with it wants a lot more input; it's not clear
whether it is platform-dependent (the guy who got around to reporting it
before me is also on solaris-2.8).

Simon.

Re: Anyone built Emacs with gcc-3.3?

[Dhruva Krishnamurthy]

On Fri, 4 Jul 2003 09:33:49 +0100 , "Marshall, Simon"
<simon.marshall@misys.com> said:
> I've tried to build emacs-21.3 and 21.1.90 with gcc-3.3 on solaris-2.8
> but without success.  Emacs builds but coredumps on exit, see bug #11386
> at GCC Bugzilla via http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386.
> 
> Have any of you guys built with gcc-3.3 or any snapshot prior to its
> release?  I ask because the bug looks like it might be tricky to track
> down; the gcc guy dealing with it wants a lot more input; it's not clear
> whether it is platform-dependent (the guy who got around to reporting it
> before me is also on solaris-2.8).
> 
> Simon.

I had rised a similar BUG on W2K and Wolfgang Bangerth from GCC
responded. I did not have any other way to nail the cause, hence I gace
up.
Refer bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9816

with regards,
dhruva
-- 
Dhruva Krishnamurthy
Home: http://www32.brinkster.com/schemer/

Re: Anyone built Emacs with gcc-3.3?

[Nelson H. F. Beebe]

If any of you have an earlier version of gcc still installed after
installing gcc-3.3 (I kept 2.95.3 around), I suggest that you try to
debug the core dump problem by successively recompiling one file at a
time with the older gcc.  This can be automated with a modest script,
and I've found it a useful technique in the past to deal with compiler
errors in large programs.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- Center for Scientific Computing       FAX: +1 801 581 4148                  -
- University of Utah                    Internet e-mail: beebe@math.utah.edu  -
- Department of Mathematics, 110 LCB        beebe@acm.org  beebe@computer.org -
- 155 S 1400 E RM 233                       beebe@ieee.org                    -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
-------------------------------------------------------------------------------


-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- Center for Scientific Computing       FAX: +1 801 581 4148                  -
- University of Utah                    Internet e-mail: beebe@math.utah.edu  -
- Department of Mathematics, 110 LCB        beebe@acm.org  beebe@computer.org -
- 155 S 1400 E RM 233                       beebe@ieee.org                    -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
-------------------------------------------------------------------------------

Re: Anyone built Emacs with gcc-3.3?

[puneet]

I am using emacs on solaris 2.8. Right now I am using emacs from
CVS. Earlier on I had emacs 21.3 compiled with 64-bit gcc 3.3. And it
did not give any problems.

I have compiled emacs in gcc 3.3. Actually I configured gcc for
sparcv9 arch. And hence my emacs is 64-bit. I use it daily. I believe
I used gcc 3.3 only to install emacs as my emacs was installed later
than I installed the present gcc.

I will try compiling emacs with 32 bit gcc early next week, as I do
not have access to my solaris system at home.

Regards
- puneet

(emacs-version)
"GNU Emacs 21.3.50.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars)
 of 2003-06-27 on cheetah"

$ uname -a
SunOS cheetah 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-60 Solaris
$ file `which emacs`
/home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/bin/emacs: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), dynamically linked (uses shared libs), stripped
$ gcc -v
Reading specs from /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/gcc-lib/sparcv9-sun-solaris2.8/3.3/specs
Configured with: ../gcc-3.3/configure --disable-nls --enable-threads --enable-languages=c,c++,f77 --prefix=/home/pgoel/local/gnu --exec-prefix=${prefix}/arch/sparcv9-sun-solaris2.8 --host=sparcv9-sun-solaris2.8
Thread model: posix
gcc version 3.3
$ ls -la `which gcc`
-r-xr-xr-x    3 pgoel    staff      123608 2003-05-16 01:13 /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/bin/gcc
$ which emacs
/home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/bin/emacs
$ ls -la `which emacs`
-r-xr-xr-x    2 pgoel    staff    12604912 2003-06-27 03:53 /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/bin/emacs


>>>>> "Marshall" == Marshall, Simon <simon.marshall@misys.com> writes:

    Marshall> I've tried to build emacs-21.3 and 21.1.90 with gcc-3.3
    Marshall> on solaris-2.8 but without success.  Emacs builds but
    Marshall> coredumps on exit, see bug #11386 at GCC Bugzilla via
    Marshall> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386.

    Marshall> Have any of you guys built with gcc-3.3 or any snapshot
    Marshall> prior to its release?  I ask because the bug looks like
    Marshall> it might be tricky to track down; the gcc guy dealing
    Marshall> with it wants a lot more input; it's not clear whether
    Marshall> it is platform-dependent (the guy who got around to
    Marshall> reporting it before me is also on solaris-2.8).

    Marshall> Simon.

    Marshall> --

-- 

--
Puneet Goel

--
BLESSED is he whose fame does not
outshine his truth.
-
Stray Birds, Rabindernath Tagore

--

Re: Anyone built Emacs with gcc-3.3?

[Richard Stallman]

    I've tried to build emacs-21.3 and 21.1.90 with gcc-3.3 on solaris-2.8
    but without success.

Does it work with other GCC versions?

			  Emacs builds but coredumps on exit, see bug #11386
    at GCC Bugzilla via http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386.

Do you mean it core dumps when you type C-c C-c?

The way to debug this is to treat it as an Emacs bug.  When you
find the bug, it will actually be a miscompiled function (if this
is GCC's fault).  Then you can send a useful GCC bug report.

RE: Anyone built Emacs with gcc-3.3?

[Marshall, Simon]

Yes, Emacs works with 3.2.3.  With 3.3 it dumps core on C-x C-c in
__do_global_dtors_aux() after Fkill_emacs() calls exit().

-----Original Message-----
From: Richard Stallman [mailto:rms@gnu.org]
Sent: 05 July 2003 23:26
To: Marshall, Simon
Cc: emacs-devel@gnu.org; emacs-pretesters@gnu.org
Subject: Re: Anyone built Emacs with gcc-3.3?


    I've tried to build emacs-21.3 and 21.1.90 with gcc-3.3 on
solaris-2.8
    but without success.

Does it work with other GCC versions?

			  Emacs builds but coredumps on exit, see bug
#11386
    at GCC Bugzilla via
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386.

Do you mean it core dumps when you type C-c C-c?

The way to debug this is to treat it as an Emacs bug.  When you
find the bug, it will actually be a miscompiled function (if this
is GCC's fault).  Then you can send a useful GCC bug report.

Re: Anyone built Emacs with gcc-3.3?

[Richard Stallman]

    Yes, Emacs works with 3.2.3.  With 3.3 it dumps core on C-x C-c in
    __do_global_dtors_aux() after Fkill_emacs() calls exit().

I have a hunch that relates to unexec.  Perhaps unexec fails to
preserve some of the data that __do_global_dtors_aux uses.

Debugging the details is the only way to proceed.

Re: Anyone built Emacs with gcc-3.3?

[Jason Rumney]

Richard Stallman wrote:

>     Yes, Emacs works with 3.2.3.  With 3.3 it dumps core on C-x C-c in
>     __do_global_dtors_aux() after Fkill_emacs() calls exit().
> 
> I have a hunch that relates to unexec.  Perhaps unexec fails to
> preserve some of the data that __do_global_dtors_aux uses.
> 
> Debugging the details is the only way to proceed.

Someone else reported yesterday that a recent version of ld from 
binutils has changed the position of some of the data segments in ELF 
executables, causing problems with unexec. I think it is worth 
investigating if this is really the cause of the gcc 3.3 problems, as it 
could save a lot of debugging.

RE: Anyone built Emacs with gcc-3.3?

[Marshall, Simon]

> >     Yes, Emacs works with 3.2.3.  With 3.3 it dumps core on 
> C-x C-c in
> >     __do_global_dtors_aux() after Fkill_emacs() calls exit().
> > 
> > I have a hunch that relates to unexec.  Perhaps unexec fails to
> > preserve some of the data that __do_global_dtors_aux uses.
> > 
> > Debugging the details is the only way to proceed.

The guys who first raised it on bugzilla had the same hunch.  The
problem is: where do I start?  I can't debug in __do_global_dtors_aux()
as there is no debugging info.  Do I have to build libgcc.a with
debugging (or whatever it is that supplied __do_global_dtors_aux())?

> Someone else reported yesterday that a recent version of ld from 
> binutils has changed the position of some of the data segments in ELF 
> executables, causing problems with unexec. I think it is worth 
> investigating if this is really the cause of the gcc 3.3 
> problems, as it 
> could save a lot of debugging.

Thanks, though in my case I am using Sun as & ld (unless gcc comes with
a binutils ld and is quietly using it).

Re: Anyone built Emacs with gcc-3.3?

[Dave Love]

"Marshall, Simon" <simon.marshall@misys.com> writes:

> I've tried to build emacs-21.3 and 21.1.90 with gcc-3.3 on solaris-2.8
> but without success.  Emacs builds but coredumps on exit, see bug #11386
> at GCC Bugzilla via http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386.

That suggests it is dependent on data size.  I've seen similar
behaviour on Tru64 which was related to the use of mmap if I remember
correctly and never got resolved.  Also if I remember correctly, handa
had a similar problem on Solaris and resolved it on the basis of what
I said about the Tru64 problem, but I don't recall how.

For what it's worth, Emacs 21.3 appears to work on sparc64 with the
gcc pre-3.3.1 in Debian testing.

unexec problems are likely with a new gcc on ELF platforms.  To
investigate, I would run objdump or elfdump (?) on temacs versions
that work and don't work, looking for unexpected sections.  (You want
whatever option lists all the section headers.)  That might suggest
other things that need to be copied, for instance.  [In case that
turns out to be the case, let me say again that undumping should be
dumped.]

At one time, building Emacs was part of the regression testing for
gcc.  If that's been dropped, it seems like a backward move.

Re: Anyone built Emacs with gcc-3.3?

[Dave Love]

puneet <puneet@computer.org> writes:

> I have compiled emacs in gcc 3.3. Actually I configured gcc for
> sparcv9 arch. And hence my emacs is 64-bit.

That doesn't follow.  -mcpu=v9 is orthogonal to -m64.  `file' will
tell you whether the binary is 64-bit, but as far as I remember, you
won't get 64-bit Emacs words with gcc anyhow since gcc doesn't define
_LP64.  (gcc -m64 wasn't useful when I last touched 64-bit sparc
configuration.)  Somewhere I have some changes to somewhat sanitize
64-bit configuration, but as far as I know there are still some basic
problems with 64-bit systems, especially big-endian ones, and I'm
surprised they work at all...

If it behaves differently on different Solaris systems with the same
OS version then you should probably look at all the installed patches,
versions of development tools (I assume you use the Sun ld) and what
you pick up from the system libraries -- the version of malloc in
particular.

Re: Anyone built Emacs with gcc-3.3?

[Dhruva Krishnamurthy]

On Tue, 08 Jul 2003 15:39:47 +0100, "Jason Rumney" <jasonr@gnu.org> said:
> Richard Stallman wrote:
> 
> >     Yes, Emacs works with 3.2.3.  With 3.3 it dumps core on C-x C-c in
> >     __do_global_dtors_aux() after Fkill_emacs() calls exit().
> > 
> > I have a hunch that relates to unexec.  Perhaps unexec fails to
> > preserve some of the data that __do_global_dtors_aux uses.
> > 
> > Debugging the details is the only way to proceed.
> 
> Someone else reported yesterday that a recent version of ld from 
> binutils has changed the position of some of the data segments in ELF 
> executables, causing problems with unexec. I think it is worth 
> investigating if this is really the cause of the gcc 3.3 problems, as it 
> could save a lot of debugging.
> 

I had sent an email to the list:
----------------------------------------------------------------------------------------------
I had tried building GNU Emacs with GCC 3.3 and had encountered a
problem which I have raised as a bug in GCC bugzilla(#9816).
I tried again using a newer port of GCC 3.3 and GCC 3.4 (not an official
port though) from:
http://www.thisiscool.com/gcc33_mingw.htm

I am unable to build or even progress to get an emacs.exe (executable).
With the earlier port of GCC 3.3, I could build a bare emacs executable
which failed in compiling elisp files.
If someone has a link to a GCC 3.3 port on W2K (Win32/MinGW), please let
me know. I will try to do some extensive testing. Unfortunately, I do not
have the older GCC 3.3 port with me now!
----------------------------------------------------------------------------------------------
 As the problem is happening on Windows 2000 (W2K) platform, I feel it is
 not releted to 
unexec and specific to ELF. On W2K, I am not sure it uses 'ld' for
linking. So, modifications to 'ld' may not be the cause.

with regards,
dhruva
-- 
Dhruva Krishnamurthy
Web: http://schemer.fateback.com/

Re: Anyone built Emacs with gcc-3.3?

[Pascal Obry]

Dhruva,

 > I had sent an email to the list:
 > ----------------------------------------------------------------------------------------------
 > I had tried building GNU Emacs with GCC 3.3 and had encountered a
 > problem which I have raised as a bug in GCC bugzilla(#9816).
 > I tried again using a newer port of GCC 3.3 and GCC 3.4 (not an official
 > port though) from:
 > http://www.thisiscool.com/gcc33_mingw.htm
 > 
 > I am unable to build or even progress to get an emacs.exe (executable).
 > With the earlier port of GCC 3.3, I could build a bare emacs executable
 > which failed in compiling elisp files.
 > If someone has a link to a GCC 3.3 port on W2K (Win32/MinGW), please let
 > me know. I will try to do some extensive testing. Unfortunately, I do not
 > have the older GCC 3.3 port with me now!
 > ----------------------------------------------------------------------------------------------
 >  As the problem is happening on Windows 2000 (W2K) platform, I feel it is
 >  not releted to 
 > unexec and specific to ELF. On W2K, I am not sure it uses 'ld' for
 > linking. So, modifications to 'ld' may not be the cause.

'ld' is used on Windows.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Anyone built Emacs with gcc-3.3?

[Jason Rumney]

"Dhruva Krishnamurthy" <seagull@fastmail.fm> writes:

>  As the problem is happening on Windows 2000 (W2K) platform, I feel it is
>  not releted to unexec and specific to ELF.

Right.

> On W2K, I am not sure it uses 'ld' for linking.

If gcc is used for compiling, then ld is used for linking. But the
executable format is COFF on Windows IIRC, not ELF.

> So, modifications to 'ld' may not be the cause.

Maybe, but since the problem with ld has already been proven, perhaps
we should fix that first, and see if it makes a difference.

Re: Anyone built Emacs with gcc-3.3?

[Puneet Goel]

>>>>> "Dave" == Dave Love <d.love@dl.ac.uk> writes:

    Dave> puneet <puneet@computer.org> writes:
    >> I have compiled emacs in gcc 3.3. Actually I configured gcc for
    >> sparcv9 arch. And hence my emacs is 64-bit.

    Dave> That doesn't follow.  -mcpu=v9 is orthogonal to -m64.

    Sorry, I did not know that. For record, I am not a software
    engineer. I am a hardware professional. And I needed 64-bit emacs
    to read big files. I do use gcc -m64 for building my emacs. I try
    building 64-bit emacs from emacs CVS almost once a week. Never
    faced a problem.

    I think I first successfully built 64-bit emacs some three months
    back. That was the time when our sys-admin upgraded my sparc
    machine to solaris 2.8. Our sys-admin is on leave, and I do not
    know a way to get patch information on my system. I believe he
    installed just the recommended patches from Sun.

    So I have been compiling and running 64-bit emacs versions 21.X
    and 21.3.50 on my solaris 2.8 for the past three months now
    without any issue. The only issue I face is when I set my display
    to a linux system, and launch 64-bit emacs on that display, emacs
    dumps core. 32-bit solaris emacs compiles work fine.

    I am sure that my emacs is 64-bit because ....

    1. I use gcc -m64 to compile that.
    2. I am able to open BIG files (200MB and more) with this
       emacs. 32-bit emacs gives "Maximum buffer size exceeded" for
       the same files.
    3. I had to compile 64-bit versions of all the required
       libraries. And my emacs is linked to 64-bit versions of sun
       libraries. here is the ldd output ....
$ ldd /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/bin/emacs
        libXaw3d.so.5 =>         /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libXaw3d.so.5
        libXmu.so.4 =>   /usr/lib/64/libXmu.so.4
        libXt.so.4 =>    /usr/lib/64/libXt.so.4
        libSM.so.6 =>    /usr/lib/64/libSM.so.6
        libICE.so.6 =>   /usr/lib/64/libICE.so.6
        libXext.so.0 =>  /usr/lib/64/libXext.so.0
        libtiff.so =>    /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libtiff.so
        libjpeg.so.62 =>         /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libjpeg.so.62
        libpng.so.3 =>   /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libpng.so.3
        libz.so =>       /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libz.so  
        libm.so.1 =>     /usr/lib/64/libm.so.1
        libungif.so.4 =>         /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libungif.so.4
        libXpm.so.4.11 =>        /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libXpm.so.4.11
        libX11.so.4 =>   /usr/lib/64/libX11.so.4
        libsocket.so.1 =>        /usr/lib/64/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/64/libnsl.so.1
        libkstat.so.1 =>         /usr/lib/64/libkstat.so.1
        libcurses.so.1 =>        /usr/lib/64/libcurses.so.1
        libc.so.1 =>     /usr/lib/64/libc.so.1
        libICE.so.6 (SUNWprivate) =>     (version not found)
        libICE.so.6 (SUNWprivate) =>     (version not found)
        libdl.so.1 =>    /usr/lib/64/libdl.so.1
        libdga.so.1 =>   /usr/openwin/lib/sparcv9/libdga.so.1
        libgcc_s.so.1 =>         /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/sparcv9/libgcc_s.so.1
        libmp.so.2 =>    /usr/lib/64/libmp.so.2
        /usr/platform/SUNW,Ultra-60/lib/sparcv9/libc_psr.so.1



    Dave> 
    Dave> `file' will tell you whether the binary is 64-bit, but as
    Dave> far as I remember, you won't get 64-bit Emacs words with gcc
    Dave> anyhow since gcc doesn't define _LP64.  (gcc -m64 wasn't
    Dave> useful when I last touched 64-bit sparc configuration.)

          Well file does say that it is 64-bit version.

    Dave> 
    Dave> Somewhere I have some changes to somewhat sanitize 64-bit
    Dave> configuration, but as far as I know there are still some
    Dave> basic problems with 64-bit systems, especially big-endian
    Dave> ones, and I'm surprised they work at all...

          I am not competent to comment on these. The first time I
          compiled 64-bit emacs was sometimes in oct 2002. RMS had put
          a request on the emacs-pretesters list for testing on 64 bit
          machines. At that time, I could compile emacs. I could even
          run it with "emacs -nw". X11 emacs used to dump core. It
          seemed to be some openwin internal error. I had reported
          all this on the emacs-pretesters list.

          Now I work for a different organization. And 64-bit emacs
          compiles have been running fine since last 3 months. I use
          64-bit emacs for almost everything (including gnus etc.)

    Dave> If it behaves differently on different Solaris systems with
    Dave> the same OS version then you should probably look at all the
    Dave> installed patches, versions of development tools (I assume
    Dave> you use the Sun ld) and what you pick up from the system
    Dave> libraries -- the version of malloc in particular.

          I do use sun ld. I do not know how to check for which
          malloc I am using. Should I send you the config.log file??

    Dave> --

Regards
- p

--
Puneet Goel
TranSwitch India
--
LEAD me in the centre of thy silence
to fill my heart with songs.
-
Stray Birds, Rabindernath Tagore

--

Re: Anyone built Emacs with gcc-3.3?

[Richard Stallman]

    The guys who first raised it on bugzilla had the same hunch.  The
    problem is: where do I start?  I can't debug in __do_global_dtors_aux()
    as there is no debugging info.

I think it has to be debugged at the assembler level anyway.
(That function is probably very simple--just look at the source
and you will see.)

Re: Anyone built Emacs with gcc-3.3?

[Paul Eggert]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 05 Jul 2003 18:25:56 -0400
> 
> The way to debug this is to treat it as an Emacs bug.  When you
> find the bug, it will actually be a miscompiled function (if this
> is GCC's fault).  Then you can send a useful GCC bug report.

I looked into this a bit, and there seem to be at least two problems.
One is an Emacs portability problem; the rest I don't know yet.

Emacs assumes that a top-level declaration like "int pure[1000] = {0};"
puts "pure" into the data area.  However, this assumption is no longer
true with GCC 3.3 on Solaris 8, which notices that "pure" has an
initializer that is all zeros, and puts "pure" into BSS instead.
This is a valid optimization, so I guess Emacs should deal with it.

I checked for all static variables that Emacs 21.3 defines to be zero
in Solaris 8, and which become readonly after dumping with GCC 3.2.3
but not with GCC 3.3, and I came up with the following patch to fix
this portability problem.  This fixes part of the bug, but not all;
Emacs still dumps core.  I'll see if I can investigate this further if
I find more time but that won't be before this weekend.

2003-07-11  Paul Eggert  <eggert@twinsun.com>

	GCC 3.3 no longer puts "int foo = 0;" into data; it optimizes
	this case and puts it into BSS instead, at least on Solaris 8.
	* src/alloc.c (pure, staticvec, staticidx):
	Initialize to nonzero, so that it's data.
	* src/emacs.c (bss_end): Likewise.
	(main): Use bss_end==1 to mean it's unset.

	The following changes don't fix any bugs, but they remove
	initializations to zero that do not need to be in pure space.
	I am including them in this patch (if only to document them).
	* src/emacs.c (gdb_data_seg_bits): Do not initialize to zero
	explicitly, since it's OK for this to be in BSS.
	* src/xfns.c (cursor_bits): Likewise.
	* src/xterm.c (Xt_default_resources): Likewise.

diff -pru emacs-21.3/src/alloc.c emacs-21.3-fix/src/alloc.c
--- emacs-21.3/src/alloc.c	2003-01-17 05:45:13.000000000 -0800
+++ emacs-21.3-fix/src/alloc.c	2003-07-11 02:02:37.215626000 -0700
@@ -188,7 +188,7 @@ Lisp_Object Vpurify_flag;
 
 /* Force it into data space! */
 
-EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {0,};
+EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {1,};
 #define PUREBEG (char *) pure
 
 #else /* not HAVE_SHM */
@@ -395,11 +395,11 @@ struct gcpro *gcprolist;
 /* Addresses of staticpro'd variables.  */
 
 #define NSTATICS 1024
-Lisp_Object *staticvec[NSTATICS] = {0};
+Lisp_Object *staticvec[NSTATICS] = {1};
 
 /* Index of next unused slot in staticvec.  */
 
-int staticidx = 0;
+int staticidx = 1;
 
 static POINTER_TYPE *pure_alloc P_ ((size_t, int));
 
diff -pru emacs-21.3/src/emacs.c emacs-21.3-fix/src/emacs.c
--- emacs-21.3/src/emacs.c	2002-08-29 12:27:07.000000000 -0700
+++ emacs-21.3-fix/src/emacs.c	2003-07-11 01:39:19.348060000 -0700
@@ -86,7 +86,7 @@ EMACS_INT gdb_emacs_intbits = sizeof (EM
 #ifdef DATA_SEG_BITS
 EMACS_INT gdb_data_seg_bits = DATA_SEG_BITS;
 #else
-EMACS_INT  gdb_data_seg_bits = 0;
+EMACS_INT gdb_data_seg_bits /* = 0 */;
 #endif
 EMACS_INT PVEC_FLAG = PSEUDOVECTOR_FLAG;
 
@@ -188,10 +188,10 @@ extern Lisp_Object Vwindow_system;
 extern Lisp_Object Vauto_save_list_file_name;
 
 #ifdef USG_SHARED_LIBRARIES
-/* If nonzero, this is the place to put the end of the writable segment
+/* If not 1, this is the place to put the end of the writable segment
    at startup.  */
 
-unsigned int bss_end = 0;
+unsigned int bss_end = 1;
 #endif
 
 /* Nonzero means running Emacs without interactive terminal.  */
@@ -856,7 +856,7 @@ main (argc, argv, envp)
   stack_bottom = &stack_bottom_variable;
 
 #ifdef USG_SHARED_LIBRARIES
-  if (bss_end)
+  if (bss_end != 1)
     brk ((void *)bss_end);
 #endif
 
diff -pru emacs-21.3/src/xfns.c emacs-21.3-fix/src/xfns.c
--- emacs-21.3/src/xfns.c	2002-12-06 09:05:35.000000000 -0800
+++ emacs-21.3-fix/src/xfns.c	2003-07-11 01:26:46.669033000 -0700
@@ -3954,13 +3954,7 @@ x_icon (f, parms)
    background, border and mouse colors; also create the
    mouse cursor and the gray border tile.  */
 
-static char cursor_bits[] =
-  {
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-  };
+static char cursor_bits[32];
 
 static void
 x_make_gc (f)
diff -pru emacs-21.3/src/xterm.c emacs-21.3-fix/src/xterm.c
--- emacs-21.3/src/xterm.c	2002-10-15 07:21:45.000000000 -0700
+++ emacs-21.3-fix/src/xterm.c	2003-07-11 01:25:07.789266000 -0700
@@ -284,7 +284,7 @@ struct frame *pending_autoraise_frame;
 #ifdef USE_X_TOOLKIT
 /* The application context for Xt use.  */
 XtAppContext Xt_app_con;
-static String Xt_default_resources[] = {0};
+static String Xt_default_resources[1];
 #endif /* USE_X_TOOLKIT */
 
 /* Nominal cursor position -- where to draw output.  

Re: Anyone built Emacs with gcc-3.3?

[Paul Eggert]

> From: "Marshall, Simon" <simon.marshall@misys.com>
> Date: Tue, 8 Jul 2003 16:18:10 +0100 
> 
> I can't debug in __do_global_dtors_aux()
> as there is no debugging info.

I am using the GDB "disas" command to disassemble
__do_global_dtors_aux into SPARC instructions.
(It's not a lot of fun.)

Re: Anyone built Emacs with gcc-3.3?

[Paul Eggert]

I found the other bug that was preventing Emacs 21.3 from building
with GCC 3.3 on Solaris 8 (sparc).  Here is a patch.  When I installed
this patch, together with the patch I sent earlier today, Emacs built
and installed on Solaris 8 with GCC 3.3, and ran OK on some simple
tests.

2003-07-11  Paul Eggert  <eggert@twinsun.com>

	* unexelf.c (unexec): Consider a section to precede the .bss
	section if its addresses overlap that of .bss.  This fixes the
	bug reported by Simon Marshall in
	<http://mail.gnu.org/archive/html/emacs-devel/2003-07/msg00033.html>,
	if you also install the patch that I submitted yesterday in
	<http://mail.gnu.org/archive/html/emacs-devel/2003-07/msg00207.html>.
	This patch is related to my 1996-06-24 patch to unexelf.c
	<http://www.geocrawler.com/archives/3/337/1996/6/0/1851704/>,
	but it uses a more precise heuristic for deciding when the other
	section precedes the .bss section.

--- emacs-21.3/src/unexelf.c	2002-10-15 07:21:44.000000000 -0700
+++ emacs-21.3-fix/src/unexelf.c	2003-07-11 14:59:48.649294000 -0700
@@ -971,8 +971,13 @@ unexec (new_name, old_name, data_start, 
 	}
       else
 	{
-	  /* Any section that was original placed AFTER the bss
-	     section should now be off by NEW_DATA2_SIZE. */
+	  /* Any section that was originally placed after the .bss
+	     section should now be off by NEW_DATA2_SIZE.  If a
+	     section overlaps the .bss section, consider it to be
+	     placed after the .bss section.  Overlap can occur if the
+	     section just before .bss has less-strict alignment; this
+	     was observed between .symtab and .bss on Solaris 2.5.1
+	     (sparc) with GCC snapshot 960602.  */
 #ifdef SOLARIS_POWERPC
 	  /* On PPC Reference Platform running Solaris 2.5.1
 	     the plt section is also of type NOBI like the bss section.
@@ -986,9 +991,8 @@ unexec (new_name, old_name, data_start, 
 	      >= OLD_SECTION_H (old_bss_index-1).sh_offset)
 	    NEW_SECTION_H (nn).sh_offset += new_data2_size;
 #else
-	  if (round_up (NEW_SECTION_H (nn).sh_offset,
-			OLD_SECTION_H (old_bss_index).sh_addralign)
-	      >= new_data2_offset)
+	  if (NEW_SECTION_H (nn).sh_offset + NEW_SECTION_H (nn).sh_size
+	      > new_data2_offset)
 	    NEW_SECTION_H (nn).sh_offset += new_data2_size;
 #endif
 	  /* Any section that was originally placed after the section

Re: Anyone built Emacs with gcc-3.3?

[Richard Stallman]

Thanks.  Would someone please install these changes?

Re: Anyone built Emacs with gcc-3.3?

[Simon Leinen]

Paul,

THANK YOU! Your two patches makes Emacs 21.3 work well for me on
Solaris 9 in 64-bit mode using GCC 3.3.

Do you think it would be useful for me to test your patches in other
compilation modes as well?

Regards,
-- 
Simon.

Re: Anyone built Emacs with gcc-3.3?

[Paul Eggert]

> From: Simon Leinen <simon@limmat.switch.ch>
> Date: Sun, 13 Jul 2003 16:56:09 +0200
> 
> Do you think it would be useful for me to test your patches in other
> compilation modes as well?

I am testing 32-bit Solaris sparc (both Solaris 8 and 9) in everyday
use, so you needn't bother with those cases.  It'd be nice to test it
on older Solaris releases.

However, I discovered that the zero-initializer changes
<http://mail.gnu.org/archive/html/emacs-devel/2003-07/msg00207.html>
are not needed on Solaris 8 or 9, since unexelf.c does not attempt to
make any of the initialized data read-only.

On further thought, those changes are not urgent: they are only an
optimization, and they help only on hosts where dumping the 'pure'
array into readonly text is a real performance win.  This used to be a
big deal (15 years ago, say), but I suspect it's not that important
these days.  Certainly small things like scalars are not worth
worrying about now, from a performance viewpoint; only arrays like
'pure' matter.

Since the zero-initializer changes don't fix any real bug that I know
of, I didn't install them into the RC branch.  And I omitted the
proposed changes to scalars, leaving only the following small change
that I just installed into the trunk.

2003-07-13  Paul Eggert  <eggert@twinsun.com>

	GCC 3.3 (sparc) no longer puts "int foo = 0;" into data; it
	puts it into BSS instead, at least on Solaris 8 and 9.
	This is a valid optimization, and it may occur on other platforms,
	so Emacs should not assume that initializing a static variable to
	zero puts it into data.
	* alloc.c (pure, staticvec):
	Initialize these arrays to nonzero, so that they're not
	put into BSS by that optimization.

Index: alloc.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/alloc.c,v
retrieving revision 1.314
retrieving revision 1.315
diff -p -u -r1.314 -r1.315
--- alloc.c	14 Jul 2003 02:51:08 -0000	1.314
+++ alloc.c	14 Jul 2003 05:37:52 -0000	1.315
@@ -185,9 +185,10 @@ Lisp_Object Vmemory_full;
 
 #ifndef HAVE_SHM
 
-/* Force it into data space! */
+/* Force it into data space!  Initialize it to a nonzero value;
+   otherwise some compilers put it into BSS.  */
 
-EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {0,};
+EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {1,};
 #define PUREBEG (char *) pure
 
 #else /* HAVE_SHM */
@@ -404,10 +405,11 @@ static void check_gcpros P_ ((void));
 
 struct gcpro *gcprolist;
 
-/* Addresses of staticpro'd variables.  */
+/* Addresses of staticpro'd variables.  Initialize it to a nonzero
+   value; otherwise some compilers put it into BSS.  */
 
 #define NSTATICS 1280
-Lisp_Object *staticvec[NSTATICS] = {0};
+Lisp_Object *staticvec[NSTATICS] = {&Vpurify_flag};
 
 /* Index of next unused slot in staticvec.  */

RE: Anyone built Emacs with gcc-3.3?

[Marshall, Simon]

Paul, thanks.  I can confirm that Emacs builds OK for me on s8 with
gcc-3.3 with the below Emacs patches plus your unexelf.c patch.  (Eric's
patch was not relevant for me anyway as I don't build with Xaw.)

I do get a gripe though:

alloc.c:398: warning: initialization makes pointer from integer without
a cast

due to this change:

-Lisp_Object *staticvec[NSTATICS] = {0};
+Lisp_Object *staticvec[NSTATICS] = {1};

Casting 1 with (Lisp_Object *) keeps gcc happy; so does removing the
initialisation.  I'll leave someone else to work out the correct way to
deal with this.

Thanks to everyone for sorting this out.  Simon.

-----Original Message-----
From: Marshall, Simon 
Sent: 11 July 2003 11:38
To: 'Paul Eggert'
Cc: 'ebotcazou@gcc.gnu.org'; 'ishikawa@yk.rim.or.jp'
Subject: RE: Anyone built Emacs with gcc-3.3?


Paul, many thanks.  FYI, I put your email on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386, seeing as they have
also looked at it with objdump.  Your input may help them and vice
versa.
I hope this can be fixed for 3.3.1, rather than the target 3.3.2.
Simon.

-----Original Message-----
From: Paul Eggert [mailto:eggert@twinsun.com]
Sent: 11 July 2003 10:55
To: rms@gnu.org
Cc: simon.marshall@misys.com; emacs-devel@gnu.org;
emacs-pretesters@gnu.org
Subject: Re: Anyone built Emacs with gcc-3.3?


> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 05 Jul 2003 18:25:56 -0400
> 
> The way to debug this is to treat it as an Emacs bug.  When you
> find the bug, it will actually be a miscompiled function (if this
> is GCC's fault).  Then you can send a useful GCC bug report.

I looked into this a bit, and there seem to be at least two problems.
One is an Emacs portability problem; the rest I don't know yet.

Emacs assumes that a top-level declaration like "int pure[1000] = {0};"
puts "pure" into the data area.  However, this assumption is no longer
true with GCC 3.3 on Solaris 8, which notices that "pure" has an
initializer that is all zeros, and puts "pure" into BSS instead.
This is a valid optimization, so I guess Emacs should deal with it.

I checked for all static variables that Emacs 21.3 defines to be zero
in Solaris 8, and which become readonly after dumping with GCC 3.2.3
but not with GCC 3.3, and I came up with the following patch to fix
this portability problem.  This fixes part of the bug, but not all;
Emacs still dumps core.  I'll see if I can investigate this further if
I find more time but that won't be before this weekend.

2003-07-11  Paul Eggert  <eggert@twinsun.com>

	GCC 3.3 no longer puts "int foo = 0;" into data; it optimizes
	this case and puts it into BSS instead, at least on Solaris 8.
	* src/alloc.c (pure, staticvec, staticidx):
	Initialize to nonzero, so that it's data.
	* src/emacs.c (bss_end): Likewise.
	(main): Use bss_end==1 to mean it's unset.

	The following changes don't fix any bugs, but they remove
	initializations to zero that do not need to be in pure space.
	I am including them in this patch (if only to document them).
	* src/emacs.c (gdb_data_seg_bits): Do not initialize to zero
	explicitly, since it's OK for this to be in BSS.
	* src/xfns.c (cursor_bits): Likewise.
	* src/xterm.c (Xt_default_resources): Likewise.

diff -pru emacs-21.3/src/alloc.c emacs-21.3-fix/src/alloc.c
--- emacs-21.3/src/alloc.c	2003-01-17 05:45:13.000000000 -0800
+++ emacs-21.3-fix/src/alloc.c	2003-07-11 02:02:37.215626000 -0700
@@ -188,7 +188,7 @@ Lisp_Object Vpurify_flag;
 
 /* Force it into data space! */
 
-EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {0,};
+EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {1,};
 #define PUREBEG (char *) pure
 
 #else /* not HAVE_SHM */
@@ -395,11 +395,11 @@ struct gcpro *gcprolist;
 /* Addresses of staticpro'd variables.  */
 
 #define NSTATICS 1024
-Lisp_Object *staticvec[NSTATICS] = {0};
+Lisp_Object *staticvec[NSTATICS] = {1};
 
 /* Index of next unused slot in staticvec.  */
 
-int staticidx = 0;
+int staticidx = 1;
 
 static POINTER_TYPE *pure_alloc P_ ((size_t, int));
 
diff -pru emacs-21.3/src/emacs.c emacs-21.3-fix/src/emacs.c
--- emacs-21.3/src/emacs.c	2002-08-29 12:27:07.000000000 -0700
+++ emacs-21.3-fix/src/emacs.c	2003-07-11 01:39:19.348060000 -0700
@@ -86,7 +86,7 @@ EMACS_INT gdb_emacs_intbits = sizeof (EM
 #ifdef DATA_SEG_BITS
 EMACS_INT gdb_data_seg_bits = DATA_SEG_BITS;
 #else
-EMACS_INT  gdb_data_seg_bits = 0;
+EMACS_INT gdb_data_seg_bits /* = 0 */;
 #endif
 EMACS_INT PVEC_FLAG = PSEUDOVECTOR_FLAG;
 
@@ -188,10 +188,10 @@ extern Lisp_Object Vwindow_system;
 extern Lisp_Object Vauto_save_list_file_name;
 
 #ifdef USG_SHARED_LIBRARIES
-/* If nonzero, this is the place to put the end of the writable segment
+/* If not 1, this is the place to put the end of the writable segment
    at startup.  */
 
-unsigned int bss_end = 0;
+unsigned int bss_end = 1;
 #endif
 
 /* Nonzero means running Emacs without interactive terminal.  */
@@ -856,7 +856,7 @@ main (argc, argv, envp)
   stack_bottom = &stack_bottom_variable;
 
 #ifdef USG_SHARED_LIBRARIES
-  if (bss_end)
+  if (bss_end != 1)
     brk ((void *)bss_end);
 #endif
 
diff -pru emacs-21.3/src/xfns.c emacs-21.3-fix/src/xfns.c
--- emacs-21.3/src/xfns.c	2002-12-06 09:05:35.000000000 -0800
+++ emacs-21.3-fix/src/xfns.c	2003-07-11 01:26:46.669033000 -0700
@@ -3954,13 +3954,7 @@ x_icon (f, parms)
    background, border and mouse colors; also create the
    mouse cursor and the gray border tile.  */
 
-static char cursor_bits[] =
-  {
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-  };
+static char cursor_bits[32];
 
 static void
 x_make_gc (f)
diff -pru emacs-21.3/src/xterm.c emacs-21.3-fix/src/xterm.c
--- emacs-21.3/src/xterm.c	2002-10-15 07:21:45.000000000 -0700
+++ emacs-21.3-fix/src/xterm.c	2003-07-11 01:25:07.789266000 -0700
@@ -284,7 +284,7 @@ struct frame *pending_autoraise_frame;
 #ifdef USE_X_TOOLKIT
 /* The application context for Xt use.  */
 XtAppContext Xt_app_con;
-static String Xt_default_resources[] = {0};
+static String Xt_default_resources[1];
 #endif /* USE_X_TOOLKIT */
 
 /* Nominal cursor position -- where to draw output.  

Re: Anyone built Emacs with gcc-3.3?

[Eric Botcazou]

> I thought an additional
>  post explaining the resolution (Paul's patch to
> emacs initialization statement and to unexelf.c)
> and pointing to appropriate URL of the mailing
> list archive would be helpful.

Please add these informations to the GCC bugzilla entry. I don't think the 
"resolved" state prevents this.

Thanks.

-- 
Eric Botcazou

Re: Anyone built Emacs with gcc-3.3?

[Paul Eggert]

> From: "Marshall, Simon" <simon.marshall@misys.com>
> Date: Mon, 14 Jul 2003 12:19:12 +0100
> 
> alloc.c:398: warning: initialization makes pointer from integer without
> a cast

Yes, thanks: I fixed that by using the following instead in the
version that I checked into the Emacs trunk:

Lisp_Object *staticvec[NSTATICS] = {&Vpurify_flag};


> Date: Mon, 14 Jul 2003 23:06:31 +0900
> From: Ishikawa <ishikawa@yk.rim.or.jp>

> (Strangely, I didn't have to apply the patch Eric posted. I suspect
> that there may be a factor due to different version of Sun's ld. 

As I understand it, the bug does not always occur: it depends on the
layouts of the earlier segments.  So it's possible that Eric's patch
happened to fix the problem for his particular alignment, even though
it shouldn't fix the problem in general (and didn't work for me).

> I didn't notice the warning Simon caught because I was
> so ecstatic that "make" ended successfully.
> I should have scrolled up a little bit to see some warning messages.

Yes, that's what happened with me too.

Re: Anyone built Emacs with gcc-3.3?

[Eric Botcazou]

> As I understand it, the bug does not always occur: it depends on the
> layouts of the earlier segments.  So it's possible that Eric's patch
> happened to fix the problem for his particular alignment, even though
> it shouldn't fix the problem in general (and didn't work for me).

Yes, and I recently learnt that this whole business could simply be avoided 
by specifying -fno-zero-initialized-in-bss on the command line...

-- 
Eric Botcazou

Re: Anyone built Emacs with gcc-3.3?

[Dave Love]

Puneet Goel <pgoel@txc.stpn.soft.net> writes:

>     I am sure that my emacs is 64-bit because ....
>
>     1. I use gcc -m64 to compile that.

Right, that's the relevant option with gcc.  I mentioned it to try to
avoid confusion.  Sorry I misremembered that I did make it work on
SPARC, although gcc supposedly didn't generate reliable code at the
time.

>           I do use sun ld. I do not know how to check for which
>           malloc I am using. Should I send you the config.log file??

Actually, that wasn't relevant, because Solaris uses gmalloc now --
something else I mis-remembered.