From: Ian Lance Taylor <iant@golang.org>
To: Cherry Zhang <cherryyz@google.com>
Cc: Jim Wilson <jimw@sifive.com>,
Andreas Schwab <schwab@linux-m68k.org>,
gcc-patches <gcc-patches@gcc.gnu.org>,
gofrontend-dev <gofrontend-dev@googlegroups.com>
Subject: Re: [gofrontend-dev] Re: Go patch committed: Intrinsify runtime/internal/atomic functions
Date: Thu, 23 May 2019 01:41:00 -0000 [thread overview]
Message-ID: <CAOyqgcWUovBynsiQuquxgeZy-cdTfGdZxZou8A4yH-q9-dD_JA@mail.gmail.com> (raw)
In-Reply-To: <CAHpjNSKtyody2NspEbzE47JOsRdb5OGSqK3DCVqo-H+d2ny=pA@mail.gmail.com>
On Wed, May 22, 2019 at 9:36 PM Cherry Zhang <cherryyz@google.com> wrote:
>
> Jim, thank you for the fix! The patch looks good to me. Maybe we should also 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 <jimw@sifive.com> wrote:
>>
>> On Sun, May 19, 2019 at 5:22 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>> > ../../../libgo/go/runtime/mbitmap.go: In function ‘runtime.setMarked.runtime.markBits’:
>> > ../../../libgo/go/runtime/mbitmap.go:291:9: internal compiler error: Segmentation 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
next prev parent reply other threads:[~2019-05-23 1:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-17 0:21 Ian Lance Taylor
2019-05-19 12:22 ` Andreas Schwab
2019-05-22 1:17 ` Jim Wilson
2019-05-23 1:37 ` [gofrontend-dev] " Cherry Zhang via gcc-patches
2019-05-23 1:41 ` Ian Lance Taylor [this message]
2019-05-30 20:50 ` Jim Wilson
2019-05-30 20:51 ` Jim Wilson
2019-05-30 18:37 ` Andreas Schwab
2019-05-30 20:56 ` Jim Wilson
2019-06-03 14:12 ` Maciej Rozycki
2019-06-03 17:03 ` Ian Lance Taylor
2019-06-03 20:11 ` Maciej Rozycki
2019-06-03 17:21 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOyqgcWUovBynsiQuquxgeZy-cdTfGdZxZou8A4yH-q9-dD_JA@mail.gmail.com \
--to=iant@golang.org \
--cc=cherryyz@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gofrontend-dev@googlegroups.com \
--cc=jimw@sifive.com \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).