1
0
mirror of https://github.com/golang/go synced 2024-11-05 14:46:11 -07:00
Commit Graph

912 Commits

Author SHA1 Message Date
Ian Lance Taylor
e9fcd6ed2b cmd/link: if -B option was used, pass it to the external linker
Fixes #10607.

Change-Id: Ib294cf65b07103b60f62b86b21ff2d07b25136fe
Reviewed-on: https://go-review.googlesource.com/12242
Reviewed-by: Russ Cox <rsc@golang.org>
2015-07-21 03:57:55 +00:00
Ian Lance Taylor
dabb268170 cmd/compile: ignore carriage return in magic comments
Update #11771.

Change-Id: I3bb3262619765d3ca79652817e17e8f260f41907
Reviewed-on: https://go-review.googlesource.com/12379
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2015-07-18 17:33:53 +00:00
Russ Cox
19916e453e test/fixedbugs: disable issue11656.go on arm64
For #11656.

Change-Id: I8365d33a15419bd0e54f71182ad0994e41650264
Reviewed-on: https://go-review.googlesource.com/12248
Reviewed-by: Russ Cox <rsc@golang.org>
2015-07-16 02:16:20 +00:00
Ian Lance Taylor
2e4b659954 cmd/compile: recognize embedded field in inlined function
There was already special code to recognize "?" in hidden_structdcl,
which is used for inlined types and variables.  This recognizes "?" in
structdcl as well, a case that arises when a struct type appears
within an inlined function body.

Fixes #10219.

Change-Id: Ic5257ae54f817e0d4a189c2294dcd633c9f2101a
Reviewed-on: https://go-review.googlesource.com/12241
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-07-15 06:04:51 +00:00
Russ Cox
0bcdffeea6 runtime: fix x86 stack trace for call to heap memory
Fixes #11656.

Change-Id: Ib81d583e4b004e67dc9d2f898fd798112434e7a9
Reviewed-on: https://go-review.googlesource.com/12026
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
2015-07-13 19:42:35 +00:00
Brad Fitzpatrick
2ae77376f7 all: link to https instead of http
The one in misc/makerelease/makerelease.go is particularly bad and
probably warrants rotating our keys.

I didn't update old weekly notes, and reverted some changes involving
test code for now, since we're late in the Go 1.5 freeze. Otherwise,
the rest are all auto-generated changes, and all manually reviewed.

Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d
Reviewed-on: https://go-review.googlesource.com/12048
Reviewed-by: Rob Pike <r@golang.org>
2015-07-11 14:36:33 +00:00
Russ Cox
6f80e5edf4 cmd/link: reject data size > 2 GB
We can't address more than this on amd64 anyway.

Fixes #9862.

Change-Id: Ifb1abae558e2e1ee2dc953a76995f3f08c60b1df
Reviewed-on: https://go-review.googlesource.com/11715
Reviewed-by: Austin Clements <austin@google.com>
2015-06-30 19:40:39 +00:00
Russ Cox
1122836b5f cmd/compile: reject large floating point exponents without math/big
For #11326 (but not a fix).

Change-Id: Ic51814f5cd7357427c3fd990a5522775d05e7987
Reviewed-on: https://go-review.googlesource.com/11673
Reviewed-by: Robert Griesemer <gri@golang.org>
2015-06-29 21:18:01 +00:00
Russ Cox
55203c7dd5 cmd/compile: allow unnamed constants to set line number
Fixes #8836.

Change-Id: Idda9f4a987e03b3bdf5e8fdb984fe56d6f84aa59
Reviewed-on: https://go-review.googlesource.com/11672
Reviewed-by: David Chase <drchase@google.com>
2015-06-29 17:35:55 +00:00
Austin Clements
840965f8d7 runtime: always clear stack barriers on G exit
Currently the runtime fails to clear a G's stack barriers in gfput if
the G's stack allocation is _FixedStack bytes. This causes the runtime
to panic if the following sequence of events happens:

1) The runtime installs stack barriers on a G.

2) The G exits by calling runtime.Goexit. Since this does not
   necessarily return through the stack barriers installed on the G,
   there may still be untriggered stack barriers left on the G's stack
   in recorded in g.stkbar.

3) The runtime calls gfput to add the exiting G to the free pool. If
   the G's stack allocation is _FixedStack bytes, we fail to clear
   g.stkbar.

4) A new G starts and allocates the G that was just added to the free
   pool.

5) The new G begins to execute and overwrites the stack slots that had
   stack barriers in them.

6) The garbage collector enters mark termination, attempts to remove
   stack barriers from the new G, and finds that they've been
   overwritten.

Fix this by clearing the stack barriers in gfput in the case where it
reuses the stack.

Fixes #11256.

Change-Id: I377c44258900e6bcc2d4b3451845814a8eeb2bcf
Reviewed-on: https://go-review.googlesource.com/11461
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-06-29 15:02:30 +00:00
Dave Cheney
834fef80ae test: add test case for issue 8154
Updates #8154

Change-Id: Ie9c731a91b008277e51c723eef6871bb0919fa4c
Reviewed-on: https://go-review.googlesource.com/10831
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-06-26 17:58:22 +00:00
Todd Neal
765c0f37ed cmd/compile: fix half multiply issue
In walkdiv, an OMUL node was created and passed to typecheck,
before the op was changed back to OHMUL.  In some instances,
the node that came back was an evaluated literal constant that
occurred with a full multiply.  The end result was a literal node
with a non-shifted value and an OHMUL op. This change causes code
to be generated for the OHMUL.

Fixes #11358
Fixes #11369

Change-Id: If42a98c6830d07fe065d5ca57717704fb8cfbd33
Reviewed-on: https://go-review.googlesource.com/11400
Reviewed-by: Russ Cox <rsc@golang.org>
2015-06-26 15:55:22 +00:00
Austin Clements
a8ae93fd26 runtime: fix heap bitmap repeating with large scalar tails
When heapBitsSetType repeats a source bitmap with a scalar tail
(typ.ptrdata < typ.size), it lays out the tail upon reaching the end
of the source bitmap by simply increasing the number of bits claimed
to be in the incoming bit buffer. This causes later iterations to read
the appropriate number of zeros out of the bit buffer before starting
on the next repeat of the source bitmap.

Currently, however, later iterations of the loop continue to read bits
from the source bitmap *regardless of the number of bits currently in
the bit buffer*. The bit buffer can only hold 32 or 64 bits, so if the
scalar tail is large and the padding bits exceed the size of the bit
buffer, the read from the source bitmap on the next iteration will
shift the incoming bits into oblivion when it attempts to put them in
the bit buffer. When the buffer does eventually shift down to where
these bits were supposed to be, it will contain zeros. As a result,
words that should be marked as pointers on later repetitions are
marked as scalars, so the garbage collector does not trace them. If
this is the only reference to an object, it will be incorrectly freed.

Fix this by adding logic to drain the bit buffer down if it is large
instead of reading more bits from the source bitmap.

Fixes #11286.

Change-Id: I964432c4b9f1cec334fc8c3da0ff16460203feb6
Reviewed-on: https://go-review.googlesource.com/11360
Reviewed-by: Russ Cox <rsc@golang.org>
2015-06-23 18:37:17 +00:00
Michael Matloob
32f2f72c47 cmd/compile: provide better error when method called without receiver
When a method is called using the Type.Method(receiver, args...) syntax
without the receiver, or enough arguments, provide the more helpful
error message "not enough arguments in call to method expression
Type.Method" instead of the old message "not enough arguments in call
to Type.Method".

Fixes #8385

Change-Id: Id5037eb1ee5fa93687d4a6557b4a8233b29e9df2
Reviewed-on: https://go-review.googlesource.com/2193
Reviewed-by: Russ Cox <rsc@golang.org>
2015-06-18 19:37:38 +00:00
David Chase
5be61b18d4 cmd/compile: run escape analysis after method wrapper generation
Also modified test/run.go to ignore messages prefixed <autogenerated>
because those cannot be described with "// ERROR ...", and backed out
patch from issue #9537 because it is no longer necessary.  The reasons
described in the 9537 discussion for why escape analysis cannot run
late no longer hold, happily.

Fixes #11053.

Change-Id: Icb14eccdf2e8cde3d0f8fb8a216b765400a96385
Reviewed-on: https://go-review.googlesource.com/11088
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Chase <drchase@google.com>
2015-06-17 02:36:45 +00:00
Josh Bleecher Snyder
a44becef4a cmd/compile: use generated temps in bool codegen
Bool codegen was generating a temp for function calls
and other complex expressions, but was not using it.

This was a refactoring bug introduced by CL 7853.
The cmp code used to do (in short):

	l, r := &n1, &n2

It was changed to:

	l, r := nl, nr

But the requisite assignments:

	nl, nr = &n1, &n2

were only introduced on one of two code paths.

Fixes #10654.

Change-Id: Ie8de0b3a333842a048d4308e02911bb10c6915ce
Reviewed-on: https://go-review.googlesource.com/10844
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2015-06-09 17:38:26 +00:00
Josh Bleecher Snyder
494ff188f8 cmd/compile: early typecheck top level OAS2 nodes
Fixes #10977.

Change-Id: I706c953c16daad48595c7fae2d82124614dfc3ad
Reviewed-on: https://go-review.googlesource.com/10780
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
2015-06-09 00:25:02 +00:00
David Chase
596bb76248 cmd/compile: reject p-notation floats in Go source files
Use pkgimport == nil (or not) to distinguish between
parsing .go source files where "p" exponent specifier
is not allowed and parsing .a or .o export data where
it is.  Use that to control error when p-exponent is
seen.

Fixes #9036

Change-Id: I8924f09c91d4945ef3f20e80a6e544008a94a7e4
Reviewed-on: https://go-review.googlesource.com/10450
Reviewed-by: Russ Cox <rsc@golang.org>
2015-05-28 18:52:14 +00:00
David Chase
05d8f1d166 cmd/compile: propagate correct line numbers in treecopy
Added a lineno parameter to treecopy and listtreecopy
(ignored if = 0).  When nodes are copied the copy is
assigned the non-zero lineno (normally this would be
the destination).

Fixes #8183

Change-Id: Iffb767a745093fb89aa08bf8a7692c2f0122be98
Reviewed-on: https://go-review.googlesource.com/10334
Reviewed-by: Russ Cox <rsc@golang.org>
2015-05-27 17:29:15 +00:00
David Chase
b19ec6842d cmd/internal/gc: make indirect calls properly escape-y
Indirect function and method calls should leak everything,
but they didn't.

This fix had no particular effect on the cost of running the
compiler on html/template/*.go and added a single new "escape"
to the standard library:

    syscall/syscall_unix.go:85: &b[0] escapes to heap
in
	if errno := m.munmap(uintptr(unsafe.Pointer(&b[0])),
	                     uintptr(len(b))); errno != nil {

Added specific escape testing to escape_calls.go
(and verified that it fails without this patch)

I also did a little code cleanup around the changes in esc.c.

Fixes #10925

Change-Id: I9984b701621ad4c49caed35b01e359295c210033
Reviewed-on: https://go-review.googlesource.com/10295
Reviewed-by: Russ Cox <rsc@golang.org>
2015-05-22 01:36:11 +00:00
Russ Cox
cf932cd897 all: retire architecture letter in file names, public API
This CL removes the remaining visible uses of the "architecture letter" concept.
(They are no longer in tool names nor in source directory names.)

Because the architecture letter concept is now gone, delete GOCHAR
from "go env" output, and change go/build.ArchChar to return an
error always.

The architecture letter is still used in the compiler and linker sources
as a clumsy architecture enumeration, but that use is not visible to
Go users and can be cleaned up separately.

Change-Id: I4d97a38f372003fb610c9c5241bea440d9dbeb8d
Reviewed-on: https://go-review.googlesource.com/10289
Reviewed-by: Rob Pike <r@golang.org>
2015-05-21 17:32:17 +00:00
Russ Cox
0f4132c907 all: build and use go tool compile, go tool link
This CL fixes the build to use the newly created go tool compile
and go tool link in place of go tool 5g, go tool 5l, and so on.

See golang-dev thread titled "go tool compile, etc" for background.

Although it was not a primary motivation, this conversion does
reduce the wall clock time and cpu time required for make.bash
by about 10%.

Change-Id: I79cbbdb676cab029db8aeefb99a53178ff55f98d
Reviewed-on: https://go-review.googlesource.com/10288
Reviewed-by: Rob Pike <r@golang.org>
2015-05-21 17:32:03 +00:00
Russ Cox
c735064cde cmd/internal/gc: type of str[i] is byte, not uint8
Fixes #8745.

Change-Id: Id0641e3c0f259812b41ed871e83c68740feb2b19
Reviewed-on: https://go-review.googlesource.com/10261
Reviewed-by: Austin Clements <austin@google.com>
2015-05-19 19:20:25 +00:00
Robert Griesemer
99475dfb59 cmd/internal/gc: avoid spurious div-zero errors
Set overflowing integer constants to 1 rather than 0 to avoid
spurious div-zero errors in subsequent constant expressions.

Also: Exclude new test case from go/types test since it's
running too long (go/types doesn't have an upper constant
size limit at the moment).

Fixes #7746.

Change-Id: I3768488ad9909a3cf995247b81ee78a8eb5a1e41
Reviewed-on: https://go-review.googlesource.com/9165
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-05-13 17:38:13 +00:00
Russ Cox
3f209abb29 cmd/internal/gc: detect bad append(f()) during type check
Today's earlier fix can stay, but it's a band-aid over the real problem,
which is that bad code was slipping through the type checker
into the back end (and luckily causing a type error there).

I discovered this because my new append does not use the same
temporaries and failed the test as written.

Fixes #9521.

Change-Id: I7e33e2ea15743406e15c6f3fdf73e1edecda69bd
Reviewed-on: https://go-review.googlesource.com/9921
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2015-05-12 16:26:35 +00:00
Didier Spezia
7c0db1b7e2 cmd/gc: do not display ~b identifiers in error messages
Instead of errors like:

./blank2.go:15: cannot use ~b1 (type []int) as type int in assignment

we now have:

./blank2.go:15: cannot use _ (type []int) as type int in assignment

Less confusing for users.

Fixes #9521

Change-Id: Ieab9859040e8e0df95deeaee7eeb408d3be61c0f
Reviewed-on: https://go-review.googlesource.com/9902
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2015-05-11 17:44:31 +00:00
David Chase
d4bb72b485 cmd/internal/gc: improve "type *X has no field or method M" message
Try to provide hints for common areas, either *interface
were interface would have been better, and note incorrect
capitalization (but don't be more ambitious than that, at
least not today).

Added code and test for cases

  ptrInterface.ExistingMethod
  ptrInterface.unexportedMethod
  ptrInterface.MissingMethod
  ptrInterface.withwRongcASEdMethod
  interface.withwRongcASEdMethod
  ptrStruct.withwRongcASEdMethod
  struct.withwRongcASEdMethod

also included tests for related errors to check for
unintentional changes and consistent wording.

Somewhat simplified from previous versions to avoid second-
guessing user errors, yet also biased to point out most-likely
root cause.

Fixes #10700

Change-Id: I16693e93cc8d8ca195e7742a222d640c262105b4
Reviewed-on: https://go-review.googlesource.com/9731
Reviewed-by: Russ Cox <rsc@golang.org>
2015-05-07 16:21:57 +00:00
David Chase
7fbb1b36c3 cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:

outK = paramJ   encoded in outK bits for paramJ
outK = *paramJ  encoded in outK bits for paramJ
heap = paramJ   EscHeap
heap = *paramJ  EscContentEscapes

Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.

The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)

A new test was  added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm.  Another new test checks
(some) correctness with array parameters, results, and operations.

The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result.  A test was added against the discovered bug.

The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.

With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.

Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).

Profiling allocations in src/html/template with
for i in {1..5} ;
  do go tool 6g -memprofile=mastx.${i}.prof  -memprofilerate=1 *.go;
  go tool pprof -alloc_objects -text  mastx.${i}.prof ;
done

showed a 15% reduction in allocations performed by the compiler.

Update #3753
Update #4720
Fixes #10466

Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-05-01 13:47:20 +00:00
Josh Bleecher Snyder
1fb948a029 test: set GOMAXPROCS=1 in fixedbugs/issue9110
With this fix,

GOMAXPROCS=8 ./all.bash

passes, at least on my machine.

Fixes #10216.

Change-Id: Ib5991950892a1399ec81aced0a52b435e6f83fdf
Reviewed-on: https://go-review.googlesource.com/9392
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2015-04-28 00:06:13 +00:00
Michael Hudson-Doyle
b92a0a8969 cmd/internal/gc, cmd/go: fix value of importpath symbol
In https://golang.org/cl/7797 I attempted to use myimportpath to set the value
of the go.importpath.$foo. symbol for the module being compiled, but I messed
it up and only set the name (which the linker rewrites anyway). This lead to
the importpath for the module being compiled being "". This was hard to notice,
because all modules that import another define the importpath for their
imported modules correctly -- but main is not imported, and this meant that the
reflect module saw all fields of all types defined in the main module as
exported.

The fix is to do what I meant to do the first time, add a test and change the
go tool to compile main packages with -p main and not -p
command-line-arguments.

Fixes #10332

Change-Id: I5fc6e9b1dc2b26f058641e382f9a56a526eca291
Reviewed-on: https://go-review.googlesource.com/8481
Reviewed-by: Russ Cox <rsc@golang.org>
2015-04-19 20:14:59 +00:00
Dmitry Vyukov
24f246c1b6 cmd/gc: fix crash during escape analysis
Fixes #10441

Compiler crashed as:

panic: runtime error: invalid memory address or nil pointer dereference
goroutine 1 [running]:
cmd/internal/gc.haspointers(0x0, 0xffffffffffffffff)
    src/cmd/internal/gc/reflect.go:623 +0x1f
cmd/internal/gc.escwalk(0x20c82dc00, 0xffffffffffffffff, 0x20c82dda0, 0x20c835520)
    src/cmd/internal/gc/esc.go:1291 +0x14aa
cmd/internal/gc.escwalk(0x20c82dc00, 0xffffffffffffffff, 0x20c82dda0, 0x20beac340)
    src/cmd/internal/gc/esc.go:1386 +0x836

while evaluating haspointers of the fake OADDR node here:

	leaks = level <= 0 && dst.Escloopdepth < src.Escloopdepth || level < 0 && dst == &e.funcParam && haspointers(src.Type)

Change-Id: I13c23fced52e8fcd0ae1df81b374df8632eb7790
Reviewed-on: https://go-review.googlesource.com/8932
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2015-04-14 15:45:26 +00:00
Ian Lance Taylor
607d5158c1 test: add gcc65755.go for http://gcc.gnu.org/PR65755
Change-Id: Ic35dff4c9a7fc6716ef9d5553a7b1769bed9be01
Reviewed-on: https://go-review.googlesource.com/8892
Reviewed-by: Minux Ma <minux@golang.org>
2015-04-13 23:24:30 +00:00
Shenghou Ma
399b3e3230 test: add gccgo test case for #10407
Change-Id: I8d17e2b0fbc529ca7958c75222964a5e419aa3db
Reviewed-on: https://go-review.googlesource.com/8717
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2015-04-10 22:51:46 +00:00
Dmitry Vyukov
878a86a129 cmd/gc: fix escape analysis of closures
Fixes #10353

See test/escape2.go:issue10353. Previously new(int) did not escape to heap,
and so heap-allcated closure was referencing a stack var. This breaks
the invariant that heap must not contain pointers to stack.

Look at the following program:

package main

func main() {
	foo(new(int))
	bar(new(int))
}

func foo(x *int) func() {
	return func() {
		println(*x)
	}
}

// Models what foo effectively does.
func bar(x *int) *C {
	return &C{x}
}

type C struct {
	x *int
}

Without this patch escape analysis works as follows:

$ go build -gcflags="-m -m -m -l" esc.go
escflood:1: dst ~r1 scope:foo[0]
escwalk: level:0 depth:0  func literal( l(9) f(1) esc(no) ld(1)) scope:foo[1]
/tmp/live2.go:9: func literal escapes to heap
escwalk: level:0 depth:1 	 x( l(8) class(PPARAM) f(1) esc(no) ld(1)) scope:foo[1]
/tmp/live2.go:8: leaking param: x to result ~r1

escflood:2: dst ~r1 scope:bar[0]
escwalk: level:0 depth:0  &C literal( l(15) esc(no) ld(1)) scope:bar[1]
/tmp/live2.go:15: &C literal escapes to heap
escwalk: level:-1 depth:1 	 &C literal( l(15)) scope:bar[0]
escwalk: level:-1 depth:2 		 x( l(14) class(PPARAM) f(1) esc(no) ld(1)) scope:bar[1]
/tmp/live2.go:14: leaking param: x

/tmp/live2.go:5: new(int) escapes to heap
/tmp/live2.go:4: main new(int) does not escape

new(int) does not escape while being captured by the closure.
With this patch escape analysis of foo and bar works similarly:

$ go build -gcflags="-m -m -m -l" esc.go
escflood:1: dst ~r1 scope:foo[0]
escwalk: level:0 depth:0  &(func literal)( l(9)) scope:foo[0]
escwalk: level:-1 depth:1 	 func literal( l(9) f(1) esc(no) ld(1)) scope:foo[1]
/tmp/live2.go:9: func literal escapes to heap
escwalk: level:-1 depth:2 		 x( l(8) class(PPARAM) f(1) esc(no) ld(1)) scope:foo[1]
/tmp/live2.go:8: leaking param: x

escflood:2: dst ~r1 scope:bar[0]
escwalk: level:0 depth:0  &C literal( l(15) esc(no) ld(1)) scope:bar[1]
/tmp/live2.go:15: &C literal escapes to heap
escwalk: level:-1 depth:1 	 &C literal( l(15)) scope:bar[0]
escwalk: level:-1 depth:2 		 x( l(14) class(PPARAM) f(1) esc(no) ld(1)) scope:bar[1]
/tmp/live2.go:14: leaking param: x

/tmp/live2.go:4: new(int) escapes to heap
/tmp/live2.go:5: new(int) escapes to heap

Change-Id: Ifd14b7ae3fc11820e3b5eb31eb07f35a22ed0932
Reviewed-on: https://go-review.googlesource.com/8408
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2015-04-09 09:56:27 +00:00
Matthew Dempsky
4f2a73011f cmd/internal/gc, cmd/yacc: restore remaining custom error messages
This CL extends cmd/yacc to expose a yyErrorVerbose variable that
changes the error messages from just "syntax error" to "syntax error:
unexpected ${tokname}".

It also moves the yyToknames table generation to after rules have been
processed so that entries can be generated for tokens that aren't
mentioned in the preamble (e.g., '.' in the case of go.y).

Lastly, it restores gc's old code for applying yytfix to yyToknames,
except that substituting "LLITERAL" with litbuf happens in Yyerror.

Fixes #9968.

Change-Id: Icec188d11fdabc1dae31b8a471c35b5c7f6deec7
Reviewed-on: https://go-review.googlesource.com/8432
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2015-04-03 23:40:40 +00:00
David Crawshaw
ca0adeddd5 cmd/7g: reserve registers R26 to R32
These registers are not available for programs to use. Prior to this
change, the compiler would crash attempting to use ZR as a general
purpose register. Other programs would compile but on execution would
overwrite the G register and cause havoc.

Fixes linux/arm64 build.
Fixes #10304
Fixes #10320

Change-Id: I5cf51d3b77cfe3db7dd6377324950cafb02f8d8b
Reviewed-on: https://go-review.googlesource.com/8456
Reviewed-by: Minux Ma <minux@golang.org>
2015-04-03 18:25:09 +00:00
Robert Griesemer
a51d5f27e8 cmd/internal/gc: use 512 bits (rather than 464) for multi-precision arithmetic
The original implementation used 16 int "words" but only 29 bits per word
for a total of 16*29 = 464 bits, with a space consumption of 16*64 = 1024
bits on a 64 bit machine. Switching to 512 bits increases precision while
still using (in the worst case) half the amount of memory per mp value on
a 64 bit machine.

Also: Decreased permitted number of least-significant mantissa bits which
may be incorrect when considering if a precise floating-point constant is
an integer from 29 to 16 bits.

Change-Id: Iee9287056f0e9aa4f06ceac0724ff4674f710c53
Reviewed-on: https://go-review.googlesource.com/8429
Reviewed-by: Russ Cox <rsc@golang.org>
2015-04-03 17:13:07 +00:00
Robert Griesemer
5bb89eb009 cmd/internal/gc: use big.Float to represent Mpflt bits
All multi-precision arithmetic is now based on math/big.

- passes all.bash
- added test cases for fixed bugs

Fixes #7740.
Fixes #6866.

Change-Id: I67268b91766970ced3b928260053ccdce8753d58
Reviewed-on: https://go-review.googlesource.com/7912
Reviewed-by: Russ Cox <rsc@golang.org>
2015-04-02 22:49:47 +00:00
Matthew Dempsky
398bf9d5a0 cmd/internal/gc, cmd/yacc: restore custom syntax error messages
This restores go.errors from before 3af0d79 along with a fixed up
version of the bisonerrors AWK script, translated to Go.

However, this means Yyerror needs access to the yacc parser's state,
which is currently private.  To workaround that, add a "state"
accessor method like the Lookahead method added in c7fa3c6.

Update issue #9968.

Change-Id: Ib868789e92fdb7d135442120a392457923e50121
Reviewed-on: https://go-review.googlesource.com/7270
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2015-04-02 21:56:24 +00:00
David Crawshaw
33448d963c cmd/7g: fix ACMP entry in progtable
On arm64, CMP $foo, R is encoded as from=$foo, reg=R, not as from=$foo,
to=R. The progtable entry for ACMP incorrectly described the latter
form. Because of this, the registerizer was not accounting the registers
used in CMP instructions and was incorrectly re-assigning those registers.

This was an old problem, but it only became apparent after b115c35
(cmd/internal/gc: move cgen, regalloc, et al to portable code). Previous
to this commit, the compiler used a slightly larger register set for the
temps than it used for register variables. Since it had plenty registers
dedicated to temps, the registers used in CMP instruction never clashed
with registers assigned to register variables.

Fixes #10253

Change-Id: Iedf4bd882bd59440dff310ac0f81e0f53d80d7ed
Reviewed-on: https://go-review.googlesource.com/8387
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
2015-04-02 20:18:28 +00:00
Shenghou Ma
73c026e6fe test: add testcase for gccgo-specific issue 10284
Change-Id: I624b336a9eb27fbbc8ef13f141023b4f60966245
Reviewed-on: https://go-review.googlesource.com/8240
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2015-03-30 19:31:35 +00:00
Ian Lance Taylor
362f7bfa68 test: add test that gccgo failed to compile
Change-Id: I9ea6d4d8a9c1c63de36f2f3871dd5ac9201c0aac
Reviewed-on: https://go-review.googlesource.com/7523
Reviewed-by: Minux Ma <minux@golang.org>
2015-03-13 22:05:23 +00:00
Shenghou Ma
0d6a0d6c3f runtime: don't return a slice with nil ptr but non-zero len from growslice
Fixes #10135.

Change-Id: Ic4c5ab15bcb7b9c3fcc685a788d3b59c60c26e1e
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/7400
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2015-03-12 00:08:38 +00:00
Chris Manghane
09b49bf18d test: add testcase for gccgo-specific issue 10047.
Change-Id: Ia5115b15a79e1b2b53036646f1ed4b08225b220f
Reviewed-on: https://go-review.googlesource.com/7051
Run-TryBot: Chris Manghane <cmang@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2015-03-06 22:29:08 +00:00
Shenghou Ma
f09887cdce cmd/internal/gc: do not show original expression for constants in export data
Fixes #10066.

Change-Id: I43c423793dd094989e921e163a06b12181a35719
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/6750
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Chris Manghane <cmang@golang.org>
2015-03-05 03:40:42 +00:00
Chris Manghane
77d7771a82 cmd/internal/gc: omit non-explicit capacity in errors with map/chan make
Fixes #9083.

Change-Id: Ifbdebafb39a73a1dacf7e67171e8e88028d1f10b
Reviewed-on: https://go-review.googlesource.com/1219
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Chris Manghane <cmang@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2015-02-25 20:04:22 +00:00
Chris Manghane
c7e1453e3d cmd/internal/gc: do not show computed value in type error
Fixes #9076.

Change-Id: Ib41a452fa9aa9fecf19f65c36d13715923548041
Reviewed-on: https://go-review.googlesource.com/1250
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Chris Manghane <cmang@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2015-02-25 19:49:49 +00:00
Chris Manghane
b59dd94f33 cmd/internal/gc: method selector should not auto-deref named pointer type
Fixes #9017.

Change-Id: I26cb1e7d6e137ff145773169cfe2d8bd4e1b339c
Reviewed-on: https://go-review.googlesource.com/1252
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Chris Manghane <cmang@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2015-02-25 19:27:30 +00:00
Russ Cox
5b94a47b7f [dev.cc] test: disable syntax error tests
These don't work with the new compiler, because the
new compiler doesn't have the custom syntax errors
that I built for the old compiler. It will, just not yet.
(Issue #9968.)

Change-Id: I658f7dab2c7f855340a501f9ae4479c097b28cd3
Reviewed-on: https://go-review.googlesource.com/5632
Reviewed-by: Rob Pike <r@golang.org>
2015-02-23 19:56:11 +00:00
Ian Lance Taylor
5aa448ff8c test: add test case for issue 4365
This is an update of http://golang.org/cl/151410043 by Tim Shen.

Change-Id: I43ab7fcedd785059c535f45a3c8cdb7b618c1499
Reviewed-on: https://go-review.googlesource.com/4873
Reviewed-by: David Crawshaw <crawshaw@golang.org>
2015-02-14 16:02:10 +00:00