https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126661
--- Comment #4 from wedge009 at wedge009 dot net --- The LLM concedes you're right about the central claim in its report. On a second verification: files with their own "static aud::mutex mutex;": 14 (adder.cc, art.cc, cue-cache.cc, effect.cc, equalizer.cc, eventqueue.cc, hook.cc, playback.cc, playlist-cache.cc, playlist.cc, plugin-registry.cc, timer.cc, vfs_async.cc, vis-runner.cc) files with their own "static aud::condvar cond;": 2 (cue-cache.cc, playback.cc) That's an exact match for the "13 mutex / 2 cond" counts in both the original report and our GCC-16.1.1 rebuild. Every one of those is a genuinely separate, unrelated object — art.cc's mutex guards art-cache state, cue-cache.cc's guards cue-cache state, playback.cc's guards playback state — they just happen to share the same short, conventional variable name across files, which is completely normal and expected with internal (static) linkage, with or without LTO. nm showing N symbols named mutex when N files each declare their own private mutex is not duplication of anything — it's exactly N distinct objects behaving exactly as intended. Our "minimal reproducer" (playback.cc + art.cc) never demonstrated LTO duplication either — it just showed that linking any second file which also happens to declare its own static aud::mutex mutex; produces 2 mutex symbols, which was guaranteed from the start and has nothing to do with partition thresholds. The whole bisection table was almost certainly just tracking which of the 53 other files happen to also declare their own mutex/cond, not a real size/cost threshold in GCC's partitioner. *What this means for the real bug*: the original hang/leak/crash symptom (and the finding that swapping in a non-LTO libaudcore.so eliminates it) is still real and still worth explaining — but not as a GCC defect. The far more plausible explanation, per that dev's comment, is a genuine pre-existing data race in Audacious's own playback.cc around song_finished/failed_entries (or similar shared state), where LTO's more aggressive whole-program optimisation changes inlining/instruction timing enough to expose a race that milder optimisation levels happen not to hit. --- I'll do some more investigation when I get back in about 8 hours. But on your correction it appears not to be a GCC issue after all. I haven't reported this to Audacious yet because if compiling without LTO removed the problem then I felt the issue lay with the compiler. But since you and the revised analysis seems to point to Audacious' coding maybe this can be closed for now. Thanks for your time anyway.
