This seems to have come from this gcc test:

/* The FR-V port used to fail this test because the andcc patterns
   wrongly claimed to set the C and V flags.  */
#include <limits.h>
int x[4] = { INT_MIN / 2, INT_MAX, 2, 4 };
int
main ()
{
  if (x[0] < x[1])
    if ((x[2] & x[3]) < 0)
      abort ();
  exit (0);
}

@FiloSottile suggested that a recent mailing list post be moved to an issue, so here goes:

Jan Mercl reports that this code will miscompile on ARM:

package main

import "fmt"

var x = [4]int32{((-0x7fffffff - 1) / 2), 0x7fffffff, 2, 4} /* 20041210-1.c:5:5 */

func main() { /* 20041210-1.c:8:1: */
        if x[0] < x[1] {
                if x[2]&x[3] < 0 {
                        panic(fmt.Errorf("%v & %v = %v, < 0 ? %v", x[2], x[3], x[2]&x[3], x[2]&x[3] < 0))
                }
        }
}

Running the same code on 386 vs arm shows success on 386 and panics on arm. I've confirmed this is the case with 1.15.5, and Meng Zhuo confirmed it to be happening on 1.13, so it is at least a somewhat oldish bug.

The current issue title is vague because I haven't looked into what's actually happening yet. And I haven't yet assessed the security implications, either, but one can start imagining worrisome corner cases.

CC @rsc @cherrymui @ianlancetaylor @aclements

Change https://golang.org/cl/273892 mentions this issue: libgo: define SO_RCVTIMEO on 32-bit GNU/Linux

@kevinburkeshyp we don't monitor closed issues, if that's still a problem, please open a new issue.

Originally posted by @FiloSottile in https://github.com/golang/go/issues/19900#issuecomment-385464876

@kevinburkeshyp we don't monitor closed issues, if that's still a problem, please open a new issue.

Originally posted by @FiloSottile in https://github.com/golang/go/issues/19900#issuecomment-385464876

Message from Go Bot:

Patch Set 1: TryBot-Result+1

TryBots are happy.

Please don’t reply on this GitHub thread. Visit golang.org/cl/273946. After addressing review feedback, remember to publish your drafts!

Profile the program you care about (not a benchmark a real program) and see how much pprof reports is spend in round2.

Message from Jason A. Donenfeld:

Patch Set 6: Code-Review+2

Please don’t reply on this GitHub thread. Visit golang.org/cl/273446. After addressing review feedback, remember to publish your drafts!

Message from Go Bot:

Patch Set 1:

TryBots beginning. Status page: https://farmer.golang.org/try?commit=6cba0861

Please don’t reply on this GitHub thread. Visit golang.org/cl/273946. After addressing review feedback, remember to publish your drafts!

A function with no body is valid Go. It is expected to be provided by assembler code or C code or via go:linkname or via some other mechanism. See https://golang.org/ref/spec#Function_declarations .

I haven't looked at this and I'm not sure where it is going wrong, but it would not be correct to modify the parser to reject functions with no bodies.

Message from Ian Lance Taylor:

Patch Set 1: Run-TryBot+1

Please don’t reply on this GitHub thread. Visit golang.org/cl/273946. After addressing review feedback, remember to publish your drafts!

Message from Go Bot:

Patch Set 6: TryBot-Result+1

TryBots are happy.

Please don’t reply on this GitHub thread. Visit golang.org/cl/273446. After addressing review feedback, remember to publish your drafts!

Message from Jason A. Donenfeld:

Patch Set 6: Run-TryBot+1

Please don’t reply on this GitHub thread. Visit golang.org/cl/273446. After addressing review feedback, remember to publish your drafts!

I looked into this a bit. parser.ParseFile and friends do not generate an error for the function with no body but the compiler does. This results in tools like go test and gopls to panic in this way. Would it be appropriate to try to add this as an error condition to the parser or should I just patch src/go/doc/example.go ?

Message from Jason A. Donenfeld:

Patch Set 6: -Run-TryBot

(1 comment)

Please don’t reply on this GitHub thread. Visit golang.org/cl/273446. After addressing review feedback, remember to publish your drafts!

Change https://golang.org/cl/273946 mentions this issue: all: update references to symbols moved from io/ioutil to io

This PR (HEAD: 0eb1e066c09ed871bf849466e8b5445b6605d6b4) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/273946 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off) See the Wiki page for more info

Update references missed in CL 263142.

For #41190

Hi! I'd like to give this a try. Could I send a patch for this?

Would it be ok to show an output like this (just like godoc)?

type Path struct {
        // contains filtered or unexported fields
}
A Path is series of selectors to query a CUE value

I agree that the tutorial should work as it is and you shouldn't need to mkdir -p example.com/greetings. My guess is that you missed some of the steps, or did something wrong. Suggestion: try to re-do the tutorial from scratch. If you still get that error, post your directory structure like @task4233 did above, and the content of all the files; and we may be able to understand what went wrong.

gopls server log after uninstall tdm-gcc

gopls-server-uninstall-tdm-gcc.txt

Message from Go Bot:

Patch Set 6: TryBot-Result-1

1 of 14 TryBots failed: Failed on linux-386: https://storage.googleapis.com/go-build-log/4ce0a7ce/linux-386_15f9733a.log

Consult https://build.golang.org/ to see whether they are new failures. Keep in mind that TryBots currently test exactly your git commit, without rebasing. If your commit's git parent is old, the failure might've already been fixed.

Please don’t reply on this GitHub thread. Visit golang.org/cl/273446. After addressing review feedback, remember to publish your drafts!

Message from Go Bot:

Patch Set 6:

Build is still in progress... This change failed on linux-386: See https://storage.googleapis.com/go-build-log/4ce0a7ce/linux-386_15f9733a.log

Other builds still in progress; subsequent failure notices suppressed until final report. Consult https://build.golang.org/ to see whether they are new failures. Keep in mind that TryBots currently test exactly your git commit, without rebasing. If your commit's git parent is old, the failure might've already been fixed.

Please don’t reply on this GitHub thread. Visit golang.org/cl/273446. After addressing review feedback, remember to publish your drafts!

Message from Go Bot:

Patch Set 6:

TryBots beginning. Status page: https://farmer.golang.org/try?commit=effcdaab

Please don’t reply on this GitHub thread. Visit golang.org/cl/273446. After addressing review feedback, remember to publish your drafts!

Message from Jason A. Donenfeld:

Patch Set 6: Run-TryBot+1

Please don’t reply on this GitHub thread. Visit golang.org/cl/273446. After addressing review feedback, remember to publish your drafts!

find some error that couldn't run 'go': fork/exec C:\Program Files\Go\bin\go.exe: The filename or extension is too long. in the go.mod, and find like issue https://github.com/therecipe/qt/issues/657 search by google . so uninstall the tdm-gcc, it work is ok

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go version go1.15.5 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="on" GOARCH="amd64" GOBIN="" GOCACHE="/home/username/.cache/go-build" GOENV="/home/username/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/username/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/username/go" GOPRIVATE="" GOPROXY="https://goproxy.io,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/username/workspace/projects/http2socks5/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build039276181=/tmp/go-build -gno-record-gcc-switches"

</pre></details> Besides, I use the vscode remote-ssh extension.

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. --> I just import a package golang.org/x/net/proxy.

What did you expect to see?

The program runs properly without any notifcation.

What did you see instead?

The program is running properly. However, the extension go nightly tells me that the complier noticed that I have a package loading error. It does not influence the program's performence, but the notifcation is kind of annoying.

Message from Boshi Lian:

Patch Set 6:

(1 comment)

Please don’t reply on this GitHub thread. Visit golang.org/cl/273446. After addressing review feedback, remember to publish your drafts!

Message from Boshi Lian:

Patch Set 5:

(4 comments)

Please don’t reply on this GitHub thread. Visit golang.org/cl/273446. After addressing review feedback, remember to publish your drafts!