https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122992
--- Comment #21 from Kevin Stefanov <kevinstefanov15 at gmail dot com> --- (In reply to Frank Ch. Eigler from comment #20) > If you have access to a competent LLM chat thing, with MCP support (claude, > vscode, opencode, etc.), then consider adding > https://builder.sourceware.org/mcp as a HTTP streaming mcp server, and ask > it: > > > Check out the bunsen test results associated with gcc upstream > > > commit f6103f3a1e42fe4db15f3c1d96847cd4a4829e4e . Is there strong > > evidence that this patch caused regressions? Are these fixed now? > > > > > Any correlation between the partial recoveries and cpu flags? > > > > > > Any suggestion how to reproduce the regression on a dev workstation? None of the ones I've used so far (ChatGPT, Gemini, Claude) have shown that they're competent enough for me to confidently rely on them for technical GCC work, or any non-trivial programming for that matter. They spit out nonsense in a persuasive tone, right next to the correct things they tell you. I've been using them only for easy things, like checking the formatting of my ChangeLog, reminding me of the exact syntax of a command, explaining a topic from a language or a tool that's new for me, etc. I've seen them hallucinate wrong things when analyzing and emitting C++ code too many times for me to use them for anything beyond easy things like that. What I think about LLMs pretty much overlaps with Andrew Kelly's opinion on them - one is better off avoiding them for non-trivial technical work. I was under the impression that when my testsuite run comparison says I'm matching the test run results of the pristine GCC build, I can be confident that my patch won't break things, so I'm kind of confused right now about what's going on, to be honest. I'm new to all this here and would appreciate some guidance. In the end, is my patch wrong, or was the test that reported it to have caused a regression somehow misconfigured?
