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

gccgo: assert in Export::package_index while exporting inlinable function #32778

Closed
thanm opened this issue Jun 25, 2019 · 4 comments
Closed
Milestone

Comments

@thanm
Copy link
Contributor

thanm commented Jun 25, 2019

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

$ go version
go version go1.12.2 gccgo (GCC) 10.0.0 20190624 (experimental) linux/amd64

Does this issue reproduce with the latest release?

Yes.

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

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/usr/local/google/home/thanm/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPROXY=""
GORACE=""
GOTMPDIR=""
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build416581980=/tmp/go-build -gno-record-gcc-switches -funwind-tables"

What did you do?

Compile these two packages, first "pf" and the "upf". Source code:

Package "pf":

`package pf

import (
"regexp"
"strings"
)

var (
regexName = regexp.MustCompile(^[_a-zA-Z][_a-zA-Z0-9]*$)
regexFullName = regexp.MustCompile(^[_a-zA-Z][_a-zA-Z0-9]*(\.[_a-zA-Z][_a-zA-Z0-9]*)*$)
)

type Name string

func (n Name) IsValid() bool {
return regexName.MatchString(string(n))
}

type FullName string

func (n FullName) IsValid() bool {
return regexFullName.MatchString(string(n))
}

func (n FullName) Name() Name {
if i := strings.LastIndexByte(string(n), '.'); i >= 0 {
return Name(n[i+1:])
}
return Name(n)
}
`
Package "upf"

`package upf

import "pf"

var n pf.Name

func Expo(fn pf.FullName) pf.Name {
return fn.Name()
}
`

What did you expect to see?

Clean build

What did you see instead?

Assert with this stack trace:

go1: internal compiler error: in package_index, at go/gofrontend/export.cc:1143 0x6af1bb Export::package_index(Package const*) const ../../gcc-trunk/gcc/go/gofrontend/export.cc:1143 0x6beeb8 Export_function_body::package_index(Package const*) const ../../gcc-trunk/gcc/go/gofrontend/export.h:368 0x6beeb8 Expression::export_name(Export_function_body*, Named_object const*) ../../gcc-trunk/gcc/go/gofrontend/expressions.cc:98 0x6ca108 Expression::export_expression(Export_function_body*) const ../../gcc-trunk/gcc/go/gofrontend/expressions.h:1054 0x6ca108 Call_expression::do_export(Export_function_body*) const ../../gcc-trunk/gcc/go/gofrontend/expressions.cc:12226 0x7481c2 Expression::export_expression(Export_function_body*) const ../../gcc-trunk/gcc/go/gofrontend/expressions.h:1054 0x7481c2 Variable_declaration_statement::do_export_statement(Export_function_body*) ../../gcc-trunk/gcc/go/gofrontend/statements.cc:447 0x6fe68b Statement::export_statement(Export_function_body*) ../../gcc-trunk/gcc/go/gofrontend/statements.h:339 0x6fe68b Block::export_block(Export_function_body*) ../../gcc-trunk/gcc/go/gofrontend/gogo.cc:6852 0x74c0e1 Block_statement::export_block(Export_function_body*, Block*, bool) ../../gcc-trunk/gcc/go/gofrontend/statements.cc:2143 0x6fe68b Statement::export_statement(Export_function_body*) ../../gcc-trunk/gcc/go/gofrontend/statements.h:339 0x6fe68b Block::export_block(Export_function_body*) ../../gcc-trunk/gcc/go/gofrontend/gogo.cc:6852 0x6fee14 Function::export_func_with_type(Export*, Named_object const*, Function_type const*, std::vector<Named_object*, std::allocator<Named_object*> >*, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Block*, Location) ../../gcc-trunk/gcc/go/gofrontend/gogo.cc:5914 0x6ff568 Function::export_func(Export*, Named_object const*) const ../../gcc-trunk/gcc/go/gofrontend/gogo.cc:5768 0x704243 Named_object::export_named_object(Export*) const ../../gcc-trunk/gcc/go/gofrontend/gogo.cc:8493 0x75815a Named_type::do_export(Export*) const ../../gcc-trunk/gcc/go/gofrontend/types.cc:11120 0x6ae957 Type::export_type(Export*) const ../../gcc-trunk/gcc/go/gofrontend/types.h:1076 0x6ae957 Export::write_type_definition(Type const*, int) ../../gcc-trunk/gcc/go/gofrontend/export.cc:1097 0x6aec27 Export::write_types(int) ../../gcc-trunk/gcc/go/gofrontend/export.cc:1034 0x6b32f3 Export::export_globals(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, Package*, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Package*> > > const&, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, Package*, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Package*> > > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Import_init_set const&, Bindings const*) ../../gcc-trunk/gcc/go/gofrontend/export.cc:368
Looks at first blush like a problem with building the package index.

@thanm thanm added this to the Gccgo milestone Jun 25, 2019
@thanm thanm self-assigned this Jun 25, 2019
@thanm
Copy link
Contributor Author

thanm commented Jun 25, 2019

I think the issue here is that we picked up indirectly imported packages via the Find_types_to_prepare traversal in exports.cc, and this traversal is not looking at call expressions (hence it misses the fact that the pf.FullName.Name method calls strings.LastIndexByte, hence it misses the indirectly imported strings package. I will work on some sort of a fix for this.

@gopherbot
Copy link

Change https://golang.org/cl/183850 mentions this issue: compiler: fix buglet in exporter's package tracking

@thanm
Copy link
Contributor Author

thanm commented Jun 25, 2019

I have a tentative fix. Also worth noting -- it seems we could get this same type of problem with references to global variables; I tried to write a test case that would trigger this but wasn't successful (mainly since the compiler decided not to export the routine).

@gopherbot
Copy link

Change https://golang.org/cl/183851 mentions this issue: test: add testcase for gccgo compile failure

gopherbot pushed a commit that referenced this issue Jul 2, 2019
Test case that caused a compiler crash in gofrontend, related to
exporting inlinable function bodies.

Updates #32778

Change-Id: Iacf1753825d5359da43e5e281189876d4c3dd3c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/183851
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
kraj pushed a commit to kraj/gcc that referenced this issue Jul 3, 2019
    
    Revamps the way the exporter tracks exported types and imported
    packages that need to be mentioned in the export data.
    
    The previous implementation wasn't properly handling the case where an
    exported non-inlinable function refers to an imported type whose
    method set includes an inlinable function whose body makes a call to a
    function in another package that's not directly used in the original
    package.
    
    This patch integrates together two existing traversal helper classes,
    "Collect_references_from_inline" and "Find_types_to_prepare" into a
    single helper "Collect_export_references", so as to have common/shared
    code that looks for indirectly imported packages.
    
    Fixes golang/go#32778
    
    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/183850


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@272955 138bc75d-0d04-0410-961f-82ee72b054a4
@golang golang locked and limited conversation to collaborators Jul 2, 2020
asiekierka pushed a commit to WonderfulToolchain/gcc-ia16 that referenced this issue May 16, 2022
    
    Revamps the way the exporter tracks exported types and imported
    packages that need to be mentioned in the export data.
    
    The previous implementation wasn't properly handling the case where an
    exported non-inlinable function refers to an imported type whose
    method set includes an inlinable function whose body makes a call to a
    function in another package that's not directly used in the original
    package.
    
    This patch integrates together two existing traversal helper classes,
    "Collect_references_from_inline" and "Find_types_to_prepare" into a
    single helper "Collect_export_references", so as to have common/shared
    code that looks for indirectly imported packages.
    
    Fixes golang/go#32778
    
    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/183850

From-SVN: r272955
@rsc rsc unassigned thanm Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants