Skip to content

Compile breaks due to incorrect type #132

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.

Sign up for GitHub

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
Closed
gopherbot opened this issue Nov 13, 2009 · 7 comments
Closed

Compile breaks due to incorrect type #132

gopherbot opened this issue Nov 13, 2009 · 7 comments
Labels
FrozenDueToAge

Comments

@gopherbot
Copy link
Contributor

by anthonyjbentley:

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull -u" and retry what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. Run all.bash
2. Wait for it to break while making gopack

What is the expected output? What do you see instead?
Expect to see gopack compile. Instead:

%%%% making gopack %%%%

quietgcc -ggdb -I/home/anthony/golang/include -O2 -fno-inline -c
/home/anthony/golang/src/cmd/gopack/ar.c
/home/anthony/golang/src/cmd/gopack/ar.c:1222: warning: passing arg 1 of
`ctime' from incompatible pointer type
make: *** [ar.o] Error 1

What is your $GOOS?  $GOARCH?
linux/386
Building on OpenBSD. I don't expect everything to work, but this issue at
least can be fixed.

Which revision are you sync'ed to?  (hg log -l 1)
changeset:   4021:3d43362ac8d4
tag:         tip
user:        Kevin Ballard <kevin@sb.org>
date:        Thu Nov 12 18:40:42 2009 -0800
summary:     Teach emacs M-x gofmt to save region/restrictions

Please provide any additional information below.
Fixed with the attached diff.

cdate() is being passed a long, this changes it to time_t.

Attachments:

  1. golang.diff (243 bytes)
@agl
Copy link
Contributor

agl commented Nov 13, 2009

Comment 1:

I suspect that you aren't synced up to the revision that you think you are. This issue 
was fixed in [1] that I landed yesterday.
Maybe try checking out again to be sure?
[1] http://code.google.com/p/go/source/detail?
spec=svn3d43362ac8d428230b19daad6c1047f680442604&r=45e4ed9236073aba0974156b9682068699272f
c3

Owner changed to a...@golang.org.

Status changed to WaitingForReply.

@gopherbot
Copy link
Contributor Author

Comment 2 by anthonyjbentley:

I was sloppy; after updating I had only checked the declaration without realizing it
could be fixed elsewhere. Didn't actually run the scripts.
Sorry for the noise.

@robpike
Copy link
Contributor

robpike commented Nov 13, 2009

Comment 3:

Status changed to Fixed.

@tylerarnold tylerarnold mentioned this issue Feb 6, 2015
Closed
minux added a commit to minux/goios that referenced this issue Feb 27, 2015
@minux
liblink: restore SP and LR before RETJMP
67867c5 
I believe the Power64 port is also affected by this issue.

Test program:
    package main
    type T1 struct{}
    type R struct {
    	pad [128]byte
    }
    func (t *T1) M() (r R) { // has a large out param so duffzero is called in its wrappers
    	println(t)
    	return
    }
    type T2 struct {
    	T1
    }
    type I interface {
    	M() R
    }
    func smash() {
    	var x [128]int
    	for i := range x {
    		x[i] = 0xdead
    	}
    }
    func main() {
    	var t I = &T2{} // use interface to force it to go through (*T2).M
    	smash()         // poison the stack slots
    	t.M()
    	println("OK")
    }

Fixes golang#132.
@gopherbot
Copy link
Contributor Author

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

josharian added a commit that referenced this issue Jun 4, 2015
@josharian
runtime, cmd/internal/obj/arm: improve arm function prologue
5353cde 
When stack growth is not needed, as it usually is not,
execute only a single conditional branch
rather than three conditional instructions.
This adds 4 bytes to every function,
but might speed up execution in the common case.

Sample disassembly for

func f() {
	_ = [128]byte{}
}

Before:

TEXT main.f(SB) x.go
	x.go:3	0x2000	e59a1008	MOVW 0x8(R10), R1
	x.go:3	0x2004	e59fb028	MOVW 0x28(R15), R11
	x.go:3	0x2008	e08d200b	ADD R11, R13, R2
	x.go:3	0x200c	e1520001	CMP R1, R2
	x.go:3	0x2010	91a0300e	MOVW.LS R14, R3
	x.go:3	0x2014	9b0118a9	BL.LS runtime.morestack_noctxt(SB)
	x.go:3	0x2018	9afffff8	B.LS main.f(SB)
	x.go:3	0x201c	e52de084	MOVW.W R14, -0x84(R13)
	x.go:4	0x2020	e28d1004	ADD $4, R13, R1
	x.go:4	0x2024	e3a00000	MOVW $0, R0
	x.go:4	0x2028	eb012255	BL 0x4a984
	x.go:5	0x202c	e49df084	RET #132
	x.go:5	0x2030	eafffffe	B 0x2030
	x.go:5	0x2034	ffffff7c	?

After:

TEXT main.f(SB) x.go
	x.go:3	0x2000	e59a1008	MOVW 0x8(R10), R1
	x.go:3	0x2004	e59fb02c	MOVW 0x2c(R15), R11
	x.go:3	0x2008	e08d200b	ADD R11, R13, R2
	x.go:3	0x200c	e1520001	CMP R1, R2
	x.go:3	0x2010	9a000004	B.LS 0x2028
	x.go:3	0x2014	e52de084	MOVW.W R14, -0x84(R13)
	x.go:4	0x2018	e28d1004	ADD $4, R13, R1
	x.go:4	0x201c	e3a00000	MOVW $0, R0
	x.go:4	0x2020	eb0124dc	BL 0x4b398
	x.go:5	0x2024	e49df084	RET #132
	x.go:5	0x2028	e1a0300e	MOVW R14, R3
	x.go:5	0x202c	eb011b0d	BL runtime.morestack_noctxt(SB)
	x.go:5	0x2030	eafffff2	B main.f(SB)
	x.go:5	0x2034	eafffffe	B 0x2034
	x.go:5	0x2038	ffffff7c	?

Updates #10587.

package sort benchmarks on an iPhone 6:

name            old time/op  new time/op  delta
SortString1K     569µs ± 0%   565µs ± 1%  -0.75%  (p=0.000 n=23+24)
StableString1K   872µs ± 1%   870µs ± 1%  -0.16%  (p=0.009 n=23+24)
SortInt1K        317µs ± 2%   316µs ± 2%    ~     (p=0.410 n=26+26)
StableInt1K      343µs ± 1%   339µs ± 1%  -1.07%  (p=0.000 n=22+23)
SortInt64K      30.0ms ± 1%  30.0ms ± 1%    ~     (p=0.091 n=25+24)
StableInt64K    30.2ms ± 0%  30.0ms ± 0%  -0.69%  (p=0.000 n=22+22)
Sort1e2          147µs ± 1%   146µs ± 0%  -0.48%  (p=0.000 n=25+24)
Stable1e2        290µs ± 1%   286µs ± 1%  -1.30%  (p=0.000 n=23+24)
Sort1e4         29.5ms ± 2%  29.7ms ± 1%  +0.71%  (p=0.000 n=23+23)
Stable1e4       88.7ms ± 4%  88.6ms ± 8%  -0.07%  (p=0.022 n=26+26)
Sort1e6          4.81s ± 7%   4.83s ± 7%    ~     (p=0.192 n=26+26)
Stable1e6        18.3s ± 1%   18.1s ± 1%  -0.76%  (p=0.000 n=25+23)
SearchWrappers   318ns ± 1%   344ns ± 1%  +8.14%  (p=0.000 n=23+26)

package sort benchmarks on a first generation rpi:

name            old time/op  new time/op  delta
SearchWrappers  4.13µs ± 0%  3.95µs ± 0%   -4.42%  (p=0.000 n=15+13)
SortString1K    5.81ms ± 1%  5.82ms ± 2%     ~     (p=0.400 n=14+15)
StableString1K  9.69ms ± 1%  9.73ms ± 0%     ~     (p=0.121 n=15+11)
SortInt1K       3.30ms ± 2%  3.66ms ±19%  +10.82%  (p=0.000 n=15+14)
StableInt1K     5.97ms ±15%  4.17ms ± 8%  -30.05%  (p=0.000 n=15+15)
SortInt64K       319ms ± 1%   295ms ± 1%   -7.65%  (p=0.000 n=15+15)
StableInt64K     343ms ± 0%   332ms ± 0%   -3.26%  (p=0.000 n=12+13)
Sort1e2         3.36ms ± 2%  3.22ms ± 4%   -4.10%  (p=0.000 n=15+15)
Stable1e2       6.74ms ± 1%  6.43ms ± 2%   -4.67%  (p=0.000 n=15+15)
Sort1e4          247ms ± 1%   247ms ± 1%     ~     (p=0.331 n=15+14)
Stable1e4        864ms ± 0%   820ms ± 0%   -5.15%  (p=0.000 n=14+15)
Sort1e6          41.2s ± 0%   41.2s ± 0%   +0.15%  (p=0.000 n=13+14)
Stable1e6         192s ± 0%    182s ± 0%   -5.07%  (p=0.000 n=14+14)

Change-Id: I8a9db77e1d4ea1956575895893bc9d04bd81204b
Reviewed-on: https://go-review.googlesource.com/10497
Reviewed-by: Russ Cox <rsc@golang.org>
@golang golang locked and limited conversation to collaborators Jun 24, 2016
@gopherbot
Copy link
Contributor Author

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

@odeke-em
Copy link
Member

/cc our resident bot guru @bradfitz, seems like a phantom CL here that closed this issue
screen shot 2017-04-10 at 11 55 44 am

@bradfitz
Copy link
Contributor

Gerrit is having issues.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@bradfitz @agl @robpike @odeke-em @gopherbot