Hi, On Fri, Sep 19, 2025 at 1:09 PM Tianon Gravi <[email protected]> wrote: > > 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. 🙇 >
Thanks for your reviewing. :) > 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). > Yeah, You are right, in fact I have a misunderstanding about flaky and skip in some content. For here, we did to *skip* the test cases on riscv64, it is not flaky. > 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? > Here, I was trying to find what happened here. Unfortunately, I have not been able to reproduce the issue with a minimal test case yet. The failure was due to the GCC-15 update, but it is also possible that there are some problems with goaling's Tsan detection mechanism(let me call it here) on riscv64. So, before reporting it to the GCC Debian maintainer or upstream, I hope to get confirmation first from the Golang side, like[0] [0]: https://github.com/golang/go/issues/64345#issuecomment-3240634521 > 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. > Yeah, my understanding is that the race detector currently doesn't support riscv64. Previously the gcc-14 would automatically detect the lack of support and skip it, but gcc-15 broke this rule. So I mentioned it there. > 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. Thanks for the pointer, It works. :) > > 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? Both are coincidental, I have to apply these two patches to test the patch. For #1114841, it has blocked many go packages which was rebuilt recently, but golang-1.25[1] has fixed the issue, golang-1.24 has backported the commit from upstream[2]. So, golang-1.25/25 will have tsan test failed with gcc-15 on riscv64, and I think it is not perfect to skip it. But it will take some time to find the root cause. [1]: https://tracker.debian.org/pkg/golang-1.25 [2]: https://github.com/golang/go/issues/75351 BR, Bo > > ♥, > - Tianon > 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
1112166_v2.debdiff
Description: Binary data
