From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20102 invoked by alias); 20 Sep 2007 20:32:11 -0000 Received: (qmail 20051 invoked by uid 22791); 20 Sep 2007 20:31:55 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Sep 2007 20:31:50 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l8KKTkMM025586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2007 16:29:46 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l8KKTj1P030766; Thu, 20 Sep 2007 16:29:46 -0400 Received: from [172.16.14.46] (torque.toronto.redhat.com [172.16.14.46]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l8KKTif9011223; Thu, 20 Sep 2007 16:29:45 -0400 Message-ID: <46F2D838.4040309@redhat.com> Date: Thu, 20 Sep 2007 20:47:00 -0000 From: Vladimir Makarov User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: Maxim Kuvyrkov CC: Andrey Belevantsev , gcc-patches Subject: Re: [PATCH] Fix ICE in ia64 speculation support References: <46E97245.5010107@codesourcery.com> In-Reply-To: <46E97245.5010107@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-09/txt/msg01632.txt.bz2 Maxim Kuvyrkov wrote: > Hi, > > This patch fixes minor bug in ia64 speculation support. > > The issue is that may_trap_p () can return different results given > normal instruction and its speculative version. E.g., this occurs for > (set (reg:DF) (mem:DF)) and (set (reg:DF) (unspec:DF [(mem:DF)] > DATA_SPEC)). The latter is a speculative variant of the former and > may_trap_p () always returns 'true' for the speculative version > because unspec:DF is considered a random floating point operation that > might trap. > > This causes an assert, that checks that a speculative insn can stay > speculative, fail. The fix is to use original pattern when calling > may_trap_p (). > > The bug was reported by Andrey and implicates itself only with '-O2 > -funroll-loops' (the options tested by default do not include this > combination). The testcase is a copy of > gcc.c-torture/execute/20040709-1.c but with forced -funroll-loops. > > OK for trunk? > > Sorry, I can reproduce the bug. I've tried today repository. No luck. I think that right solution would be make may_trap_p to understand that the insn is speculative. But without reproducing the bug, I can not be sure about my proposal. Vlad