This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: (RFC) GCC minor document change: gcc.1


Paul Eggert wrote:
> 
> > Date: Tue, 15 Jul 2003 09:03:32 +0900
> > From: Ishikawa <ishikawa@yk.rim.or.jp>
> 
> > ! 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.
> 
	[ ... ]

Dear Paul,

Thank you for your clarification.

So it means that, basically, the
new code layout somehow produced by GCC 3.3
triggered a bug in unexelf.c, which was
fixed in your previous posting.

OK, then we don't have to put the change in 
the gcc documentation about -fno-zero-initialized-in-bss causing
problems for GNU Emacs (although I certainly can believe
some embedded folks will be bitten for once when I think about it, but
I digress.).

Below is not directed to Paul per se, but to the CC:s mailing lists.

Now I am wondering what we should do about the problem of
GCC 3.3 + and unpatched GNU Emacs 21.3 combination under Solaris 8.
Since GCC 3.2.3 + GNU Emacs 21.3 works and
GCC 3.3 + GNU Emacs 21.3 doesn't, I still would like
to  see  a mention of the problem in some visible places
unless GNU Emacs 21.4 that fixes this problem is released very soon.
But where should we put the warning?
My feeling as the end user is on gcc's changes.html, but
there may be a better place. It is a pity that GCC 3.3's change page
doen't mention this zero-initialized-in-bss feature of GCC 3.3 in any
case.

At the end of GCC 3.3's  changes.html, it says:
>Please send comments on these web pages and GCC to our public mailing list at gcc@gnu.org or gcc@gcc.gnu.org, send >other questions to gnu@gnu.org.

Is sending this to gcc-patches enough or should I send to gcc mailing
list as well?

Happy Hacking,

Ishikawa, Chiaki
 
PS: For reasons I don't know (maybe my netscape's MIME header specifying
ISO-2022-JP is not liked by the mailing list software),
my post to emacs-pretester seems to bounce constantly. Again sorry
if there is a hole in the threaded listing of the mailing archive.





 
-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]