Comment 1:

Well, that's what you ask for...
This happens only if you build it manually from source, right? Users of prepackaged
distributions must always have normal tools.
Any suggestions?

Labels changed: added racedetector.

Comment 2:

You are right. If $GOROOT/pkg/linux_amd64_race exists, go install -race std doesn't
overwrite $GOROOT/bin/gofmt, so users of the binary distribution aren't affected. If it
doesn't, gofmt is replaced by a race-enabled one.
Other than hacking on the go tool, maybe do this:
There was an issue somewhere to add a function to runtime to tell if the race detector
is on. If that exists yet, maybe gofmt can just print a warning to stderr:
"gofmt is built with the race detector enabled and will be slow".
Alternatively, you could add a +build race file to do this.

Comment 3:

I don't know.
It's possible to add the warning to the tools (and cmd/go is even slower and used much
more often than fmt). But I know that they are slow due to race detector. Now you also
know :)
Are other people concerned with this?

Comment 4:

I had a play and `go install -race -a std` replaces all the binaries, including
$GOROOT/bin/go with a race enabled version.

Labels changed: added release-go1.3, repo-main.

Status changed to Accepted.

Comment 5:

Dave, is it good or bad?
At least that's what you ask for. If you do 'go install -gcflags=-l -a std' you will get
the same, right?

Comment 6:

Good point. @fullung are you happy with this answer ?

Status changed to WaitingForReply.

Comment 7:

I tend to think this is working as intended.

Comment 8:

I guess when people google for "slow gofmt" at least they're going to find this issue
now.

Comment 9:

Does misc/dist install the 'slow' gofmt by accident ?

Comment 10:

after running make.bash, go install -race std overwrites an existing fast gofmt with a
slow race-enabled one. I mainly do this because of an old habit caused by issue #5048,
but other people might also run this for other reasons.
Once you've done this, you have a slow gofmt and it's hard to figure out why if you only
notice it for the first time a few hours after fiddling with the race detector.

Comment 11:

Re #9, no. misc/dist takes care of this problem by reinstalling all the commands.
I don't think we can change the behavior for "go install -race std" now, however,
we might consider add a new stdlib selector for standard packages (but not commands).
However, I'm not sure about name conflicts that might cause.

Comment 12:

The only people who actually want to run these tools with race detection enabled are Go
core developers. It does kinda suck that building the race toolchain also builds the
tools.
I like fullung's proposed solution in #2. It's just the go tool and gofmt that need to
print the warning. Doesn't seem like a big deal to me, provided that the proposed
runtime.RaceEnabled const/function is acceptable.

Comment 13:

I'd rather the go command and gofmt not whine about race mode. What if you were really
trying to detect races?
This is working as intended: you asked for everything to be installed with race
detection, and it was.

Status changed to WorkingAsIntended.