gollvm: error in names.cc [const: assertion 'c < '0' || c > '9'' failed] when building mjl-/vmgo package #41862

advancedwebdeveloper · 2020-10-08T11:32:15Z

What version of Go are you using (`go version`)?

$ go version

go version go1.15.2 gollvm LLVM 12.0.0git linux/amd64
My "release" build is available [here](go version go1.15.2 gollvm LLVM 12.0.0git linux/amd64
)

Does this issue reproduce with the latest release?

Yes, for sure.

What operating system and processor architecture are you using (`go env`)?

Ubuntu 20.04 x86_64

go env $ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/oceanfish81/.cache/go-build"
GOENV="/home/oceanfish81/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/oceanfish81/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/oceanfish81/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/oceanfish81/gollvm_dist"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/oceanfish81/gollvm_dist/tools"
GCCGO="/home/oceanfish81/gollvm_dist/bin/llvm-goc"
AR="ar"
CC="/usr/bin/clang"
CXX="/usr/bin/clang++"
CGO_ENABLED="1"
GOMOD="/home/oceanfish81/golang_projects/duit/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build577579041=/tmp/go-build -gno-record-gcc-switches -funwind-tables"

$ go env

What did you do?

Cloned duit and entered the directory.
Then I tried to build

$ go build -i -v -x

What did you expect to see?

Normal build process, without any errors.

What did you see instead?

WORK=/tmp/go-build288395935

get https://proxy.golang.org/github.com/mjl-/go/@v/v0.0.0-20180429123528-fafada5f286e.info

get https://proxy.golang.org/github.com/mjl-/go/@v/v0.0.0-20180429123528-fafada5f286e.info: 200 OK (0.832s)

9fans.net/go/draw/drawfcall
mkdir -p $WORK/b003/
cd $WORK
/home/oceanfish81/gollvm_dist/bin/llvm-goc -fgo-importcfg=/dev/null -c -x c - -o /dev/null || true
cd /home/oceanfish81/go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall
/home/oceanfish81/gollvm_dist/bin/llvm-goc -c -O2 -g -m64 -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -fgo-pkgpath=9fans.net/go/draw/drawfcall -o $WORK/b003/go.o -I $WORK/b003/importcfgroot ./bit.go ./msg.go ./mux.go

9fans.net/go/draw/drawfcall

llvm-goc: /home/oceanfish81/workarea/llvm-project/llvm/tools/gollvm/gofrontend/go/names.cc:595: std::string Type::mangled_name(Gogo ) const: assertion 'c < '0' || c > '9'' failed.
#0 0x0000000000d765f3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0xd765f3)
#1 0x0000000000d7468c llvm::sys::RunSignalHandlers() (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0xd7468c)
#2 0x0000000000d76a85 SignalHandler(int) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0xd76a85)
#3 0x00007f73143713c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x00007f7313ea218b raise /build/glibc-ZN95T4/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x00007f7313e81859 abort /build/glibc-ZN95T4/glibc-2.31/stdlib/abort.c:81:7
#6 0x000000000051b662 (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x51b662)
#7 0x00000000004b1397 Type::mangled_name(Gogo) const (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x4b1397)
#8 0x00000000004b3ec8 Gogo::type_descriptor_name(Type const*, Named_type*) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x4b3ec8)
#9 0x0000000000548101 Sort_types::operator()(Type const*, Type const*) const (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x548101)
#10 0x0000000000547fa9 void std::__1::__sort<Sort_types&, Type const**>(Type const**, Type const**, Sort_types&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x547fa9)
#11 0x0000000000542a1a Export::assign_type_indices(std::__1::vector<Named_object*, std::__1::allocator<Named_object*> > const&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x542a1a)
#12 0x0000000000542261 Export::export_globals(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::map<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, Package*, std::__1::less<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const, Package*> > > const&, std::__1::map<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, Package*, std::__1::less<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const, Package*> > > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, Import_init_set const&, Bindings const*, std::__1::unordered_set<Named_object*, std::__1::hash<Named_object*>, std::__1::equal_to<Named_object*>, std::__1::allocator<Named_object*> >) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x542261)
#13 0x000000000049253d Gogo::do_exports() (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x49253d)
#14 0x0000000000479b28 go_parse_input_files(char const**, unsigned int, bool, bool) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x479b28)
#15 0x000000000046e933 gollvm::driver::CompileGoImpl::invokeFrontEnd() (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x46e933)
#16 0x000000000047118b gollvm::driver::CompileGo::performAction(gollvm::driver::Compilation&, gollvm::driver::Action const&, llvm::SmallVector<gollvm::driver::Artifact, 3u> const&, gollvm::driver::Artifact const&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x47118b)
#17 0x0000000000467b12 gollvm::driver::Driver::processAction(gollvm::driver::Action*, gollvm::driver::Compilation&, bool) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x467b12)
#18 0x0000000000467c22 gollvm::driver::Driver::processActions(gollvm::driver::Compilation&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x467c22)
#19 0x0000000000460f07 main (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x460f07)
#20 0x00007f7313e830b3 __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:342:3
#21 0x000000000045fb2e _start (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x45fb2e)
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/oceanfish81/gollvm_dist/bin/llvm-goc -c -O2 -g -m64 -fdebug-prefix-map=/tmp/go-build288395935=/tmp/go-build -gno-record-gcc-switches -fgo-pkgpath=9fans.net/go/draw/drawfcall -o $WORK/b003/go.o -I $WORK/b003/importcfgroot ../../go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall/bit.go ../../go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall/msg.go ../../go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall/mux.go

oceanfish81@oceanfish81-VirtualBox:~/golang_projects/duit$ go test ./...

9fans.net/go/draw/drawfcall

llvm-goc: /home/oceanfish81/workarea/llvm-project/llvm/tools/gollvm/gofrontend/go/names.cc:595: std::string Type::mangled_name(Gogo ) const: assertion 'c < '0' || c > '9'' failed.
#0 0x0000000000d765f3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0xd765f3)
#1 0x0000000000d7468c llvm::sys::RunSignalHandlers() (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0xd7468c)
#2 0x0000000000d76a85 SignalHandler(int) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0xd76a85)
#3 0x00007f27a70ee3c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x00007f27a6c1f18b raise /build/glibc-ZN95T4/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x00007f27a6bfe859 abort /build/glibc-ZN95T4/glibc-2.31/stdlib/abort.c:81:7
#6 0x000000000051b662 (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x51b662)
#7 0x00000000004b1397 Type::mangled_name(Gogo) const (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x4b1397)
#8 0x00000000004b3ec8 Gogo::type_descriptor_name(Type const*, Named_type*) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x4b3ec8)
#9 0x0000000000548101 Sort_types::operator()(Type const*, Type const*) const (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x548101)
#10 0x0000000000547fa9 void std::__1::__sort<Sort_types&, Type const**>(Type const**, Type const**, Sort_types&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x547fa9)
#11 0x0000000000542a1a Export::assign_type_indices(std::__1::vector<Named_object*, std::__1::allocator<Named_object*> > const&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x542a1a)
#12 0x0000000000542261 Export::export_globals(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::map<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, Package*, std::__1::less<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const, Package*> > > const&, std::__1::map<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, Package*, std::__1::less<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const, Package*> > > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, Import_init_set const&, Bindings const*, std::__1::unordered_set<Named_object*, std::__1::hash<Named_object*>, std::__1::equal_to<Named_object*>, std::__1::allocator<Named_object*> >) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x542261)
#13 0x000000000049253d Gogo::do_exports() (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x49253d)
#14 0x0000000000479b28 go_parse_input_files(char const**, unsigned int, bool, bool) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x479b28)
#15 0x000000000046e933 gollvm::driver::CompileGoImpl::invokeFrontEnd() (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x46e933)
#16 0x000000000047118b gollvm::driver::CompileGo::performAction(gollvm::driver::Compilation&, gollvm::driver::Action const&, llvm::SmallVector<gollvm::driver::Artifact, 3u> const&, gollvm::driver::Artifact const&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x47118b)
#17 0x0000000000467b12 gollvm::driver::Driver::processAction(gollvm::driver::Action*, gollvm::driver::Compilation&, bool) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x467b12)
#18 0x0000000000467c22 gollvm::driver::Driver::processActions(gollvm::driver::Compilation&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x467c22)
#19 0x0000000000460f07 main (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x460f07)
#20 0x00007f27a6c000b3 __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:342:3
#21 0x000000000045fb2e _start (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x45fb2e)
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/oceanfish81/gollvm_dist/bin/llvm-goc -c -O2 -g -m64 -fdebug-prefix-map=/tmp/go-build443995143=/tmp/go-build -gno-record-gcc-switches -fgo-pkgpath=9fans.net/go/draw/drawfcall -o $WORK/b003/go.o -I $WORK/b003/importcfgroot ../../go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall/bit.go ../../go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall/msg.go ../../go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall/mux.go

It looks like this assertion fails.

@ianlancetaylor , please what is it implemented for.

@thanm , @cherrymui : my compressed build folder, for gollvm, could be retrieved here

The text was updated successfully, but these errors were encountered:

ianlancetaylor · 2020-10-08T23:47:19Z

The problem arises when building in the directory vendor/9fans.net/go/draw/drawfcall. The gofrontend code doesn't correctly handle package paths starting with digits. I'll take a look.

CC @thanm @cherrymui

ianlancetaylor · 2020-10-09T00:12:27Z

@thanm This turns out to be more complicated than I thought. As I reread the long comment at the top of names.cc, I see that it explicitly assumes that a pkgpath can't contain a dot. But the current pkgpath encoding can contain a dot. That means that we can have name conflicts.

Consider x/a.go:

package p

type x2e int

func (x2e) M() {}

x./a.go (note: the name of the directory is x., with a trailing dot):

package p

import _ "x"

func M() {}

main/main.go:

package main

import _ "x."

func main() {}

Building main gives this error:

# main
/home/iant/binutils/gold-dir/ld: error: /home/iant/.cache/go-build/7b/7baa8f3e3feb77e7d804488cc23f3709086aea92a5afc313dbec7febc4fb5b61-d(_go_.o): multiple definition of 'x.x2e.M'
/home/iant/binutils/gold-dir/ld: /home/iant/.cache/go-build/f7/f7f6d53f176b77f8bc226aa6215f9ff5f7b6affda1f6f804d3ea05b679463344-d(_go_.o): previous definition here
collect2: error: ld returned 1 exit status

The problem is that in the package x (no dot) the name of the method is x.x2e.M. In the package x. (with dot), the package path is encoded as x.x2e and the name of the function is x.x2e.M. So the method and the function wind up with the same name.

Unfortunately I think we need to introduce yet another package path mangling scheme, one that doesn't use a dot in the package path. Unless anyone can think of a better idea.

thanm · 2020-10-09T14:27:28Z

Ouch. I don't see an easy way to resolve that clash. BTW, this seems orthogonal to original submitted problem, which is a compiler crash?

ianlancetaylor · 2020-10-09T18:01:18Z

It's different but related. The compiler crash is because the mangled package path has a leading digit, which triggers an assertion failure when it is combined with a leading dot. That is, the problem in both cases is package path mangling.

ianlancetaylor · 2020-10-12T17:14:41Z

@thanm @cherrymui Here are my thoughts. Interested to hear yours.

Premises:

The names of symbols in generated assembly code and object files must contain only ASCII letters, ASCII digits, underscore, and dot. They must start with an ASCII letter or underscore.
A Go symbol may contain any Unicode letter or digit or underscore but may not contain dot.
A package path may contain any character at all, except perhaps a 0 byte.
To avoid symbol name conflicts, we need some way to separate symbol names into components, such as some way to separate the package path from the actual symbol, and a number of similar separations. Currently we use dot for that, as outlined in the long comment at the top of names.cc. To maintain sanity that separation symbol must not appear in the components that we are separating.
We clearly must have some encoding scheme for characters that can't appear in symbol names. For simplicity and convenience for users it should be straightforward to decode that scheme without having to understand the different components of a symbol name. That is, decoding should not need to figure out whether it is looking at a package path or a Go identifier name.

The problem we have today is that we accidentally broke premise 4: a dot can appear in a package path. This leads to ambiguity.

I see two paths forward.

First path.

We continue using dot as the separator character and we keep the current identifier encoding. Therefore, we need an encoding scheme for package paths that converts any string to ASCII letters, digits, and underscores, with no dots. The obvious choice is to use underscore. We encode bytes < 0x80 as _xbb (or _zbb) and we encode Unicode characters as either _udddd or _Udddddddd. We encode underscore itself as either _x5f or as simply __. Note that we also have to encode a leading digit in a package path, presumably using the _xbb notation.

To satisfy premise 5, we have to further encode underscores in Go identifier names. We can encode them as ..z5f (using the current encoding) or _x5f or __ (using the new encoding).

This means that the decoding scheme will have to support both underscore mangling and dot mangling.

Second path.

We continue using dot as a separator character. However, we stop using dot as a mangling character. Instead, we use underscore. Instead of .xbb in a struct tag, we use _xbb. Instead of ..zbb, ..udddd or ..Udddddddd, we use _xbb, _udddd, or _Udddddddd. We encode underscore itself as either _x5f or __. We apply this mangling to both package paths and Go identifiers.

This makes the decoding scheme simpler. It's a little easier to reason about as we no longer have to ensure that there is no overlap between the separator character dot and the mangling character dot (this is why the mangling scheme needs two dots but only one underscore).

thanm · 2020-10-12T18:20:26Z

Thanks the the analysis. I think you've broken it down well.

The one thing that makes me nervous about making more use of "_" (as opposed to ".") in the mangling process is that it increases the risk that users might not "notice" that a given symbol is encoded vs original. With the "." encoding, most Go users are aware that Go symbols can't contain a dot, so when seeing a mangled named one immediately catches on. When looking at a name like "x_x5f_x5fQ" in the debugger, it's possible that a user might not catch on right away that this is a mangled symbol name.

With that said, we have to do something, so in fact either of the schemes you describe seem ok to me. Getting a complete/functional mangling scheme is the important thing, even if it risks user debugger confusion in rare cases.

advancedwebdeveloper · 2020-10-12T19:03:04Z

@brendandburns , could you express your vision/opinion?

gopherbot · 2020-11-17T04:06:30Z

Change https://golang.org/cl/270637 mentions this issue: cmd/go, cmd/cgo: update gofrontend mangling checks

This is a port of two patches in the master repository. https://golang.org/cl/259298 cmd/cgo: split gofrontend mangling checks into cmd/internal/pkgpath This is a step toward porting https://golang.org/cl/219817 from the gofrontend repo to the main repo. Note that this also corrects the implementation of the v2 mangling scheme to use ..u and ..U where appropriate. https://golang.org/cl/259299 cmd/go: use cmd/internal/pkgpath for gccgo pkgpath symbol For golang/go#37272 For golang/go#41862 Change-Id: Id276ca1bac7e1d850408a9d222c19e57b26ba001 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/270637 Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>

gopherbot · 2020-11-19T22:24:23Z

Change https://golang.org/cl/271726 mentions this issue: compiler, libgo: change mangling scheme

Overhaul the mangling scheme to avoid ambiguities if the package path contains a dot. Instead of using dot both to separate components and to mangle characters, use dot only to separate components and use underscore to mangle characters. For golang/go#41862 Change-Id: Iddc04422673a4cdc6773d24d3d75fc8945266773 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/271726 Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>

gopherbot · 2020-11-20T20:56:03Z

Change https://golang.org/cl/272127 mentions this issue: cmd/cgo, cmd/internal/pkgpath: support gofrontend mangler v3

The gofrontend mangling scheme used by gccgo and GoLLVM has changed again. Support the new version. This is a port of the relevant parts of https://golang.org/cl/271726. For #41862 Change-Id: I9c961c8e17ec960a83a23e1d49ea900962b63393 Reviewed-on: https://go-review.googlesource.com/c/go/+/272127 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Go Bot <gobot@golang.org>

Overhaul the mangling scheme to avoid ambiguities if the package path contains a dot. Instead of using dot both to separate components and to mangle characters, use dot only to separate components and use underscore to mangle characters. For golang/go#41862 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/271726

ianlancetaylor · 2020-12-08T00:28:52Z

This is now fixed on tip.

advancedwebdeveloper mentioned this issue Oct 8, 2020

llvm-goc: /home/oceanfish81/workarea/llvm-project/llvm/tools/gollvm/gofrontend/go/names.cc:595: std::string Type::mangled_name(Gogo *) const: assertion 'c < '0' || c > '9'' failed. mjl-/duit#21

Open

ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 8, 2020

ianlancetaylor added this to the Gccgo milestone Oct 8, 2020

ianlancetaylor closed this as completed Dec 8, 2020

golang locked and limited conversation to collaborators Dec 8, 2021

gopherbot added the FrozenDueToAge label Dec 8, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gollvm: error in names.cc [const: assertion 'c < '0' || c > '9'' failed] when building mjl-/vmgo package #41862

gollvm: error in names.cc [const: assertion 'c < '0' || c > '9'' failed] when building mjl-/vmgo package #41862

advancedwebdeveloper commented Oct 8, 2020

ianlancetaylor commented Oct 8, 2020

ianlancetaylor commented Oct 9, 2020

thanm commented Oct 9, 2020

ianlancetaylor commented Oct 9, 2020

ianlancetaylor commented Oct 12, 2020

thanm commented Oct 12, 2020

advancedwebdeveloper commented Oct 12, 2020

gopherbot commented Nov 17, 2020

gopherbot commented Nov 19, 2020

gopherbot commented Nov 20, 2020

ianlancetaylor commented Dec 8, 2020

gollvm: error in names.cc [const: assertion 'c < '0' || c > '9'' failed] when building mjl-/vmgo package #41862

gollvm: error in names.cc [const: assertion 'c < '0' || c > '9'' failed] when building mjl-/vmgo package #41862

Comments

advancedwebdeveloper commented Oct 8, 2020

What version of Go are you using (go version)?

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

What did you do?

What did you expect to see?

What did you see instead?

get https://proxy.golang.org/github.com/mjl-/go/@v/v0.0.0-20180429123528-fafada5f286e.info

get https://proxy.golang.org/github.com/mjl-/go/@v/v0.0.0-20180429123528-fafada5f286e.info: 200 OK (0.832s)

9fans.net/go/draw/drawfcall

9fans.net/go/draw/drawfcall

ianlancetaylor commented Oct 8, 2020

ianlancetaylor commented Oct 9, 2020

thanm commented Oct 9, 2020

ianlancetaylor commented Oct 9, 2020

ianlancetaylor commented Oct 12, 2020

thanm commented Oct 12, 2020

advancedwebdeveloper commented Oct 12, 2020

gopherbot commented Nov 17, 2020

gopherbot commented Nov 19, 2020

gopherbot commented Nov 20, 2020

ianlancetaylor commented Dec 8, 2020

What version of Go are you using (`go version`)?

What operating system and processor architecture are you using (`go env`)?