Change-Id: Iea08b8f4e74a8cd4b4d317273046457c8db956a1
Reviewed-on: https://go-review.googlesource.com/1640Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

This was a copy-paste error from 9l.  Besides incorrectly referring to
cnames9, 6l doesn't even use a->class, so simply remove this.

Fixes #9320

Change-Id: I0e3440c9dae1c3408eb795b3645f9f1dd8f50aed
Reviewed-on: https://go-review.googlesource.com/1516Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #9418

Change-Id: I044fa1d26d972f012f00388a84c4d0f143cf4f63
Reviewed-on: https://go-review.googlesource.com/1970Reviewed-by: Robert Griesemer <gri@golang.org>

Change-Id: I04d2e83f86f021464190f0b0fe0e450cb4662ad9
Reviewed-on: https://go-review.googlesource.com/1971Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Some applications use unpadded base64 format, omitting the trailing
'=' padding characters from the standard base64 format, either to
minimize size or (more justifiably) to avoid use of the '=' character.
Unpadded flavors are standard and documented in section 3.2 of RFC 4648.

To support these unpadded flavors, this change adds two predefined
encoding variables, RawStdEncoding and RawURLEncoding, for unpadded
encodings using the standard and URL character set, respectively.
The change also adds a function WithPadding() to customize the padding
character or disable padding in a custom Encoding.

Finally, I noticed that the existing base64 test-suite was only
exercising the StdEncoding, and not referencing URLEncoding at all.
This change adds test-suite functionality to exercise all four encodings
(the two existing ones and the two new unpadded flavors),
although it still doesn't run *every* test on all four encodings.

Naming: I used the "Raw" prefix because it's more concise than "Unpadded"
and seemed just as expressive, but I have no strong preferences here.
Another short alternative prefix would be "Min" ("minimal" encoding).

Change-Id: Ic0423e02589b39a6b2bb7d0763bd073fd244f469
Reviewed-on: https://go-review.googlesource.com/1511Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Couldn't handle a hex string terminated by anything
other than spaces. Easy to fix.

Fixes #9124.

Change-Id: I18f89a0bd99a105c9110e1ede641873bf9daf3af
Reviewed-on: https://go-review.googlesource.com/1538Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #9188

Change-Id: Ifbf5d9fa78a4f4ceb7f92d42494fe37fa7878c45
Reviewed-on: https://go-review.googlesource.com/1930Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Check for Set error when a boolean flag isn't explicitly given a value.

Fixes #9345

Change-Id: I97a1289f8cf27567d1a726ebe5ef167c800f357c
Reviewed-on: https://go-review.googlesource.com/1897Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

benchmark           old MB/s     new MB/s     speedup
BenchmarkEncode     243.20       279.89       1.15x

benchmark           old allocs     new allocs     delta
BenchmarkEncode     1370           4              -99.71%

Change-Id: I3920bcc04b6dd89efa5da89db5594d4434426d74
Reviewed-on: https://go-review.googlesource.com/1924Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Make golint a bit happier

Change-Id: I8a14342f3e492e92bf5efa611f9ef91176624031
Reviewed-on: https://go-review.googlesource.com/1891Reviewed-by: Minux Ma <minux@golang.org>

Given a file of size N, a request for "Range: bytes=N-*" should
return a 416 [1].  Currently, it returns a 206 and a body of 0
bytes, with the illegal Content-Range of "bytes N-(N-1)/N" [2].

[1]: RFC 7233, sec 2.1: "If a valid byte-range-set includes at least one
byte-range-spec with a first-byte-pos that is less than the current
length of the representation, [...]".  sec 3.1: "If all of the
preconditions are true, the server supports the Range header field for
the target resource, and the specified range(s) are invalid or
unsatisfiable, the server SHOULD send a 416 (Range Not Satisfiable)
response."

[2]: RFC 7233, sec 4.2: "A Content-Range field value is invalid if it
contains a byte-range-resp that has a last-byte-pos value less than its
first-byte-pos value, [...]"

Fixes #8988

Change-Id: If3e1134e7815f5d361efea01873b29aafe3de817
Reviewed-on: https://go-review.googlesource.com/1862Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

with uintptr, the check for < 0 will never succeed in mem_plan9.go's
sbrk() because the brk_ syscall returns -1 on failure. fixes the plan9/amd64 build.

this failed on plan9/amd64 because of the attempt to allocate 136GB in mallocinit(),
which failed. it was just by chance that on plan9/386 allocations never failed.

Change-Id: Ia3059cf5eb752e20d9e60c9619e591b80e8fb03c
Reviewed-on: https://go-review.googlesource.com/1590Reviewed-by: Anthony Martin <ality@pbrane.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>

Fixes #9177

Change-Id: I1c7e57f0f0a9b00fb3ddc7fa4844ac53ea6df46f
Reviewed-on: https://go-review.googlesource.com/1876Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Co-hacking with Dave Cheney.

Fixes #9405

Change-Id: I14fc3b6a47dcdb5e514e93d062b804bb24e89f47
Reviewed-on: https://go-review.googlesource.com/1875Reviewed-by: Dave Cheney <dave@cheney.net>

Gccgo can only get a backtrace for the currently running thread, which
means that it can only get a backtrace for goroutines currently running
Go code.  When a goroutine is running C code, gccgo has no way to stop
it and get the backtrace.  This test is all about getting a backtrace
of goroutines running C code, so it can't work for gccgo.

Change-Id: I2dff4403841fb544da7396562ab1193875fc14c3
Reviewed-on: https://go-review.googlesource.com/1904Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I6be5f610af5c56131a9d887569919372bab1d02c
Reviewed-on: https://go-review.googlesource.com/1903Reviewed-by: Minux Ma <minux@golang.org>

Instead of relying on the asm names declared in the gccgo version of
cgo_export.h, just emit a dummy symbol with the right asm name.  This
is enough to let the _cgo_main link succeed, which is all that matters
here.

Fixes #9294.

Change-Id: I803990705b6b226ed0adf17dc57b58a9f501b213
Reviewed-on: https://go-review.googlesource.com/1901Reviewed-by: Minux Ma <minux@golang.org>

This was brought to my attention because a user thought that because
the file was named "example.go" it served as an example of good coding
practice.  It's not an example, of course, but may as well use a more
idiomatic style anyhow.

Change-Id: I7aa720f603f09f7d597fb7536dbf46ef09144e28
Reviewed-on: https://go-review.googlesource.com/1902Reviewed-by: Minux Ma <minux@golang.org>

benchmark                   old ns/op      new ns/op      delta
BenchmarkStableInt1K        117212         116287         -0.79%
BenchmarkStableInt64K       9632002        9587872        -0.46%
BenchmarkStable1e4          40044309       39865644       -0.45%
BenchmarkStable1e2          126985         126456         -0.42%
BenchmarkStableString1K     389774         391052         +0.33%
BenchmarkStable1e6          8183202516     8157693442     -0.31%

Change-Id: I14e518ad49ecce3d1fc2b056e1acd5e5a2de8144
Reviewed-on: https://go-review.googlesource.com/1821Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Ib9699fc9c45f61e9d75e9d9ae69167f039a66dfc
Reviewed-on: https://go-review.googlesource.com/1890Reviewed-by: Minux Ma <minux@golang.org>

"x*41" computes the same value as "x*31 + x*7 + x*3" and (when
compiled by gc) requires just one multiply instruction instead of
three.

Alternatively, the expression could be written as "(x<<2+x)<<3 + x" to
use shifts instead of multiplies (which is how GCC optimizes "x*41").
But gc currently emits suboptimal instructions for this expression
anyway (e.g., separate SHL+ADD instructions rather than LEA on
386/amd64). Also, if such an optimization was worthwhile, it would
seem better to implement it as part of gc's strength reduction logic.

Change-Id: I7156b793229d723bbc9a52aa9ed6111291335277
Reviewed-on: https://go-review.googlesource.com/1830Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I0f9cf081cb280f0a805ee7f5178a5cbed0d4ad88
Reviewed-on: https://go-review.googlesource.com/1842Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

replacement for CL 180640043

Change-Id: I8ff36645cfcbbda338faf7b29cbfdb95c47d5ec4
Reviewed-on: https://go-review.googlesource.com/1765Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I64c8c247acd5d134b2f17ed7aab0a035d7710679
Reviewed-on: https://go-review.googlesource.com/1804Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: If367cc1e8c2d744569513bc71da6e6c454c74e9a
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/1802Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Change-Id: Ia6739c164575751a63cc0d4d41d1f6887fbbaee3
Reviewed-on: https://go-review.googlesource.com/1803Reviewed-by: Minux Ma <minux@golang.org>

Previously, liblink would silently truncate register offset constants
to 32 bits.  For example,

    MOVD $0x200000004(R2),R3

would assemble to

    addis   r31,r2,0
    addi    r3,r31,4

To fix this, limit C_LACON to 32 bit (signed) offsets and introduce a
new C_DACON operand type for larger register offsets.  We don't
implement this currently, but at least liblink will now give an error
if it encounters an address like this.

Change-Id: I8e87def8cc4cc5b75498b0fb543ac7666cf2964e
Reviewed-on: https://go-review.googlesource.com/1758Reviewed-by: Minux Ma <minux@golang.org>

On ppc64, there are three ELF ABI versions an ELF file can request.
Previously, we used 0, which means "unspecified".  On our test
machines, this meant to use the default (v1 for big endian and v2 for
little endian), but apparently some systems can pick the wrong ABI if
neither is requested.  Leaving this as 0 also confuses libbfd, which
confuses gdb, objdump, etc.

Fix these problems by specifying ABI v1 for big endian and v2 for
little endian.

Change-Id: I4d3d5478f37f11baab3681a07daff3da55802322
Reviewed-on: https://go-review.googlesource.com/1800Reviewed-by: Minux Ma <minux@golang.org>

When we do y = &x for global variables x and y, y gets initialized
at link time.  Do the same for y = &x.f if x is a struct and y=&x[5]
if x is an array.

fixes #9217
fixes #9355

Change-Id: Iea3c0ce2ce1b309e2b760e345608fd95460b5713
Reviewed-on: https://go-review.googlesource.com/1691Reviewed-by: Minux Ma <minux@golang.org>

Fixes #9374.

Change-Id: Ic53757eba98fc43bcd24e25e03876fef917b4da1
Reviewed-on: https://go-review.googlesource.com/1751Reviewed-by: David Crawshaw <crawshaw@golang.org>

Change-Id: I13a8aacd1b8243c992b539ab6bf7b5dff2a1393a
Reviewed-on: https://go-review.googlesource.com/1757Reviewed-by: Minux Ma <minux@golang.org>

SSLv3 (the old minimum) is still supported and can be enabled via the
tls.Config, but this change increases the default minimum version to TLS
1.0. This is now common practice in light of the POODLE[1] attack
against SSLv3's CBC padding format.

[1] https://www.imperialviolet.org/2014/10/14/poodle.html

Fixes #9364.

Change-Id: Ibae6666ee038ceee0cb18c339c393155928c6510
Reviewed-on: https://go-review.googlesource.com/1791Reviewed-by: Minux Ma <minux@golang.org>

Fix TLS_FALLBACK_SCSV check when comparing the client version to the
default max version. This enables the TLS_FALLBACK_SCSV check by default
in servers that do not explicitly set a max version in the tls config.

Change-Id: I5a51f9da6d71b79bc6c2ba45032be51d0f704b5e
Reviewed-on: https://go-review.googlesource.com/1776Reviewed-by: Adam Langley <agl@golang.org>

This test was added in CL 151000043.
It got lost in CL 144630044.

Change-Id: I318ab11be8e3e7489fc1395457c029c8bdb2aa41
Reviewed-on: https://go-review.googlesource.com/1773Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I513665626ec0866f32036c26207dc234c17acea1
Reviewed-on: https://go-review.googlesource.com/1540Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I7ef01a738b6ca49af1c148146d439c81b0a33b16
Reviewed-on: https://go-review.googlesource.com/1785Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fix style by removing unnecessary named result parameter.

Fix doc comment while here.

Change-Id: If8394e696ab37e00a95484d5137955aa06c59520
Reviewed-on: https://go-review.googlesource.com/1781Reviewed-by: Yasuhiro MATSUMOTO <mattn.jp@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

On ppc64, liblink rewrites MOVD's of >32-bit constants by putting the
constant in memory and rewriting the MOVD to load from that memory
address.  However, there were two bugs in the condition:

a) owing to an incorrect sign extension, it triggered for all negative
   constants, and

b) it could trigger for constant offsets from registers (addresses of
   the form $n(Rm) in assembly)

Together, these meant instructions of the form MOVD $-n(Rm), x were
compiled by putting -n in memory and rewriting the MOVD to load this
constant from memory (completely dropping Rm).

Change-Id: I1f6cc980efa3e3d6f164b46c985b2c3b55971cca
Reviewed-on: https://go-review.googlesource.com/1752Reviewed-by: Minux Ma <minux@golang.org>

People are probably not making this mistake anymore.

Fixes #9164

Change-Id: I86b440ed63d09b4ca676bba7034838860f1a5d8b
Reviewed-on: https://go-review.googlesource.com/1782Reviewed-by: Minux Ma <minux@golang.org>

warning: src/cmd/gc/bits.c:101 non-interruptable temporary

Change-Id: I74661fefab50455b912b8085d913fc45ba13c5c8
Reviewed-on: https://go-review.googlesource.com/1780Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>