public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jim Wilson <jimw@sifive.com>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Ian Lance Taylor <iant@golang.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>,
		gofrontend-dev <gofrontend-dev@googlegroups.com>
Subject: Re: Go patch committed: Intrinsify runtime/internal/atomic functions
Date: Wed, 22 May 2019 01:17:00 -0000	[thread overview]
Message-ID: <CAFyWVaY8aMmhmnWpoGdywaeEhiXmSUe8qqha+HhvbxYHhUnisQ@mail.gmail.com> (raw)
In-Reply-To: <87a7fibpms.fsf@igel.home>

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

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

[-- Attachment #2: go-builtins.txt --]
[-- Type: text/plain, Size: 955 bytes --]

diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
index 1b26f2bac93..91043b51463 100644
--- a/gcc/go/go-gcc.cc
+++ b/gcc/go/go-gcc.cc
@@ -871,6 +871,8 @@ Gcc_backend::Gcc_backend()
                                NULL_TREE);
   this->define_builtin(BUILT_IN_ATOMIC_AND_FETCH_1, "__atomic_and_fetch_1", NULL,
                        t, false, false);
+  this->define_builtin(BUILT_IN_ATOMIC_FETCH_AND_1, "__atomic_fetch_and_1", NULL,
+                       t, false, false);
 
   t = build_function_type_list(unsigned_char_type_node,
                                ptr_type_node,
@@ -879,6 +881,8 @@ Gcc_backend::Gcc_backend()
                                NULL_TREE);
   this->define_builtin(BUILT_IN_ATOMIC_OR_FETCH_1, "__atomic_or_fetch_1", NULL,
                        t, false, false);
+  this->define_builtin(BUILT_IN_ATOMIC_FETCH_OR_1, "__atomic_fetch_or_1", NULL,
+                       t, false, false);
 }
 
 // Get an unnamed integer type.

  reply	other threads:[~2019-05-22  1:17 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 [this message]
2019-05-23  1:37     ` [gofrontend-dev] " Cherry Zhang via gcc-patches
2019-05-23  1:41       ` Ian Lance Taylor
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=CAFyWVaY8aMmhmnWpoGdywaeEhiXmSUe8qqha+HhvbxYHhUnisQ@mail.gmail.com \
    --to=jimw@sifive.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gofrontend-dev@googlegroups.com \
    --cc=iant@golang.org \
    --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).