From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: [22.1.90]: Point before start of properties Date: Sat, 23 Feb 2008 23:18:24 +0200 Message-ID: References: <6EE216E1AA959543A555C60FF34FB76702E48034@maileube01.misys.global.ad> <87wspcj0ou.fsf@stupidchicken.com> <6EE216E1AA959543A555C60FF34FB76702EED4A1@maileube01.misys.global.ad> <6EE216E1AA959543A555C60FF34FB76702EEDA6E@maileube01.misys.global.ad> <6EE216E1AA959543A555C60FF34FB7670300E86B@maileube01.misys.global.ad> <6EE216E1AA959543A555C60FF34FB7670305B82C@maileube01.misys.global.ad> <6EE216E1AA959543A555C60FF34FB7670305BF82@maileube01.misys.global.ad> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1203801536 14513 80.91.229.12 (23 Feb 2008 21:18:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Feb 2008 21:18:56 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 23 22:19:21 2008 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 1JT1m9-0000a0-T2 for ged-emacs-devel@m.gmane.org; Sat, 23 Feb 2008 22:19:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JT1le-00063X-41 for ged-emacs-devel@m.gmane.org; Sat, 23 Feb 2008 16:18:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JT1lZ-00062E-Dv for emacs-devel@gnu.org; Sat, 23 Feb 2008 16:18:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JT1lX-000617-1N for emacs-devel@gnu.org; Sat, 23 Feb 2008 16:18:40 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JT1lW-000613-VB for emacs-devel@gnu.org; Sat, 23 Feb 2008 16:18:38 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JT1lV-0001fp-Pa for emacs-devel@gnu.org; Sat, 23 Feb 2008 16:18:37 -0500 Original-Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1JT1lV-0001dJ-Ij for emacs-pretest-bug@gnu.org; Sat, 23 Feb 2008 16:18:37 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1JT1lS-0001cX-HL for emacs-pretest-bug@gnu.org; Sat, 23 Feb 2008 16:18:37 -0500 Original-Received: from romy.inter.net.il ([213.8.233.24]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JT1lO-0001XC-Di; Sat, 23 Feb 2008 16:18:30 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-84-229-200-132.inter.net.il [84.229.200.132]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id KIA31160 (AUTH halo1); Sat, 23 Feb 2008 23:18:05 +0200 (IST) In-reply-to: (message from Richard Stallman on Sat, 23 Feb 2008 14:29:31 -0500) X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:90159 gmane.emacs.pretest.bugs:21279 Archived-At: > From: Richard Stallman > Date: Sat, 23 Feb 2008 14:29:31 -0500 > Cc: emacs-pretest-bug@gnu.org > > It can be solved almost trivially, IMO, by providing a special -Ox > switch which would turn off every optimization whose results cannot be > expressed reliably using the modern debug info formats. > > Doesn't -O1 do that job? No, not really. -O1 disables ``expensive optimizations'', i.e. optimizations that use significant portions of processor time. Thus, which optimizations are selected for inclusion in -O1 has nothing to do with which ones defeat debugging, and the fact that -O1 compiled programs are easier to debug is a pure coincidence. I'm quite sure several important optimizations could be added to -O1 without any significant effect on debuggability.