Mastodawn

Krister Walfridsson Oct 24

Andrea (Drea) Tamar Pinski

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

@pinskia https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121230

121230 – [13/14/15/16 regression] x86: Inefficient code generation with -m3dnow -msse since GCC 12

Yann Droneaud Oct 24

@pinskia how old should the bug report be ?

Andrea (Drea) Tamar Pinski Oct 24

@ydroneaud Could be 5 minutes old or 20 years old (there are 434 which are 20+ years old even) . I am not too picky.

Bernhard Oct 24

@pinskia not in scope but any help how to approach the challenges, their feasibility or mailinglist streetcred would be appreciated :D https://gist.github.com/DO3RB/aa5b1f2558d247dd01ce20c7928fb079
edit: found a bugentry for it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99937

ARM Cortex-M Costing of Multiply

ARM Cortex-M Costing of Multiply. GitHub Gist: instantly share code, notes, and snippets.

Gist

Andrea (Drea) Tamar Pinski Oct 24

@bernerd Sorry I don't know enough about the arm (aarch32) cost functions or backend to say what you are doing is correct. You can always ask on gcc@ or file a bug report since I do consider that an missed-optimization issue; there are a few arm folks that still care a little bit about aarch32 and GCC so it might get a look into.

Note the `+16` seems to have been there since before 2004 (I looked at git blame) so it might be that far out of date.

Martin Uecker Oct 25

@pinskia
Here is mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159

96159 – atomic creates incorrect code for possible misaligned struct

@pinskia https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101027

101027 – Short-circuit behavior not respected with co_await in while head

Andrea (Drea) Tamar Pinski Oct 24

@horenmar co-routines part of the c++ is something I have stayed away from except for confirming the bug report. Maybe it is time for me to look into this one anyways.

Simon Richter Oct 24

@pinskia all of mine already have a reply from you anyway :)

One that isn't a gcc bug for the most part, but difficult to tackle is that ghdl fails to generate valid code from the gcc backend on RISC-V because it does the initialization wrong, so the machine type is an empty string, causing an invalid assembler directive without an argument to be output.

My feeling is that the RISC-V backend is a bit brittle here, and essentially relies on the frontend and the specs to provide a default.

Calling cc1 for RISC-V directly, and giving it an empty input generates an assembler file containing

.attribute arch, ""

which isn't valid.

I'm not sure this should be a bug report, it's just one of these cases where it's difficult to determine what should happen -- should the ghdl frontend bring its own specs file?

penguin42 Oct 24

@pinskia Well, I did report this one about 18 months ago, so fairly new; and it's only a missing warning.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115027

Andrea (Drea) Tamar Pinski Oct 24

@penguin42 a patch for that one was already posted but never approved. It had one review to it asking about a specific testcase and the author of the patch didnt reply either.
So this looks like something I can maybe help with separately.

penguin42 Oct 24

@pinskia Oh thanks! It's not urgent; but the self-referential part is kind of fun.

Dan Riley Oct 25

@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>

Andrea (Drea) Tamar Pinski Oct 25

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.

@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

@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.

@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.

Dan Riley Oct 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).

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

Zack Weinberg Oct 25

@pinskia gotta be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501

18501 – [13/14/15/16 Regression] Missing 'used uninitialized' warning (CCP)

Andrea (Drea) Tamar Pinski Oct 25

@zwol I knew i was asking for trouble when I asked this question.

Warnings during optimization is the biggest area I hate the most in gcc recently. Fixing this false negative has been one of my ideas i work on for gcc 17. I think this one is too big for a weekend project which I had hoped this list would provide me.
We (gcc) has to figure out something for gcc 17 for these Warnings though .

@pinskia https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121671

https://compiler-explorer.com/z/8YrrKhTbo

121671 – Confusing compile error message with std::visit and std::format_string