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

cmd/compile: global variable references have weird line numbers #15430

Closed
randall77 opened this issue Apr 24, 2016 · 4 comments
Closed

cmd/compile: global variable references have weird line numbers #15430

randall77 opened this issue Apr 24, 2016 · 4 comments
Milestone

Comments

@randall77
Copy link
Contributor

package main

import "os"

func main() {
    x := os.Stdout
    x.WriteString("foo\n")
}

When I compile this with SSA, I get:

    0x0013 00019 (tmp.go:3) MOVQ    os.Stdout(SB), AX

Note the line number. It's the line number of the import statement, not the line number where os.Stdout is mentioned.

This bug comes from earlier in the pipeline than the SSA backend. On input to SSA, we have:

.   AS u(2) l(6) colas(true) tc(1)
.   .   NAME-main.x u(1) a(true) g(1) l(6) x(0+0) class(PAUTO) f(1) tc(1) used(true) PTR64-*os.File
.   .   NAME-os.Stdout u(1) a(true) l(3) x(0+0) class(PEXTERN) tc(1) used(true) PTR64-*os.File

Note the l(3) on the os.Stdout reference.

I suspect the old compiler ends up using the line number of the AS, so it is ok, whereas the SSA compiler uses the line number for the NAME.

Probably a dup of #14742

See issue #15427

@davecheney

@randall77 randall77 added this to the Go1.7 milestone Apr 24, 2016
@minux
Copy link
Member

minux commented Apr 24, 2016 via email

@mdempsky
Copy link
Member

All references to an imported object share the same ONAME Node, so their line numbers (at least currently) have to correspond to the definition line rather than the usage line.

@mdempsky
Copy link
Member

It looks like this should just be a matter of avoiding the s.pushLine(n.Lineno) call in (*state).expr for ONAME Nodes. Maybe for named OLITERAL Nodes too.

@mdempsky mdempsky self-assigned this Apr 26, 2016
@gopherbot
Copy link

CL https://golang.org/cl/22479 mentions this issue.

@mdempsky mdempsky assigned randall77 and unassigned mdempsky Apr 26, 2016
@golang golang locked and limited conversation to collaborators Apr 27, 2017
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

4 participants