[Bug rtl-optimization/122992] speed up loops with TEST_HARD_REG_BIT using EXECUTE_IF_SET_IN_HARD_REG_SET

kevinstefanov15 at gmail dot com gcc-bugzilla@gcc.gnu.org
Fri Jun 5 04:14:09 GMT 2026


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?


More information about the Gcc-bugs mailing list