Yeah, we can probably disable caching for all such debug/printing flags. Want to make a list of them all?

I'm not sure if disabling the cache for the build or caching the output is the correct way to go forward.

I'll collect these in the issue and ping after it's done (should be this weeked).

Considering how rarely these are used, and how they're only used for debugging or developing the Go compilers themselves, disabling the build cache seems simplest and safest.

Considering how rarely these are used, and how they're only used for debugging or developing the Go compilers themselves

Neither of these statements are true. People use -S and -m for performance analysis of their own code.

I mean they're only used for
a) debugging
b) developing the Go compilers themselves
sure, we can add
c) performance analysis of your own code

My point remains: they're rarely used.

We can afford to give up the caching here.

Another workaround is using go tool compile -S, that will always print the asm. It's also 2 characters shorter than go build -gcflags -S, so you save time : )

@gopherbot please open a backport tracking issue, as this is a 1.10 regression.

Backport issue(s) opened: #25045 (for 1.10).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

No flag whitelist needed. This is a variant of #22587. https://golang.org/cl/77110 should have fixed this but somehow did not.

/cc @bcmills want to take a look?

I'll look into it when I get a chance. Is this possibly a difference of stderr vs. stdout?

In my testing the -S output is repeated as expected when building a non-main package. It is not repeated when building a main package if the executable already exists.

@dlsniper Were you building a main package?

Change https://golang.org/cl/128903 mentions this issue: cmd/go: display cached compiler output more often