On Sat, 25 Apr 2026, Richard Biener via Gcc wrote: > > Am 24.04.2026 um 22:08 schrieb Thomas Koenig <[email protected]>: > > > > 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 [email protected]
