Fri, Oct 20, 2023 at 12:43:56PM -0700, Linus Torvalds kirjoitti: > On Fri, 20 Oct 2023 at 11:29, Andy Shevchenko > <andriy.shevchenko@xxxxxxxxx> wrote: > > > > I'll reply to this with the attached object file, I assume it won't go to the > > mailing list, but should be available in your mailbox. > > Honestly, both cases (that function gets inlined twice) look > *identical* from a quick look, apart from obviously the extra call to > __quota_error(). > > I might be missing something, but this most definitely is not a "gcc > ends up creating very different code when it doesn't need to > synchronize around the call" thing. > > So a compiler issue looks very unlikely. No absolute guarantees - I > didn't do *that* kind of walk-through instruction by instruction - but > the results actually seem to line up perfectly. > > Even register allocation didn't change, making the compare between #if > 0 and without rather easy. > > There's one extra spill/reload due to the call in the "non-#if0" case, > and that actually made me look twice (because it spilled %eax, and > then reloaded it as %rcx), but it turns that %eax/%ecx had the same > value at the time of the spill, so even that was not a "real" > difference. > > So I will claim that no, it's not the compiler. It's some unrelated > subtle timing, or possibly just a random code layout issue (because > the code addresses do obviously change). Okay, but since now I can't use the certain configuration, the bug is persistent to me after this merge with the GCC. Yet, you mentioned that you would expect some reports but I don't think many people have a configuration similar to what I have. In any case a bug is lurking somewhere there. Let me check next week on different CPU (but I'm quite sceptical that it may anyhow trigger the same behaviour as if it's a timing, many parameters are involved, including hardware clocks, etc). That said, if you or anyone has ideas how to debug futher, I'm all ears! -- With Best Regards, Andy Shevchenko
