This issue is currently labeled as early-in-cycle for Go 1.19.
That time is now, so a friendly reminder to look at it again.

I see README now lists different llvm revisions for different arches.
Should we merge https://go-review.googlesource.com/c/go/+/333529 for amd64 only? Or update more arches at once? Keith, as far as I remember, you mentioned that you can re-build runtime for more arches.

Are we still early-in-cycle? For how long?

I don't think we are early in cycle anymore, but 1.19 is also a release with a unique timeline given how late its tree reopened. I think this is currently blocked on reviews or approvals, and I really hope it will get merged for the upcoming release :) I am more than happy to test the new race detector on all my projects, as I use -race fairly often and I daily drive Go master.

Then the question: do I submit cl/333529 now?
The sooner we start testing, the better. And amd64 is the most widely used arch I think.

@dvyukov Go ahead and submit the CL when you are ready. Thanks.

The linux/amd64 version is submitted, the builder said ok.

I believe this is ~done. @dvyukov did linux/amd64 (CL 333529), me for the new s390x support (CL 401714), @cherrymui all of the others (CL 397494, 397676). Thanks everyone!

@cherrymui My understanding is windows/amd64 has not been updated - waiting for C toolchain issues, is that still true?

openbsd/amd64 will not be updated, as openbsd is no longer supported by the latest tsan.

Yes, I haven't done windows/amd64. Last time I tried it ended with a build failure with the old GCC on the builder. I think @thanm is updating the C toolchain. As long as that is done, I'll try to build the new syso.

Alex and I are meeting tomorrow to work on the new builder image, so hopefully the new compilers will be available shortly after that. Fingers crossed.

Ok, I'll leave this issue open for now. Cherry, feel free to mark the future CL for windows/amd64 as fixing this issue.

Any word on the C toolchain issue?

Still working on the toolchain.

The latest wrinkle is that when I generate a new base Windows builder
using a more up-to-date GCP image (e.g. something like
windows-server-2012-r2-dc-v20220513 instead of what we were using
before (windows-server-2016-dc-core-v20171010), I get cgo test
failures (e.g. something in the new image is tickling a problem in the
linker). I'll need to debug that before I can move forward.

Update: my LLVM change to support V3 (https://reviews.llvm.org/D128909) has been submitted. This change can be used to build a working race_windows_amd64.syso file that works with Go tip. To test this change on your windows machine (assuming you are building Go from source) use

git fetch https://go.googlesource.com/go refs/changes/97/420197/2 && git checkout FETCH_HEAD

We have a logistics problem in that the new windows V3 runtime isn't buildable with the existing GCC compilers installed on the windows builders (they are an ancient version of GCC 5.1). We have new VM images (the windows-*newcc variants in the build pool) that have updated compilers, but we can't switch over to them by default, since we use those builders for testing minor releases, and the older releases can't grok the host objects from the newer compilers. I will be working with the release team to work out a solution this.

Maybe the gcc support on Windows is now available? In any case, bumping to 1.21.

The GCC support is in. CL 420197 updates the race syso, which targets Go 1.21. So, yeah, 1.21 milestone.

Change https://go.dev/cl/420197 mentions this issue: runtime/race: update race_windows_amd64.syso