https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126661
--- Comment #2 from Drea Pinski <pinskia at gcc dot gnu.org> --- I suspect the issue is related to song_finished or failed_entries. and there might be a race condition there. I highly doubt there is a LTO issue in GCC with respect a std::mutex nor a static variable/funciton issue. I suspect there is some race condition that being exposed by more optimization with LTO. The LLM written description of the issue tries to explain what GCC is doing and yes it explaination is close. But it does not point to what is going wrong at all. >**Identical result: 13 copies of `mutex`, 2 copies of `cond`**, same functions No, there are actually 13 different mutex variables. each static ones from the .cc files. So that is not the problem. That is definitely a misunderstanding. Two distinct storage locations (`0xb400`, `0xb360`) for the same file-static `mutex`, referenced from functions compiled into different LTO partitions (`finish_item`/`art_item_unref` in `art.cc` vs. `request_seek`/ `playback_cleanup` in `playback.cc`) — the identical class of bug as the original 13-copy finding, at the smallest scale that still crosses the partitioning threshold. Huh? art.cc and playback.cc has their own mutex object and don't share according to the sources themself. So yes this is LLM slop.
