This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gofrontend-dev] Re: Go patch committed: Intrinsify runtime/internal/atomic functions
- From: "Cherry Zhang via gcc-patches" <gcc-patches at gcc dot gnu dot org>
- To: Jim Wilson <jimw at sifive dot com>
- Cc: Andreas Schwab <schwab at linux-m68k dot org>, Ian Lance Taylor <iant at golang dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, gofrontend-dev <gofrontend-dev at googlegroups dot com>
- Date: Wed, 22 May 2019 21:36:47 -0400
- Subject: Re: [gofrontend-dev] Re: Go patch committed: Intrinsify runtime/internal/atomic functions
- References: <CAOyqgcUfhNqUfBtRroHB5SyKeRn0=faPVO7KhJsF8QLa1rKH+w@mail.gmail.com> <87a7fibpms.fsf@igel.home> <CAFyWVaY8aMmhmnWpoGdywaeEhiXmSUe8qqha+HhvbxYHhUnisQ@mail.gmail.com>
- Reply-to: Cherry Zhang <cherryyz at google dot com>
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 received this message because you are subscribed to the Google Groups
> "gofrontend-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gofrontend-dev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gofrontend-dev/CAFyWVaY8aMmhmnWpoGdywaeEhiXmSUe8qqha%2BHhvbxYHhUnisQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>