Policy on use of LLM tools and bug fixes

[Joseph Myers]

On Sat, 25 Apr 2026, Richard Biener via Gcc wrote:

> > Am 24.04.2026 um 22:08 schrieb Thomas Koenig <tkoenig@netcologne.de>:
> > 
> > Am 24.04.26 um 11:02 schrieb Richard Biener via Gcc:
> >> The actual issues we're going to have with LLMs are much more likely
> >> that people do not understand the code LLMs produce and we end up
> >> having (more) code that's not really maintainable.
> > 
> > Or even worse: What the AI tools generate is like the (by now
> > proverbial) house where the walls and beams are made of foam
> > and the art is load-bearing.
> > 
> > (Current LLM tools make extremely bad software architecture
> > decisions).
> 
> I must say this is not solely a property of LLMs… ;)
> 
> I’d also not accept big infrastructure designed by LLMs.  I still hope 
> for sensible use of LLMs for GCC, like finishing long neglected partial 
> transitions.  I do not think LLMs are ready to implement new compiler 
> features.

Note that using an LLM on a partial transition doesn't always mean using 
the LLM to generate changes to GCC directly (with associated risks of 
mixing in some change that isn't part of what was requested).  It could, 
for example, mean using the LLM to generate an ugly ad hoc Python script 
that does the edits to the GCC sources (because such a script doesn't need 
to be maintained after it's used, there's much less concern about it 
having a low-quality design).  E.g. for transitioning more target macros 
to hooks, probably a large proportion (where a one-to-one correspondence 
between macros and hooks is appropriate and the macro is only used in the 
compiler proper, for example) could be transitioned by ad hoc scripts 
given some human guidance on the types to use for the new target hooks.

-- 
Joseph S. Myers
josmyers@redhat.com