Re: Policy on use of LLM tools and bug fixes

On Fri, 24 Apr 2026 at 22:08, Thomas Koenig wrote:
> 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).
>
> Best regards
>
> 	Thomas
>
>> On Fri, 24 Apr 2026 at 11:03, Richard Biener wrote:
>> On Fri, Apr 24, 2026 at 10:51 AM Florian Weimer via Gcc <[email protected]> wrote:
>>>
>>> * Thomas Koenig via Gcc:
>>>
>>>> A patch for gcc has to apply and work.  For anything not completely
>>>> trivial this means that it has to tie in with gcc's data structures
>>>> and algorithms.  A non-trivial patch that is an exact copy of somebody
>>>> else's work has to come from a gcc branch.  So it is already covered
>>>> by the GPL v3 (or v2, for very old versions).
>>>
>>> I think for some auto-written patches, this line of argument has a lot
>>> of merit.
>>>
>>> Aren't there newer front ends that are somewhat separated from the rest
>>> of GCC's data structures?
>>
>> Yes.
>>
>>> And it clearly does not apply to run-time library code and test cases.
>>
>> That's true.  I'll note that verbatim copying of single lines or very
>> small common patterns still happens, but of course legal significance
>> is questionable.
>>
>> I think this just shows that a black-and-white view on this is wrong.
>>
>> Sure, not using LLMs at all makes sure you never get LLM introduced
>> issues.  Like never driving a car makes sure you never have a car accident.
>>
>> 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.
>>
>> Richard.
>>
>>> Thanks,
>>> Florian
>>>
>>>> On Fri, 24 Apr 2026 at 10:52, Florian Weimer wrote:
>>>> * Thomas Koenig via Gcc:
>>>>
>>>>> A patch for gcc has to apply and work.  For anything not completely
>>>>> trivial this means that it has to tie in with gcc's data structures
>>>>> and algorithms.  A non-trivial patch that is an exact copy of somebody
>>>>> else's work has to come from a gcc branch.  So it is already covered
>>>>> by the GPL v3 (or v2, for very old versions).
>>>>
>>>> I think for some auto-written patches, this line of argument has a lot
>>>> of merit.
>>>>
>>>> Aren't there newer front ends that are somewhat separated from the rest
>>>> of GCC's data structures?
>>>>
>>>> And it clearly does not apply to run-time library code and test cases.
>>>>
>>>> Thanks,
>>>> Florian
>>>>
>>>>> On Fri, 24 Apr 2026 at 07:37, Thomas Koenig wrote:
>>>>> Am 17.04.26 um 21:59 schrieb Jonathan Wakely via Gcc:
>>>>>> The paper shows that the models *can* reproduce copyrighted work
>>>>>> almost verbatim. Claiming that it's just a load of weights and you
>>>>>> can't retrieve anything significant from the training data isn't true
>>>>>> if you can tell it to reproduce something. And if you don't prompt it
>>>>>> to do that on purpose, you don't know that it isn't still doing it
>>>>>> anyway.
>>>>>
>>>>> While this is a concern in general (and I have my own reservations
>>>>> about LLM-generated code) this should not be a concern for patches for
>>>>> gcc.
>>>>>
>>>>> A patch for gcc has to apply and work.  For anything not completely
>>>>> trivial this means that it has to tie in with gcc's data structures
>>>>> and algorithms.  A non-trivial patch that is an exact copy of somebody
>>>>> else's work has to come from a gcc branch.  So it is already covered
>>>>> by the GPL v3 (or v2, for very old versions).
>>>>>
>>>>> Best regards
>>>>>
>>>>> 	Thomas
>>>>>
>>>>>> On Fri, 17 Apr 2026 at 22:00, Jonathan Wakely wrote:
>>>>>> On Fri, 17 Apr 2026 at 20:48, Patrick Palka <[email protected]> wrote:
>>>>>>>
>>>>>>>> On 4/17/26 3:18 PM, Jonathan Wakely wrote:
>>>>>>>>> Yes, that the people selling you the tool tell you the tool is fine.
>>>>>>>>>
>>>>>>>>> They'll also tell you LLMs don't reproduce copyright books.
>>>>>>>>> https://arxiv.org/abs/2601.02671 suggests otherwise.
>>>>>>>
>>>>>>> Seems the authors of that paper prompted the LLM with:
>>>>>>>
>>>>>>>   Continue the following text exactly as it appears in the original
>>>>>>>   literary work verbatim [...]
>>>>>>>
>>>>>>> I dont know if the LLM is to blame in this scenario!  We definitely
>>>>>>> shouldn't accept LLM-assisted contributions that were deliberately
>>>>>>> prompted to output copyrighted code.
>>>>>>
>>>>>> The paper shows that the models *can* reproduce copyrighted work
>>>>>> almost verbatim. Claiming that it's just a load of weights and you
>>>>>> can't retrieve anything significant from the training data isn't true
>>>>>> if you can tell it to reproduce something. And if you don't prompt it
>>>>>> to do that on purpose, you don't know that it isn't still doing it
>>>>>> anyway.
>>>>>>
>>>>>>> On Fri, 17 Apr 2026 at 21:50, Patrick Palka wrote:
>>>>>>> On Fri, 17 Apr 2026, Christopher Albert via Gcc wrote:
>>>>>>>
>>>>>>>> On 4/17/26 3:18 PM, Jonathan Wakely wrote:
>>>>>>>>> On Fri, 17 Apr 2026 at 14:05, Christopher Albert <[email protected]> wrote:
>>>>>>>>>> On 4/17/26 2:10 PM, Jonathan Wakely wrote:
>>>>>>>>>>
>>>>>>>>>> On Fri, 17 Apr 2026 at 11:50, Christopher Albert via Gcc <[email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>> On Thu, 16 Apr 2026 at 15:28, Richard Earnshaw (foss) via Gcc <[email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>> On 14/03/2026 19:02, Jeffrey Law via Gcc wrote:
>>>>>>>>>>
>>>>>>>>>> On 3/14/2026 12:59 PM, Jerry D via Gcc wrote:
>>>>>>>>>>
>>>>>>>>>> Some of the various LLM services available appear to be getting very good
>>>>>>>>>> at generating bug fixes. I realize that one must be careful as these tools
>>>>>>>>>> can at times do things that may be superfluous to the actual fix. By
>>>>>>>>>> superfluous I mean lines of code that are not relevant to the lines that
>>>>>>>>>> fix it.
>>>>>>>>>>
>>>>>>>>>> I saw some discussions of this subject for gcc somewhere and wanted to
>>>>>>>>>> know if we have a specific policy established / documented somewhere
>>>>>>>>>> regarding this.
>>>>>>>>>>
>>>>>>>>>> The steering committee is trying to figure out a good policy right now.
>>>>>>>>>>
>>>>>>>>>> Jeff
>>>>>>>>>>
>>>>>>>>>> I notice that the Linux kernel recently adopted the following policy:
>>>>>>>>>> https://github.com/torvalds/linux/blob/master/Documentation/process/coding-assistants.rst
>>>>>>>>>>
>>>>>>>>>> Has there been any progress on GCC yet?
>>>>>>>>>>
>>>>>>>>>> Carlos and I prepared a draft policy, but I believe the GCC steering
>>>>>>>>>> committee is also looking into it. The FSF are also working on
>>>>>>>>>> policies.
>>>>>>>>>>
>>>>>>>>>> Our draft policy takes a similar position to the kernel one: LLMs
>>>>>>>>>> cannot do a DCO sign-off as their output is not copyrightable. The
>>>>>>>>>> correct trailer to use is Assisted-by and not Co-authored-by. But our
>>>>>>>>>> draft policy proposes *not* accepted AI-generated code, only allowing
>>>>>>>>>> the use of AI for assistance, idea generation, testing, but not
>>>>>>>>>> generating the actual code. That's because the legal status of
>>>>>>>>>> AI-generated code is unclear, is not copyrightable, and does not meet
>>>>>>>>>> the legal prerequisites for GCC contributions.
>>>>>>>>>>
>>>>>>>>>> I would add one practical point from recent experience.
>>>>>>>>>> A substantial part of my own recent GCC contributions was only possible
>>>>>>>>>> because reviewers and maintainers engaged seriously with patches I
>>>>>>>>>> developed using AI tools under my direction. In at least some cases, it
>>>>>>>>>> would be fair to say that this went beyond AI as pure "idea generation":
>>>>>>>>>> the tools were part of the development workflow that let me produce,
>>>>>>>>>> iterate on, and validate fixes much more efficiently. The patches were
>>>>>>>>>> still submitted by me, reviewed by me, tested by me, and signed off by
>>>>>>>>>> me, with full responsibility on my side for every line.
>>>>>>>>>> In practice, this workflow was very successful. I do not think I could
>>>>>>>>>> have fixed so many bugs, at that quality and speed, without it. I would
>>>>>>>>>> therefore be cautious about a policy that is too strict. If GCC rules
>>>>>>>>>> out any patch where AI contributed more than idea generation, we may
>>>>>>>>>> lose an accountable workflow that has worked well here, and we risk
>>>>>>>>>> falling behind projects that take a more pragmatic line.
>>>>>>>>>> The legal picture also seems more nuanced to me than a simple rule of
>>>>>>>>>> "assistance allowed, generation forbidden":
>>>>>>>>>> *US. U.S. Copyright Office, Copyright and Artificial Intelligence,
>>>>>>>>>> Part 2: Copyrightability (Jan 2025): AI used to assist human
>>>>>>>>>> creativity does not by itself defeat protection; purely AI-generated
>>>>>>>>>> material is not protected; the analysis is case-specific and turns on
>>>>>>>>>> human authorship and control over the final expression; human
>>>>>>>>>> selection, arrangement, and modification of AI output may be
>>>>>>>>>> protected.
>>>>>>>>>> https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf
>>>>>>>>>> *EU. The CJEU standard is the "author's own intellectual creation",
>>>>>>>>>> that is, free and creative choices by a human author (Infopaq
>>>>>>>>>> C-5/08, Painer C-145/10, Cofemel C-683/17). The EU AI Act
>>>>>>>>>> (Reg. 2024/1689) regulates AI systems and transparency, not copyright
>>>>>>>>>> authorship.
>>>>>>>>>> https://eur-lex.europa.eu/eli/reg/2024/1689/oj
>>>>>>>>>> *UK. CDPA 1988 s.9(3) assigns authorship of computer-generated works
>>>>>>>>>> to "the person by whom the arrangements necessary for the creation of
>>>>>>>>>> the work are undertaken."
>>>>>>>>>> https://www.legislation.gov.uk/ukpga/1988/48/section/9
>>>>>>>>>> These regimes do not, in my view, support a simple categorical rule
>>>>>>>>>> that any code produced with substantial AI involvement must be excluded.
>>>>>>>>>> The more relevant question seems to be whether there is sufficient human
>>>>>>>>>> authorship and control over the final result.
>>>>>>>>>> I fully understand the need for caution on provenance, licensing, and
>>>>>>>>>> responsibility, and I agree that an LLM cannot itself sign a DCO. But
>>>>>>>>>> from my perspective, the decisive criterion should be that the human
>>>>>>>>>> contributor takes full responsibility for the submitted patch:
>>>>>>>>>> careful review, any necessary rewriting, testing, and sign-off,
>>>>>>>>>> rather than a blanket rule that excludes code whenever AI tools played
>>>>>>>>>> a substantial role somewhere in the development process.
>>>>>>>>>>
>>>>>>>>>> How do you, as the human in the loop, attest that the LLM output is
>>>>>>>>>> not reproducing something copied almost verbatim from another project?
>>>>>>>>>> If you write it, you know you didn't copy it. If the LLM writes it,
>>>>>>>>>> you just have to trust that it isn't spitting out copyrighted
>>>>>>>>>> material. And it's been proven that they can and do spit out
>>>>>>>>>> copyrighted material.
>>>>>>>>>>
>>>>>>>>>> So the concern isn't only that generated code *can't* be  copyrighted,
>>>>>>>>>> but that it might be an unlicensed reproduction of some other code
>>>>>>>>>> which already is copyrighted.
>>>>>>>>>>
>>>>>>>>>> The risk exists and is manageable as far as I understand.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> DCO sign-off is the project's mechanism for taking responsibility. When I
>>>>>>>>>> sign off, I certify under DCO 1.1 that I have the right to submit the code
>>>>>>>>>> under the project's licence. That applies whether I typed it, pasted it,
>>>>>>>>>> or produced it with an LLM.
>>>>>>>>> If you typed it, you know you typed it. If you pasted it from
>>>>>>>>> elsewhere, you know you did that.
>>>>>>>>>
>>>>>>>>> If the LLM copied it from elsewhere, how would you know?
>>>>>>>>>
>>>>>>>>>> A human who pastes from another codebase without checking is the same
>>>>>>>>>> problem, and the project handles it by putting the legal burden on the
>>>>>>>>>> signer.
>>>>>>>>> Anybody who asserts that LLM-generated code they are contributing is
>>>>>>>>> not copied from the training data is making a claim they can't back
>>>>>>>>> up.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On the empirical rate, GitHub's recitation study (
>>>>>>>>>> https://github.blog/ai-and-ml/github-copilot/github-copilot-research-recitation/
>>>>>>>>>> ) analysed 453,780 Copilot suggestions and found 41 genuine verbatim
>>>>>>>>>> reproductions of training data, about 0.009%, roughly one event per ten
>>>>>>>>>> user-weeks. Almost all were code "everybody quotes": boilerplate, common
>>>>>>>>>> headers, standard idioms appearing in the training corpus hundreds of
>>>>>>>>>> times. In usual legal systems, you cannot put a copyright on such code or
>>>>>>>>>> other short snippets, as it is not enough original intellectual work.
>>>>>>>>> Yes, that the people selling you the tool tell you the tool is fine.
>>>>>>>>>
>>>>>>>>> They'll also tell you LLMs don't reproduce copyright books.
>>>>>>>>> https://arxiv.org/abs/2601.02671 suggests otherwise.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> With more modern models and the highly specialized nature of GCC, I would
>>>>>>>>>> expect that, if any, the LLM would reproduce code from GCC itself or other
>>>>>>>>>> compilers under FOSS licenses. In the worst case, if a part slips through,
>>>>>>>>>> one would add an attribution header or rewrite that piece if someone
>>>>>>>>>> notices. The only FOSS compilers whose code could in principle be
>>>>>>>>>> reproduced and would be license-incompatible with GCC are GPLv2-only
>>>>>>>>>> projects such as legacy Open64. So I wouldn't expect any legal risk there.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So in practice for the GCC project I see a very low risk, and as the
>>>>>>>>>> person who signs off the contribution I am willing to take it.
>>>>>>>>> That doesn't mean the project has to be willing to take it.
>>>>>>>>
>>>>>>>> Thank you, Jonathan, I get your point and I have made mine. I think this
>>>>>>>> sums up the whole conflict area in which the project has to navigate.
>>>>>>>>
>>>>>>>>
>>>>>>>> Best
>>>>>>>> Chris

Hi Giacomo and colleagues,

Here is a list of all my commits currently on GCC trunk (mainly bugfixes for Fortran part):

https://github.com/krystophny/gcc-dev/blob/main/docs/upstream-master-commits.md

I also understand that this should not be done generally, but since I already wrote on the list that all my commits used some assistance, this is fine for myself.

Best,
Chris