On Tue, Feb 28, 2017 at 9:41 AM, James Cowgill <james.cowg...@imgtec.com> wrote: > > On 28/02/17 17:30, Ian Lance Taylor wrote: >> On Tue, Feb 28, 2017 at 7:33 AM, James Cowgill <james.cowg...@imgtec.com> >> wrote: >>> >>> Stumbling over this thread: >>> https://groups.google.com/forum/#!topic/golang-nuts/waTy56I_KWQ >>> >>> On 25/03/16 17:08, Ian Lance Taylor wrote: >>>> mipsn64 is a GOARCH value used by gccgo, but not by gc. The gc >>>> compiler uses mips64 and mips64le. It's not clear to me how we are >>>> going to resolve this. >>> >>> This is still a problem. It is currently not possible to build golang >>> using gccgo on mips* due to it. What is the solution? Why can't (for >>> instance) gccgo move to using the GOARCH values from golang? >> >> The complexity is that since gccgo is based on GCC, it supports >> multiple different calling conventions. Which calling convention >> should "mips64" represent? I don't have an answer. I also haven't >> really thought about it. > > I think there already is a mapping: > > mips, mipsle = o32 > mips64p32, mips64p32le = n32 > mips64, mips64le = n64 > > I see there is "support" for o64 in gccgo. That ABI (and the other MIPS > ABIs gcc supports) have close to 0 users so I expect there isn't anyone > using it for go. > > I can have a go at writing a patch for this. I was just wondering if > this was a good idea.
I guess if that makes sense to you it's OK with me. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
