From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2902 invoked by alias); 21 Jan 2009 22:01:07 -0000 Received: (qmail 571 invoked by uid 48); 21 Jan 2009 22:00:56 -0000 Date: Wed, 21 Jan 2009 22:01:00 -0000 Message-ID: <20090121220056.569.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/msg02318.txt.bz2 ------- Comment #7 from hp at gcc dot gnu dot org 2009-01-21 22:00 ------- (In reply to comment #6) > However, I suspect that all the places that use may_trap_after_code_motion_p in > fact expect it to have MTP_AFTER_MOVE | MTP_UNALIGNED_MEMS semantics as well. Me too. > So I would propose to merge may_trap_or_fault_p and > may_trap_after_code_motion_p to one function (and replace the checks for > MTP_UNALIGNED_MEMS in may_trap_p_1 by MTP_AFTER_MOVE, as they IMHO handle > different instances of the same problem -- the code that does not fail at its > current location, but may fail elsewhere). Yes: I'll prepare a patch to replace (change back) calls to may_trap_after_code_motion_p with calls to may_trap_or_fault_p and fold MTP_AFTER_MOVE into MTP_UNALIGNED_MEMS. If the release managers deems that too invasive for 4.3 and 4.4, perhaps they can still agree with the patch in commen #3. Thanks for checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38921