From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20276 invoked by alias); 11 Oct 2005 13:54:59 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 20261 invoked by uid 22791); 11 Oct 2005 13:54:55 -0000 Received: from mail-out1.fuse.net (HELO smtp1.fuse.net) (216.68.8.174) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 11 Oct 2005 13:54:55 +0000 Received: from gx6.fuse.net ([216.68.188.61]) by smtp1.fuse.net (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051011135452.MRJR13215.smtp1.fuse.net@gx6.fuse.net>; Tue, 11 Oct 2005 09:54:52 -0400 Received: from dellpi.pinski.fam ([216.68.188.61]) by gx6.fuse.net (InterMail vG.1.02.00.02 201-2136-104-102-20041210) with ESMTP id <20051011135452.VEVU24344.gx6.fuse.net@dellpi.pinski.fam>; Tue, 11 Oct 2005 09:54:52 -0400 Received: from [10.0.0.80] (zhivago.i.pinski.fam [10.0.0.80]) by dellpi.pinski.fam (8.12.2/8.12.1) with ESMTP id j9BDsmOG019303; Tue, 11 Oct 2005 09:54:49 -0400 (EDT) In-Reply-To: <20051011135131.19347.qmail@sourceware.org> References: <20051011135131.19347.qmail@sourceware.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <80169e89a286f3ccef29324946099344@physics.uc.edu> Content-Transfer-Encoding: 7bit Cc: gcc-bugs@gcc.gnu.org From: Andrew Pinski Subject: Re: [Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2 Date: Tue, 11 Oct 2005 13:54:00 -0000 To: gcc-bugzilla@gcc.gnu.org X-SW-Source: 2005-10/txt/msg01300.txt.bz2 List-Id: On Oct 11, 2005, at 9:51 AM, ebotcazou at gcc dot gnu dot org wrote: > > > ------- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-10-11 > 13:51 ------- >> Yes, I think the problem is in delay slot scheduling too. COND_EXPR >> means that >> either branch must not be evaluated because it could be illegal; if >> you hoist a >> mem from a branch into the delay slot of the condition, you are >> effectively >> partially evaluting the branch. > > Yes, that makes sense. At the moment the predicate used in reorg.c is > may_trap_p so we would need to detect faulting instructions too. may_trap_p is the correct thing as it should detect this instruction as trapping: /* Memory ref can trap unless it's a static var or a stack slot. */ case MEM: if (MEM_NOTRAP_P (x)) return 0; return rtx_addr_can_trap_p (XEXP (x, 0)); -- Pinski