From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25040 invoked by alias); 27 Sep 2003 15:46:50 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24938 invoked from network); 27 Sep 2003 15:46:47 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 27 Sep 2003 15:46:47 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D8CBA2B8F; Sat, 27 Sep 2003 11:17:24 -0400 (EDT) Message-ID: <3F75AA04.8070603@redhat.com> Date: Sat, 27 Sep 2003 15:46:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH RFC] Fix break.exp optimization related failure References: <1030927002610.ZM28054@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00600.txt.bz2 > I recently encountered the following FAIL in the FR-V work that I've > been doing: > > FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file > > The reason for this failure is that gcc has optimized out the call > to marker4(). I've determined that this happens not only using -O2, > but with -O1 as well. Surprisingly, it even happens when using the > following set of switches: > > -O1 -fno-defer-pop -fno-thread-jumps -fno-loop-optimize > -fno-crossjumping -fno-if-conversion -fno-if-conversion2 > -fno-guess-branch-probability -fno-cprop-registers > -fno-omit-frame-pointer > > The various -fno-* options *should* be disabling the set of options > enabled by -O1. Anyway, I've been told that this optimization is > a special case of GCSE and apparently there's no way to disable it > via a command line switch. I've been told it gets eliminated because it's a "pure function" and the caller realises that the return value isn't used. You want to see what happens to store.c! We [GDB] are going to have to get GCC to decide, from a developers [and not compiler writers] point of view, exactly what is reasonable at -O1. We're probably also going to have to split up our test files in to separate .c's so that the compiler can't see smarts like this :-/ Andrew