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: unneeded hash/equal functions emitted for runtime types #19773

Open
thanm opened this issue Mar 29, 2017 · 2 comments
Open

gccgo: unneeded hash/equal functions emitted for runtime types #19773

thanm opened this issue Mar 29, 2017 · 2 comments
Milestone

Comments

@thanm
Copy link
Contributor

thanm commented Mar 29, 2017

Please answer these questions before submitting your issue. Thanks!

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

gccgo trunk/tip
go version devel +7e817859b3 Mon Mar 27 18:51:42 2017 +0000 linux/amd64

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

GOARCH="amd64"
GOOS="linux"

What did you do?

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

https://play.golang.org/p/tl4iNxoar6

What did you expect to see?

This program compiles and builds with gccgo, however I note that the compiler is generating more hash/equal functions that it needs to. In particular, it seems to have decided that it should generate hash/equal functions for the anonymous type corresponding to the BySize field in runtime.MemStats, along with a few other runtime types. This is not a bad thing from a correctness point of view, but it results in extra wasted work at compile time and link time, as well as object file bloat.

What did you see instead?

I would expect that the compiler would be able to recognize that the type in question is in an external package and that the hash/equal functions can be picked up externally.

@thanm thanm added this to the Gccgo milestone Mar 29, 2017
@thanm thanm self-assigned this Mar 29, 2017
@gopherbot
Copy link

Change https://golang.org/cl/130956 mentions this issue: test: add fixedbugs/bug506 for gccgo

gopherbot pushed a commit that referenced this issue Oct 18, 2018
Building with gccgo failed with an undefined symbol error from an
unnecessary hash function.

Updates #19773

Change-Id: Ic78bf1b086ff5ee26d464089c0e14987d3fe8b02
Reviewed-on: https://go-review.googlesource.com/c/130956
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@gopherbot
Copy link

Change https://golang.org/cl/194337 mentions this issue: compiler: don't use predeclared location for implicit runtime import

gopherbot pushed a commit to golang/gofrontend that referenced this issue Sep 9, 2019
For the main package we add an implicit import of the runtime package,
to ensure that it is initialized.  That import used the predeclared
location, which caused various tests, notably Named_type::is_builtin,
to treat these imported names as builtin.  Start using a real location,
so that those tests do the right thing.

By the way, this implicit import is a partial cause of golang/go#19773.

Change-Id: I2137cefa679db519c63e17a3e94c1e5c4c5459a9
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/194337
Reviewed-by: Than McIntosh <thanm@google.com>
iains pushed a commit to iains/gcc-git that referenced this issue Sep 9, 2019
    
    For the main package we add an implicit import of the runtime package,
    to ensure that it is initialized.  That import used the predeclared
    location, which caused various tests, notably Named_type::is_builtin,
    to treat these imported names as builtin.  Start using a real location,
    so that those tests do the right thing.
    
    By the way, this implicit import is a partial cause of golang/go#19773.
    
    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/194337


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@275540 138bc75d-0d04-0410-961f-82ee72b054a4
asiekierka pushed a commit to WonderfulToolchain/gcc-ia16 that referenced this issue May 16, 2022
    
    For the main package we add an implicit import of the runtime package,
    to ensure that it is initialized.  That import used the predeclared
    location, which caused various tests, notably Named_type::is_builtin,
    to treat these imported names as builtin.  Start using a real location,
    so that those tests do the right thing.
    
    By the way, this implicit import is a partial cause of golang/go#19773.
    
    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/194337

From-SVN: r275540
@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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants