On Sat, 30 Aug 2025 at 06:14, Bo YU <[email protected]> wrote:
> I proposed the workaround to skip tsan tests on riscv64 explicitly in
> case block something. Certainly, I am thinking that how to report this
> to upstream.
Thanks for the patch! It's got a minor typo ("flasky" instead of
"flaky") which I was just going to fix and apply, but I've got some
further questions after looking deeper at the details/patch. 🙇
I also don't think it's accurate to call these tests "flaky" - they're
not passing sometimes, they literally fail all the time, so if
skipping them is the correct fix here we should come up with some
better wording for the error (and filename for the patch).
Am I correct in my understanding that this is actually a GCC bug?
When you say "report this to upstream", do you mean to GCC upstream?
Are the (Debian) GCC maintainers aware of the issue already too?
Looking at your patch headers, you mention the race detector, but I
don't think this is related to the race detector, right? As noted,
the race detector isn't supported on riscv64, so upstream's tests
wouldn't be testing it. I guess I'm a little concerned that maybe
this is going to leak beyond just the tests of Go itself, but I admit
I'm not familiar with TSAN at all or how/why it's used in Go.
In your skipping patches, you've imported "runtime", but both
functions you're adding it to already have a "goarch" variable that
they appear to be using in the same way as you've used
"runtime.GOARCH" - is there a particular reason you didn't just use
them? I'm guessing upstream had a good reason for not importing
"runtime" there.
My last question is how this relates to #1114841 ? Is it just a
coincidence that they're both riscv64 and gcc-15 related and they're
otherwise totally disparate issues?
♥,
- Tianon
4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
