From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: My Emacs unicode 2 crash again when I do some *Replace String (M-%)*, I give the debug informations under gdb in the attachments. Date: Fri, 09 Mar 2007 17:20:21 +0200 Message-ID: References: <20070306063056.GA21948@debian-testing-hy.localdomain> <86zm6q5upr.fsf@lola.quinscape.zz> <17902.9556.720278.162036@kahikatea.snap.net.nz> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1173453693 7115 80.91.229.12 (9 Mar 2007 15:21:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 9 Mar 2007 15:21:33 +0000 (UTC) Cc: nickrob@snap.net.nz, emacs-devel@gnu.org, rms@gnu.org, hongyi.zhao@gmail.com, handa@m17n.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 09 16:21:25 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HPguH-0008Vq-7J for ged-emacs-devel@m.gmane.org; Fri, 09 Mar 2007 16:21:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HPguH-0002gz-F2 for ged-emacs-devel@m.gmane.org; Fri, 09 Mar 2007 10:21:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HPgu4-0002fR-Ue for emacs-devel@gnu.org; Fri, 09 Mar 2007 10:21:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HPgtz-0002f0-TD for emacs-devel@gnu.org; Fri, 09 Mar 2007 10:21:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HPgtz-0002eq-JL for emacs-devel@gnu.org; Fri, 09 Mar 2007 10:21:03 -0500 Original-Received: from heller.inter.net.il ([213.8.233.23]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HPgtN-0001s7-B6; Fri, 09 Mar 2007 10:20:25 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-36-31.inter.net.il [80.230.36.31]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id CBW06901 (AUTH halo1); Fri, 9 Mar 2007 17:19:59 +0200 (IST) In-reply-to: (message from Stefan Monnier on Thu, 08 Mar 2007 02:19:41 -0500) X-detected-kernel: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:67617 Archived-At: > Cc: rms@gnu.org, nickrob@snap.net.nz, handa@m17n.org, hongyi.zhao@gmail.com, > emacs-devel@gnu.org > From: Stefan Monnier > Date: Thu, 08 Mar 2007 02:19:41 -0500 > > I haven't followed any of gcc's development, but I do have to point out that > keeping track of source-line numbers through all compilation and > optimization phases is tremendously difficult and tiresome, even for > relatively simple optimizations. And then > designing/understanding/generating/using debug info is itself a challenge. I have no doubt that some optimizations cannot avoid hurting debuggability. But in the vast majority of programs, the extra 5%-7% percent of performance those optimizations give you are too low a gain to justify the terrible price developers need to pay for it. > So if you want reliable debuggability, avoid optimizations. The situation is not black and white. With some cooperation, I'm positive we could have had an option that enables only those optimizations which do not severely hamper debugging. If you ever needed to ship software to a paying customer, you know that you cannot turn on optimizations only when you ship; you need to perform the entire testing and QA cycle with the same compilation options. Your above suggestion means that the software will be shipped with unoptimized code, and that is simply unacceptable for many applications, for performance reasons.