From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121427 invoked by alias); 1 Oct 2019 19:44:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 121418 invoked by uid 89); 1 Oct 2019 19:44:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 01 Oct 2019 19:44:28 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 585FA307D851; Tue, 1 Oct 2019 19:44:27 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-17.rdu2.redhat.com [10.10.112.17]) by smtp.corp.redhat.com (Postfix) with ESMTP id C3B915D9C9; Tue, 1 Oct 2019 19:44:25 +0000 (UTC) Subject: Re: syncing the GCC vax port, atomic issue To: Paul Koning , coypu@sdf.org Cc: gcc@gcc.gnu.org, port-vax@netbsd.org References: <20190330090306.GA29299@SDF.ORG> <180b1040-215f-e6dc-599b-394d91761d88@redhat.com> <20190920111532.GB15685@SDF.ORG> <20190920210434.GA13838@SDF.ORG> <010f52a3-98ed-47f9-38af-2560193b6a52@redhat.com> <20190920220756.GA10628@SDF.ORG> <20190921011835.GA5931@SDF.ORG> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <95dd9389-0a99-19e7-4d8c-944e16b6be8b@redhat.com> Date: Tue, 01 Oct 2019 19:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00015.txt.bz2 On 9/21/19 12:27 PM, Paul Koning wrote: > > >> On Sep 20, 2019, at 9:18 PM, coypu@sdf.org wrote: >> >> On Fri, Sep 20, 2019 at 10:07:59PM +0000, coypu@sdf.org wrote: >>> Introducing the reversed jbb* patterns doesn't seem to help with the >>> original issue. It crashes building libatomic. >> >> My loose understanding of what is going on: >> - GCC emits this atomic in expand. >> - When cleaning up, it looks for optimizations. >> - It decides this is a branch to another branch situation, so maybe >> can be improved. >> - This fails to output an instruction for unrelated reasons. >> - Hit an assert. >> >> I don't think that we should be trying to combine regular branch + >> atomic branch in very generic code. >> My guess is that, if it didn't crash now, it might emit a different kind >> of branch which loses the atomic qualities, and result in wrong code. > > Or it might leave the atomic branch, in a place where it isn't really wanted. > > I wonder if this could be avoided by representing the atomic branch by an UNSPEC rather than by a branch, since it isn't a "normal branch" that GCC knows about. If the atomic branch is special from an architectural standpoint, then that may be advisable. Jeff