Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

gccgo: internal compiler error: in mangled_name #27569

Open
jopbrown opened this issue Sep 8, 2018 · 4 comments
Open

gccgo: internal compiler error: in mangled_name #27569

jopbrown opened this issue Sep 8, 2018 · 4 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Gccgo

Comments

@jopbrown
Copy link

jopbrown commented Sep 8, 2018 •
edited

Update

I change package domain from 9fans.net to fans.net, it can build without any error.
I think package domain can't start with number in gccgo.

gccgo 8.2.0 work well in most case at my SunOS 5.10/SPARC mechine.
But compiler error when I trying to build 9fans.net/go/draw

I try gccgo in Windows WSL, and the error can be reproduced.

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

go1.10.3 gccgo (GCC) 8.2.0 solaris/sparc
go1.10.3 gccgo (GCC) 8.2.0 linux/amd64(in windows WSL)

Does this issue reproduce with the latest release?

yes

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

SunOS 5.10/SPARC
windows10 WSL(ubuntu)/amd64

What did you do?

cd $GOPATH/src/9fans.net/go/draw
go build

What did you expect to see?

success build

What did you see instead?

# 9fans.net/go/draw/drawfcall
go1: internal compiler error: in mangled_name, at go/gofrontend/names.cc:539
0x668549 Type::mangled_name[abi:cxx11](Gogo*) const
        ../../gcc-8.2.0/gcc/go/gofrontend/names.cc:539
0x710b8a Gogo::specific_type_function_names(Type const*, Named_type const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)
        ../../gcc-8.2.0/gcc/go/gofrontend/names.cc:290
0x74f897 Type::specific_type_functions(Gogo*, Named_type*, long, Function_type*, Function_type*, Named_object**, Named_object**)
        ../../gcc-8.2.0/gcc/go/gofrontend/types.cc:2014
0x74e395 Type::type_functions(Gogo*, Named_type*, Function_type*, Function_type*, Named_object**, Named_object**)
        ../../gcc-8.2.0/gcc/go/gofrontend/types.cc:1946
0x6e9a02 Specific_type_functions::type(Type*)
        ../../gcc-8.2.0/gcc/go/gofrontend/gogo.cc:2424
0x7378d2 Type::traverse(Type*, Traverse*)
        ../../gcc-8.2.0/gcc/go/gofrontend/types.cc:318
0x73a324 Forward_declaration_type::do_traverse(Traverse*)
        ../../gcc-8.2.0/gcc/go/gofrontend/types.cc:12059
0x7378e8 Type::traverse(Type*, Traverse*)
        ../../gcc-8.2.0/gcc/go/gofrontend/types.cc:326
0x6e9988 Specific_type_functions::type(Type*)
        ../../gcc-8.2.0/gcc/go/gofrontend/gogo.cc:2447
0x7378d2 Type::traverse(Type*, Traverse*)
        ../../gcc-8.2.0/gcc/go/gofrontend/types.cc:318
0x6ecedc Bindings::traverse(Traverse*, bool)
        ../../gcc-8.2.0/gcc/go/gofrontend/gogo.cc:7950
0x6ed101 Gogo::traverse(Traverse*)
        ../../gcc-8.2.0/gcc/go/gofrontend/gogo.cc:2498
0x6ed197 Gogo::write_specific_type_functions()
        ../../gcc-8.2.0/gcc/go/gofrontend/gogo.cc:2474
0x6e876a go_parse_input_files(char const**, unsigned int, bool, bool)
        ../../gcc-8.2.0/gcc/go/gofrontend/go.cc:162
0x6e456f go_langhook_parse_file
        ../../gcc-8.2.0/gcc/go/go-lang.c:329
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
@gopherbot gopherbot added this to the Gccgo milestone Sep 8, 2018
@cherrymui
Copy link
Member

cc @ianlancetaylor @thanm

@tklauser tklauser added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 25, 2018
@ianlancetaylor
Copy link
Contributor

@thanm The problem here is that the pkgpath starts with a digit. Should we tweak the encoding scheme even farther by saying that hex-encode a leading digit in a name?

@thanm
Copy link
Contributor

thanm commented Nov 20, 2018

I'll take a look.

@thanm thanm self-assigned this Nov 20, 2018
@thanm
Copy link
Contributor

thanm commented Nov 20, 2018

This may take a bit of work to fix -- this particular assert is easy to get rid of, but there are unfortunately a fair number of other places where the compiler forms symbol names by starting with "." and then tacking on the package path, which is problematic given the mangled type encoding machinery.

@rsc rsc unassigned thanm Jun 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Gccgo
Development

No branches or pull requests
6 participants
@tklauser @ianlancetaylor @jopbrown @gopherbot @thanm @cherrymui