unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@twinsun.com>
Cc: simon.marshall@misys.com, emacs-pretesters@gnu.org, emacs-devel@gnu.org
Subject: Re: Anyone built Emacs with gcc-3.3?
Date: Sun, 13 Jul 2003 22:52:44 -0700 (PDT)	[thread overview]
Message-ID: <200307140552.h6E5qiW02148@sic.twinsun.com> (raw)
In-Reply-To: <aa7k6mlbli.fsf@limmat.switch.ch> (simon@limmat.switch.ch)

> 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.  */

  reply	other threads:[~2003-07-14  5:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-04  8:33 Anyone built Emacs with gcc-3.3? Marshall, Simon
2003-07-04  8:41 ` Dhruva Krishnamurthy
2003-07-04 16:17 ` puneet
2003-07-08 22:41   ` Dave Love
2003-07-09 12:31     ` Puneet Goel
2003-07-15 22:31       ` Dave Love
2003-07-05 22:25 ` Richard Stallman
2003-07-11  9:55   ` Paul Eggert
2003-07-11 22:52     ` Paul Eggert
2003-07-13 14:56       ` Simon Leinen
2003-07-14  5:52         ` Paul Eggert [this message]
2003-07-12  5:32     ` Richard Stallman
2003-07-08 22:30 ` Dave Love
  -- strict thread matches above, loose matches on Subject: below --
2003-07-04 12:36 Nelson H. F. Beebe
2003-07-07  8:26 Marshall, Simon
2003-07-08 14:28 ` Richard Stallman
2003-07-08 14:39   ` Jason Rumney
2003-07-09  5:34     ` Dhruva Krishnamurthy
2003-07-09  7:36       ` Pascal Obry
2003-07-09  7:59       ` Jason Rumney
2003-07-08 15:18 Marshall, Simon
2003-07-09 15:49 ` Richard Stallman
2003-07-11  9:57 ` Paul Eggert
2003-07-14 11:19 Marshall, Simon
     [not found] ` <3F12B8E7.2C387FE7@yk.rim.or.jp>
2003-07-14 14:41   ` Eric Botcazou
2003-07-14 17:47 ` Paul Eggert
2003-07-14 19:40   ` Eric Botcazou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200307140552.h6E5qiW02148@sic.twinsun.com \
    --to=eggert@twinsun.com \
    --cc=emacs-devel@gnu.org \
    --cc=emacs-pretesters@gnu.org \
    --cc=simon.marshall@misys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).