From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.comp.gcc.patches,gmane.emacs.devel Subject: Re: (RFC) GCC minor document change: gcc.1 Date: Tue, 15 Jul 2003 00:34:21 -0700 (PDT) Sender: gcc-patches-owner@gcc.gnu.org Message-ID: <200307150734.h6F7YLi13759@green.twinsun.com> References: <9EF8DA0A-B656-11D7-8A0C-000393A6D2F2@physics.uc.edu> <3F1344D4.9BCA454@yk.rim.or.jp> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1058254417 13810 80.91.224.249 (15 Jul 2003 07:33:37 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 15 Jul 2003 07:33:37 +0000 (UTC) Cc: gcc-patches@gcc.gnu.org, emacs-pretesters@gnu.org, emacs-devel@gnu.org, ebotcazou@gcc.gnu.org Original-X-From: gcc-patches-return-92302-gcc-patches=m.gmane.org@gcc.gnu.org Tue Jul 15 09:33:35 2003 Return-path: Original-Received: from sources.redhat.com ([67.72.78.213]) by main.gmane.org with smtp (Exim 3.35 #1 (Debian)) id 19cKJb-0003aE-00 for ; Tue, 15 Jul 2003 09:33:35 +0200 Original-Received: (qmail 26754 invoked by alias); 15 Jul 2003 07:34:28 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Archive: List-Post: List-Help: Original-Received: (qmail 26739 invoked from network); 15 Jul 2003 07:34:23 -0000 Original-Received: from unknown (HELO alcor.twinsun.com) (198.147.65.9) by sources.redhat.com with SMTP; 15 Jul 2003 07:34:23 -0000 Original-Received: from green.twinsun.com ([192.54.239.71]) by alcor.twinsun.com (8.12.6/8.12.6) with ESMTP id h6F7YMlV023751; Tue, 15 Jul 2003 00:34:22 -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 h6F7YLi13762; Tue, 15 Jul 2003 00:34:21 -0700 (PDT) Original-Received: from green.twinsun.com ([192.54.239.71]) by shade.twinsun.com (SAVSMTP 3.1.0.29) with SMTP id M2003071500342122700 ; Tue, 15 Jul 2003 00:34:21 -0700 Original-Received: (from eggert@localhost) by green.twinsun.com (8.11.7+Sun/8.11.7) id h6F7YLi13759; Tue, 15 Jul 2003 00:34:21 -0700 (PDT) Original-To: ishikawa@yk.rim.or.jp In-reply-to: <3F1344D4.9BCA454@yk.rim.or.jp> (ishikawa@yk.rim.or.jp) Xref: main.gmane.org gmane.comp.gcc.patches:37250 gmane.emacs.devel:15617 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:15617 > Date: Tue, 15 Jul 2003 09:03:32 +0900 > From: Ishikawa > ! This option turns off this behavior because some programs, > ! most notably GNU Emacs 21.3 and prior versions, > ! explicitly > rely on variables going to the data section. This statement is misleading, for two reasons. First, this is merely an efficiency issue for Emacs; it is not a correct-behavior issue. Second, I don't know of any real hosts where the efficiency issue actually arises. I am mainly responsible for this misunderstanding, since I originally sent incorrect messages to emacs-devel and emacs-pretesters implying that -fno-zero-initialized-in-bss caused the core dump on Solaris 8. (I was wrong: the real bug was in Emacs's src/unexelf.c.) So I'd like to make amends by clarifying the two issues as best I can. First, Emacs relies on zero-initialized data being put into the data (not bss) as an optimization on hosts that: (1) lack virtual memory, or have VM but lack copy-on-write for data segments; (2) commonly have multiple instances of Emacs running; (3) have an unexec that stores the array 'pure' into read-only shared text; (4) are so slow that people notice speedup if 'pure' is shared; and (5) have a compiler that optimizes allocations of zeros like GCC 3.3 sparc. Sharing the 'pure' array is purely an efficiency issue: it is not something that can lead to a core dump if the array is actually put into BSS (and is thus not shared in an unexec'ed emacs). Second, it's not clear that the efficiency issue actually arises on any real platforms. Hosts satisfying (1)-(4) were fairly common 15 years ago, but are rare Emacs platforms nowadays. Furthermore, I don't know of any hosts that satisfy both (3) and (5). Solaris 8 with GCC 3.3 satisfies (5) but not (3). OpenBSD 3.2 with GCC 3.3 satisfies (3) but not (5). Perhaps some host satisfies both (3) and (5) -- as well as the other constraints -- but I don't know of it. Just in case, I have installed the following patch to the Emacs trunk: It ensures that Emacs's static arrays are initialized to nonzero. This inhibits the -fno-zero-initialized-in-bss optimization, for arrays where the efficiency issue might arise. I doubt whether hosts satisfying (1) through (5) are worth worrying about much these days. But I installed the change to help keep the Emacs code consistent with Emacs's current memory-allocation philosophy, even on hosts that optimize allocations of zeros.