From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Anyone built Emacs with gcc-3.3? Date: Sun, 13 Jul 2003 22:52:44 -0700 (PDT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200307140552.h6E5qiW02148@sic.twinsun.com> References: <200307110955.h6B9tDY06306@sic.twinsun.com> <200307112252.h6BMqf009206@sic.twinsun.com> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1058162290 16544 80.91.224.249 (14 Jul 2003 05:58:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 14 Jul 2003 05:58:10 +0000 (UTC) Cc: simon.marshall@misys.com, emacs-pretesters@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jul 14 07:58:06 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19bwLe-0004Ib-00 for ; Mon, 14 Jul 2003 07:58:06 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19bwYl-0001ae-00 for ; Mon, 14 Jul 2003 08:11:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19bwJq-0007Rw-Tq for emacs-devel@quimby.gnus.org; Mon, 14 Jul 2003 01:56:14 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19bwIX-0005rJ-J2 for emacs-devel@gnu.org; Mon, 14 Jul 2003 01:54:53 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19bwIO-0005T2-BF for emacs-devel@gnu.org; Mon, 14 Jul 2003 01:54:47 -0400 Original-Received: from alcor.twinsun.com ([198.147.65.9]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19bwGf-0004Au-7x; Mon, 14 Jul 2003 01:52:58 -0400 Original-Received: from green.twinsun.com ([192.54.239.71]) by alcor.twinsun.com (8.12.6/8.12.6) with ESMTP id h6E5qjZ9001566; Sun, 13 Jul 2003 22:52:45 -0700 (PDT) Original-Received: from shade.twinsun.com (shade.twinsun.com [192.54.239.27]) by green.twinsun.com (8.11.7+Sun/8.11.7) with SMTP id h6E5qi014204; Sun, 13 Jul 2003 22:52:44 -0700 (PDT) Original-Received: from sic.twinsun.com ([192.54.239.17]) by shade.twinsun.com (SAVSMTP 3.1.0.29) with SMTP id M2003071322524412321 ; Sun, 13 Jul 2003 22:52:44 -0700 Original-Received: (from eggert@localhost) by sic.twinsun.com (8.11.7+Sun/8.11.7) id h6E5qiW02148; Sun, 13 Jul 2003 22:52:44 -0700 (PDT) Original-To: simon@limmat.switch.ch In-reply-to: (simon@limmat.switch.ch) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:15589 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:15589 > From: Simon Leinen > 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 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 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. */