From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26249 invoked by alias); 21 Jan 2009 03:46:43 -0000 Received: (qmail 26227 invoked by uid 48); 21 Jan 2009 03:46:33 -0000 Date: Wed, 21 Jan 2009 03:46:00 -0000 Message-ID: <20090121034633.26226.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/38921] [4.3 Regression] NULL access in delay-slot In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "hp at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-01/txt/msg02265.txt.bz2 ------- Comment #3 from hp at gcc dot gnu dot org 2009-01-21 03:46 ------- Created an attachment (id=17156) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17156&action=view) Fix. Looks like reorg.c wasn't to blame after all. Changes were made to may_trap_or_fault_p that made them stop considering (general, non-stack, non-const no special marks) MEMs as potentially trapping; instead putting that semantics into the new may_trap_after_code_motion_p but apparently without updating all callers. For may_trap_or_fault_p, the current only callers are resource.c (reorg.c's old friend) and ifcvt.c and both places assume the semantics in the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38921