Catch some malformed pipelines at parsing time.
The current code accepts pipelines such as:
{{12|.}}
{{"hello"|print|false}}
{{.|"blah blah"}}
Such pipelines generate panic in html/template at execution time.
Add an extra check to verify all the commands of the pipeline are executable
(except for the first one).
Fixes#10610
Change-Id: Id72236ba8f76a59fa284fe3d4c2cb073e50b51f1
Reviewed-on: https://go-review.googlesource.com/9626
Reviewed-by: Rob Pike <r@golang.org>
This makes the intermediate object file a little bigger but it doesn't waste
any space in the final shared library.
Fixes#10691
Change-Id: Ic51a571d60291f1ac2dad1b50dba4679643168ae
Reviewed-on: https://go-review.googlesource.com/9710
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This changes the action graph when shared libraries are involved to always have
an action for the shared library (which does nothing when the shared library
is up to date).
Change-Id: Ibbc70fd01cbb3f4e8c0ef96e62a151002d446144
Reviewed-on: https://go-review.googlesource.com/8934
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes#10660
Fix the clang only builder by passing -extld down to the linker when needed.
The build passed on most hosts because gcc is almost always present. The bug
was verified by symlinking bin/false in place of gcc in my $PATH and running
the build.
Also, resolve a TODO and move the support logic into its own function.
Tested manually
env CC=clang-3.5 ./all.bash # linux/amd64
env CC=gcc-4.8 ./all.bash # linux/amd64
./all.bash # linux/amd64
./all.bash # darwin/amd64
Change-Id: I4e27a1119356e295500a0d19ad7a4ec14207bf10
Reviewed-on: https://go-review.googlesource.com/9526
Run-TryBot: Dave Cheney <dave@cheney.net>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I just submitted the real fix for #10641.
This reverts commit 3120adc212.
Change-Id: I55051515f697e27ca887ed21c2ac985f0b9b062b
Reviewed-on: https://go-review.googlesource.com/9720
Reviewed-by: Joel Sing <jsing@google.com>
No semantic change.
Fixes#8708.
Change-Id: Ieda04a86a19bb69bfc2519d381a2f025e7cb8279
Reviewed-on: https://go-review.googlesource.com/9740
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I forgot there is already a ptrSize constant.
Rename field to avoid some confusion.
Change-Id: I098fdcc8afc947d6c02c41c6e6de24624cc1c8ff
Reviewed-on: https://go-review.googlesource.com/9700
Reviewed-by: Austin Clements <austin@google.com>
The old one was inferior.
Fixes#10695.
Change-Id: Ia7fb88c9ceb1b10197b77a54f729865385288d98
Reviewed-on: https://go-review.googlesource.com/9709
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
When a parse error occurred, the lexing goroutine would lay idle.
It's not likely a problem but if the program is for some reason
accepting badly formed data repeatedly, it's wasteful.
The solution is easy: Just drain the input on error. We know this
will succeed because the input is always a string and is therefore
guaranteed finite.
With debugging prints in the package tests I've shown this is effective,
shutting down 79 goroutines that would otherwise linger, out of 123 total.
Fixes#10574.
Change-Id: I8aa536e327b219189a7e7f604a116fa562ae1c39
Reviewed-on: https://go-review.googlesource.com/9658
Reviewed-by: Russ Cox <rsc@golang.org>
Freezetheworld still has stuff to do when gomaxprocs=1.
In particular, signals can come in on other Ms (like the GC M, say)
and the single user M is still running.
Fixes#10546
Change-Id: I2f07f17d1c81e93cf905df2cb087112d436ca7e7
Reviewed-on: https://go-review.googlesource.com/9551
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
When emulating ARM FSQRT instruction, the sqrt function itself
should not use any floating point arithmetics, otherwise it will
clobber the user software FP registers.
Fortunately, the sqrt function only uses floating point instructions
to test for corner cases, so it's easy to make that function does
all it job using pure integer arithmetic only. I've verified that
after this change, runtime.stepflt and runtime.sqrt doesn't contain
any call to _sfloat. (Perhaps we should add //go:nosfloat to make
the compiler enforce this?)
Fixes#10641.
Change-Id: Ida4742c49000fae4fea4649f28afde630ce4c576
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/9570
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Keith Randall <khr@golang.org>
OSQRT currently produces incorrect results when used on arm with softfloat.
Disable it on GOARM=5 until the actual problem is found and fixed.
Updates #10641
Change-Id: Ia6f6879fbbb05cb24399c2feee93c1be21113e73
Reviewed-on: https://go-review.googlesource.com/9524
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Whenever we introduce a new GOARCH, older Go releases won't
recognize them and this causes trouble for both our users and
us (we need to add unnecessary build tags).
Go 1.5 has introduced three new GOARCHes so far: arm64 ppc64
ppc64le, we can take the time to introduce GOARCHes for all
common architectures that Go might support in the future to
avoid the problem.
Fixes#10165.
Change-Id: Ida4f9112897cfb1e85b06538db79125955ad0f4c
Reviewed-on: https://go-review.googlesource.com/9644
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Update #10652
This proposal deletes cmd/internal/ld.Biobuf and replaces all uses with
cmd/internal/obj.Biobuf. As cmd/internal/ld already imported cmd/internal/obj
there are no additional dependencies created.
Notes:
- ld.Boffset included more checks, so it was merged into obj.Boffset
- obj.Bflush was removed in 8d16253c90, so replaced all calls to
ld.Bflush, with obj.Biobuf.Flush.
- Almost all of this change was prepared with sed.
Change-Id: I814854d52f5729a5a40c523c8188e465246b88da
Reviewed-on: https://go-review.googlesource.com/9660
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Dave Cheney <dave@cheney.net>
Write should return ErrWriteAfterClose instead
of ErrWriteTooLong when called after Close.
Change-Id: If5ec4ef924e4c56489e0d426976f7e5fad79be9b
Reviewed-on: https://go-review.googlesource.com/9259
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This adds a field to the runtime type structure that records the size
of the prefix of objects of that type containing pointers. Any data
after this offset is scalar data.
This is necessary for shrinking the type bitmaps to 1 bit and will
help the garbage collector efficiently estimate the amount of heap
that needs to be scanned.
Change-Id: I1318d79e6360dca0ac980245016c562e61f52ff5
Reviewed-on: https://go-review.googlesource.com/9691
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Move the one instance of type structure decoding in the linker that
doesn't live decodesym.go in to decodesym.go.
Change-Id: Ic6a23500deb72f0e9c8227ab611511e9781fac70
Reviewed-on: https://go-review.googlesource.com/9690
Reviewed-by: Russ Cox <rsc@golang.org>
shouldtriggergc is slightly expensive due to the call overhead
and the use of an atomic. This CL reduces the number of time
one checks if a GC should be done from one at each allocation
to once when a span is allocated. Since shouldtriggergc is an
important abstraction simply hand inlining it, along with its
atomic instruction would lose the abstraction.
Change-Id: Ia3210655b4b3d433f77064a21ecb54e4d9d435f7
Reviewed-on: https://go-review.googlesource.com/9403
Reviewed-by: Austin Clements <austin@google.com>
At the end of lexInsideAction(), we return lexInsideAction: this is the default
behaviour when we are still parsing an action. But some switch branches return
lexInsideAction too.
So let's ensure code consistency by always reaching the end of the
lexInsideAction function when needed.
Change-Id: I7e9d8d6e51f29ecd6db6bdd63b36017845d95368
Reviewed-on: https://go-review.googlesource.com/9441
Reviewed-by: Rob Pike <r@golang.org>
We shouldn't sort the slots array, as it is used each time the
test is run. Tests after the first should continue to use the
unsorted ordering.
Note that this doesn't fix the flaky test. Just a bug I saw
while investigating.
Change-Id: Ic03cca637829d569d50d3a2278d19410d4dedba9
Reviewed-on: https://go-review.googlesource.com/9637
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
global color table.
Change-Id: Ia38f75708ed5e5b430680a1eecafb4fc8047269c
Reviewed-on: https://go-review.googlesource.com/9467
Reviewed-by: Rob Pike <r@golang.org>
The script was renamed in b3000b6.
Change-Id: I45ecafff7400e4bff14f31906278609abf2bcb9f
Reviewed-on: https://go-review.googlesource.com/9667
Reviewed-by: Andrew Gerrand <adg@golang.org>
Noopt builds get a larger stack guard. This test must take that into account.
Change-Id: I1b5cbafdbbfee8c369ae1bebd0b900524ebf0d7d
Reviewed-on: https://go-review.googlesource.com/9610
Reviewed-by: Russ Cox <rsc@golang.org>
Ideal constants in the template package are a little different from Go.
This is a case that slipped through the cracks: A huge integer number
was accepted as a floating-point number, but this loses precision
and is confusing. Also, the code in the template package (as opposed
to the parse package) wasn't expecting it.
Root this out at the source: If an integer doesn't fit an int64 or uint64,
complain right away.
Change-Id: I375621e6f5333c4d53f053a3c84a9af051711b7a
Reviewed-on: https://go-review.googlesource.com/9651
Reviewed-by: Russ Cox <rsc@golang.org>
The siz argument to both runtime.newproc and runtime.deferproc is
int32, not uintptr. This problem won't manifest on little-endian
systems because that stack slot is uintptr sized anyway. However,
on big-endian systems, it will make a difference.
Change-Id: I2351d1ec81839abe25375cff95e327b80764c2b5
Reviewed-on: https://go-review.googlesource.com/9647
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The current parser ignores obvious errors such as:
{{0.1.E}}
{{true.any}}
{{"hello".wrong}}
{{nil.E}}
The common problem is that a chain is built from
a literal value. It then panics at execution time.
Furthermore, a double dot triggers the same behavior:
{{..E}}
Addresses a TODO left in Tree.operand to catch these
errors at parsing time.
Note that identifiers can include a '.', and pipelines
could return an object which a field can be derived
from (like a variable), so they are excluded from the check.
Fixes#10615
Change-Id: I903706d1c17861b5a8354632c291e73c9c0bc4e1
Reviewed-on: https://go-review.googlesource.com/9621
Reviewed-by: Rob Pike <r@golang.org>
There are three problems:
1. There is no CR at the end of the message.
2. The message is unconditionally printed.
3. The message is printed to stdout.
Change-Id: Ib2d880eea03348e8a69720aad7752302a75bd277
Reviewed-on: https://go-review.googlesource.com/9622
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change applies CL 9365 to the copy of Biobuf in cmd/internal/obj.
In the process I discovered that some of the methods that should have been
checking the unget buffer before reading were not and it was probably just
dumb luck that we handn't hit these issues before; Bungetc is only used in
one place in cmd/internal/gc and only an unlikely code path.
Change-Id: Ifa0c5c08442e9fe951a5078c6e9ec77a8a4dc2ff
Reviewed-on: https://go-review.googlesource.com/9529
Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Dave Cheney <dave@cheney.net>
The test was measuring something, assuming other goroutines had
already scheduled.
Fixes#10427
Change-Id: I2a4d3906f9d4b5ea44b57d972e303bbe2b0b1cde
Reviewed-on: https://go-review.googlesource.com/9561
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
An unmatched {{else}} should trigger a parsing error.
The top level parser is able to issue an error in case
of unmatched {{end}}. It does it a posteriori (i.e. after having
parsed the action).
Extend this behavior to also check for unmatched {{else}}
Fixes#10611
Change-Id: I1d4f433cc64e11bea5f4d61419ccc707ac01bb1d
Reviewed-on: https://go-review.googlesource.com/9620
Reviewed-by: Rob Pike <r@golang.org>
The usage messages for the flags in gc and ld are using the old
flag argument syntax:
"arg: description using arg"
Update them to the Go 1.5 flag package's syntax:
"description using arg"
Fixes#10505
Change-Id: Ifa54ff91e1fd644cfc9a3b41e10176eac3654137
Reviewed-on: https://go-review.googlesource.com/9505
Reviewed-by: Rob Pike <r@golang.org>
This adds a detailed debug dump of the state of the GC controller and
a GODEBUG flag to enable it.
Change-Id: I562fed7981691a84ddf0f9e6fcd9f089f497ac13
Reviewed-on: https://go-review.googlesource.com/9640
Reviewed-by: Russ Cox <rsc@golang.org>
(1) Count pointer-free objects found during scanning roots
as marked bytes, by not zeroing the mark total after scanning roots.
(2) Don't count the bytes for the roots themselves, by not adding
them to the mark total in scanblock (the zeroing removed by (1)
was aimed at that add but hitting more).
Combined, (1) and (2) fix the calculation of the marked heap size.
This makes the GC trigger much less often in the Go 1 benchmarks,
which have a global []byte pointing at 256 MB of data.
That 256 MB allocation was not being included in the heap size
in the current code, but was included in Go 1.4.
This is the source of much of the relative slowdown in that directory.
(3) Count the bytes for the roots as scanned work, by not zeroing
the scan total after scanning roots. There is no strict justification
for this, and it probably doesn't matter much either way,
but it was always combined with another buggy zeroing
(removed in (1)), so guilty by association.
Austin noticed this.
name old mean new mean delta
BenchmarkBinaryTree17 13.1s × (0.97,1.03) 5.9s × (0.97,1.05) -55.19% (p=0.000)
BenchmarkFannkuch11 4.35s × (0.99,1.01) 4.37s × (1.00,1.01) +0.47% (p=0.032)
BenchmarkFmtFprintfEmpty 84.6ns × (0.95,1.14) 85.7ns × (0.94,1.05) ~ (p=0.521)
BenchmarkFmtFprintfString 320ns × (0.95,1.06) 283ns × (0.99,1.02) -11.48% (p=0.000)
BenchmarkFmtFprintfInt 311ns × (0.98,1.03) 288ns × (0.99,1.02) -7.26% (p=0.000)
BenchmarkFmtFprintfIntInt 554ns × (0.96,1.05) 478ns × (0.99,1.02) -13.70% (p=0.000)
BenchmarkFmtFprintfPrefixedInt 434ns × (0.96,1.06) 393ns × (0.98,1.04) -9.60% (p=0.000)
BenchmarkFmtFprintfFloat 620ns × (0.99,1.03) 584ns × (0.99,1.01) -5.73% (p=0.000)
BenchmarkFmtManyArgs 2.19µs × (0.98,1.03) 1.94µs × (0.99,1.01) -11.62% (p=0.000)
BenchmarkGobDecode 21.2ms × (0.97,1.06) 15.2ms × (0.99,1.01) -28.17% (p=0.000)
BenchmarkGobEncode 18.1ms × (0.94,1.06) 11.8ms × (0.99,1.01) -35.00% (p=0.000)
BenchmarkGzip 650ms × (0.98,1.01) 649ms × (0.99,1.02) ~ (p=0.802)
BenchmarkGunzip 143ms × (1.00,1.01) 143ms × (1.00,1.01) ~ (p=0.438)
BenchmarkHTTPClientServer 110µs × (0.98,1.04) 101µs × (0.98,1.02) -8.79% (p=0.000)
BenchmarkJSONEncode 40.3ms × (0.97,1.03) 31.8ms × (0.98,1.03) -20.92% (p=0.000)
BenchmarkJSONDecode 119ms × (0.97,1.02) 108ms × (0.99,1.02) -9.15% (p=0.000)
BenchmarkMandelbrot200 6.03ms × (1.00,1.01) 6.03ms × (0.99,1.01) ~ (p=0.750)
BenchmarkGoParse 8.58ms × (0.89,1.10) 6.80ms × (1.00,1.00) -20.71% (p=0.000)
BenchmarkRegexpMatchEasy0_32 162ns × (1.00,1.01) 162ns × (0.99,1.02) ~ (p=0.131)
BenchmarkRegexpMatchEasy0_1K 540ns × (0.99,1.02) 559ns × (0.99,1.02) +3.58% (p=0.000)
BenchmarkRegexpMatchEasy1_32 139ns × (0.98,1.04) 139ns × (1.00,1.00) ~ (p=0.466)
BenchmarkRegexpMatchEasy1_1K 889ns × (0.99,1.01) 885ns × (0.99,1.01) -0.50% (p=0.022)
BenchmarkRegexpMatchMedium_32 252ns × (0.99,1.02) 252ns × (0.99,1.01) ~ (p=0.469)
BenchmarkRegexpMatchMedium_1K 72.9µs × (0.99,1.01) 73.6µs × (0.99,1.03) ~ (p=0.168)
BenchmarkRegexpMatchHard_32 3.87µs × (1.00,1.01) 3.86µs × (1.00,1.00) ~ (p=0.055)
BenchmarkRegexpMatchHard_1K 118µs × (0.99,1.01) 117µs × (0.99,1.00) ~ (p=0.133)
BenchmarkRevcomp 995ms × (0.94,1.10) 949ms × (0.99,1.01) -4.64% (p=0.000)
BenchmarkTemplate 141ms × (0.97,1.02) 127ms × (0.99,1.01) -10.00% (p=0.000)
BenchmarkTimeParse 641ns × (0.99,1.01) 623ns × (0.99,1.01) -2.79% (p=0.000)
BenchmarkTimeFormat 729ns × (0.98,1.03) 679ns × (0.99,1.00) -6.93% (p=0.000)
Change-Id: I839bd7356630d18377989a0748763414e15ed057
Reviewed-on: https://go-review.googlesource.com/9602
Reviewed-by: Austin Clements <austin@google.com>
