From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63298 invoked by alias); 23 May 2019 01:41:18 -0000 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 Received: (qmail 63285 invoked by uid 89); 23 May 2019 01:41:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-lf1-f66.google.com Received: from mail-lf1-f66.google.com (HELO mail-lf1-f66.google.com) (209.85.167.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 May 2019 01:41:16 +0000 Received: by mail-lf1-f66.google.com with SMTP id n134so3113037lfn.11 for ; Wed, 22 May 2019 18:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=golang-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=O2pKqSmTNSPP8PcmtEBVNrfBf5bLuSdMCRPzU1F9G/Q=; b=dSG93PsTUbsUeKOrSwDtCpIvVXumR4Ft8C/4ogdWW/jLCFfH7d+qNfCTptEvopTs4Q W7WlZqvW1hcRhf7uda5gsTAi88YHiB+CzfFDIRF53uxgJQYt1OazRdTyLuibFOMmafZR f0+5xCr2lRbFQRDtIEVCMFS7xyqSA3jN9d3xWTSnT3CNqWM+raerWPmLFS9QyiYluBoA n3lFPYpSFSs1XZIOmPTtJQuVcU7crDOhS01S1871PbkM5m8z91QmzyQCFHF7wZFgwM6S KbumYLB5Nvdzp77IBMkEpTadxJWxxE0zD4r/IH7MQaK/m27PF1oZayi7Q1XvFSauJgK4 BkNQ== MIME-Version: 1.0 References: <87a7fibpms.fsf@igel.home> In-Reply-To: From: Ian Lance Taylor Date: Thu, 23 May 2019 01:41:00 -0000 Message-ID: Subject: Re: [gofrontend-dev] Re: Go patch committed: Intrinsify runtime/internal/atomic functions To: Cherry Zhang Cc: Jim Wilson , Andreas Schwab , gcc-patches , gofrontend-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-05/txt/msg01549.txt.bz2 On Wed, May 22, 2019 at 9:36 PM Cherry Zhang wrote: > > Jim, thank you for the fix! The patch looks good to me. Maybe we should a= lso apply this to __atomic_add_fetch_4 and __atomic_add_fetch_8? > > Thanks, > Cherry > > > > On Tue, May 21, 2019 at 11:25 PM Jim Wilson wrote: >> >> On Sun, May 19, 2019 at 5:22 AM Andreas Schwab w= rote: >> > ../../../libgo/go/runtime/mbitmap.go: In function =E2=80=98runtime.set= Marked.runtime.markBits=E2=80=99: >> > ../../../libgo/go/runtime/mbitmap.go:291:9: internal compiler error: S= egmentation fault >> > 291 | atomic.Or8(m.bytep, m.mask) >> > | ^ >> >> This is failing for RISC-V because __atomic_or_fetch_1 isn't a >> built-in function that can be expanded inline. You have to call the >> library function in libatomic. The C front-end is registering all of >> the built-in functions, but it looks like the go front-end is only >> registering functions it thinks it needs and this list is incomplete. >> In expand_builtin, case BUILT_IN_ATOMIC_OR_FETCH_1, the external >> library call for this gets set to BUILT_IN_ATOMIC_FETCH_OR_1. Then in >> expand_builtin_atomic_fetch_op when we call builtin_decl_explicit >> (ext_call) it returns NULL. This is because the go front end >> registered BUILT_IN_ATOMIC_OR_FETCH_1 as a built-in, but did not >> register BUILT_IN_ATOMIC_FETCH_OR_1 as a built-in. The NULL return >> from builtin_decl_explicit gives us an ADDR_EXPR with a NULL operand >> which eventually causes the internal compiler error. It looks like >> the same thing is done with all of the op_fetch built-ins, so use of >> any of them means that the fetch_op built-in also has to be >> registered. I verified with a quick hack that I need both >> BUILT_IN_ATOMIC_FETCH_OR_1 and BUILT_IN_ATOMIC_FETCH_AND_1 defined as >> built-ins to make a RISC-V go build work. I haven't done any testing >> yet. Jim, you can go ahead and commit that patch with a ChangeLog entry. (The files in go/gcc but not in go/gcc/gofrontend) are under normal GCC rules.) Thanks. Ian