Do you want to build the toolchain (the compiler, linker, assembler) in msan/asan mode, or the standard library? They are two separate things. It's unclear from your message what you want.

For the former (the toolchain), there may not be much value for it. Those sanitizers are mostly for catching errors for mixed C/Go programs. And the toolchains are pure-Go programs.

For the latter, there may be some value. Not for catching bugs in the standard library, but to make sure the instrumentation is consistent and won't fail when user importing those packages.

The goal here is to run the tests with -msan or -asan. I agree that the purpose of this would be to catch cases where we aren't correctly instrumenting Go code, or where assembler code in the standard library isn't correctly recording its memory writes. This seems like a reasonable thing to do though it doesn't seem high priority.

For example, it's a good point that go test -msan reflect fails today:

Uninitialized bytes in __msan_check_mem_is_initialized at offset 0 inside [0x00c00000e5d0, 8)
==1261422==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x505b68  (/tmp/go-build2132864169/b001/reflect.test+0x505b68)

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/tmp/go-build2132864169/b001/reflect.test+0x505b68) 
Exiting
FAIL	reflect	1.917s
FAIL

It fails because it thinks that the memory accessed by the compiler-constructed method reflect_test.(*Outer).M does what appears to be a read of uninitialized memory. I'm confident that the problem is actually that nothing told msan that the memory was initialized, but that does still seem like a bug worth fixing.

Do you want to build the toolchain (the compiler, linker, assembler) in msan/asan mode, or the standard library? They are two separate things. It's unclear from your message what you want.

For the former (the toolchain), there may not be much value for it. Those sanitizers are mostly for catching errors for mixed C/Go programs. And the toolchains are pure-Go programs.

For the latter, there may be some value. Not for catching bugs in the standard library, but to make sure the instrumentation is consistent and won't fail when user importing those packages.

I mean the latter one. Thanks for clearing things up. :)

Change https://golang.org/cl/375254 mentions this issue: src: add sanitizer.bash

Change https://golang.org/cl/374496 mentions this issue: dashboard: add msan/asan builder