Andrea (Drea) Tamar PinskiOct 24

Let's try something different today.
Reply with your favorite still opened gcc bug report (https://gcc.gnu.org/bugzilla/) . I am going to put together a poll next week on which bug report i should fix and that poll will be based on the responses here.
Disclaimer, X86_64 and aarch64 target specific bugs are OK, other backends depending on the bug report might be fine but I will reply to your toot if it will be included in the poll. If I get a lot of responses, I might have a few polls to narrow down which one I implement.

This is for 2 reasons, one to show gcc developers still care about the bug reports (especially with over 18k of them filed) and 2 to give an opportunity to users to see more of the process. Also sometimes I like giving back to the users of gcc.

GCC Bugzilla Main Page

Show threadDan Riley

@pinskia I guess everyone is shy about admitting to a favorite bug? Well…if libstdc++ is in scope, I nominate https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704

That’s been responsible for at least a couple of difficult to find failures in multithreaded code.

77704 – Data race on std::ctype<char>

Oct 25 at 12:28amWeb
Show threadAndrea (Drea) Tamar PinskiOct 25

@dan131riley

libstdc++ is definitely in the scope. Though I have not worked as much in the library as other areas of GCC.

I see Jonathan fixed one of the data races.

Show threadJ.W.Oct 25
@pinskia @dan131riley I think I have a patch for the remaining data race, but it adds overhead. I'll dig it out and refresh my memory
Show threadJ.W.Oct 25
@dan131riley @pinskia what kind of failures? IIRC it can result in two or more threads writing the same value to the same memory location at the same time, but if the writes are atomic I'm not sure what can actually fail.
Show threadJ.W.Oct 25
@dan131riley @pinskia and once those values have been written, they're never changed to other values. So definitely a data race, and will cause TSan errors, but I'm struggling to see what observable failures it can cause. I think it might cause problems if the compiler moves a store to `_M_narrow_ok` before the call to `do_narrow` (in the `_M_narrow_init()` function inside the shared library), but since that call is virtual and can't be devirtualized when compiling libstdc++.so, I don't think moving that store would be a valid optimization.
Show threadDan RileyOct 25

@wako @pinskia I have to apologize and withdraw the nomination. Digging out the details, that was raised as a possibility for an ASAN out-of-bounds report, but looking back it’s clear that wasn’t the problem. More likely some combo of ASAN and LTO—we’ve had a some strange problems with LTO, unfortunately difficult to isolate.

https://github.com/cms-sw/cmssw/issues/40902 is the issue I was remembering, but probably not related to the regex race (and resolved by getting rid of the regex).

Show threadJ.W.Oct 25
@dan131riley @pinskia well it prodded me to take another look at an old bug, so maybe I'll fix it next week anyway :)