Hey Elle! On 1/20/26 4:00 PM, Weathered Steel wrote:
Hello,FWIW, I am a relatively new contributor to GCCRS myself, so take my opinion with a grain of salt.In my opinion, all use of LLMs for code generation should be disallowed. Such a ban simplifies things, and contributors would still be free to use them as a search engine equivalent, if they insist on using them.Of course, contributors that absolutely insist on using them for code generation will probably attempt to hide their usage if it is banned. However, there is nothing really that can be done about it, and if there is a hard rule against usage we can at least call them out when it happens.I think banning LLMs for code generation outright also helps convey the message that contributors should be using this opportunity for real- world learning in the FOSS community. If they want to use LLMs, they can go get a corporate internship where I'm sure that behavior is very welcome.All the best, Elle
This has been the stance of the core team for a while now, where we outright refuse LLM-generated contributions. This is usually easy to spot as contributors can't explain why something is done a certain way, or can't adapt their code according to reviewer comments.
I agree that stating something in the project's README would be good.Regarding GSoC applications, we have had our fair share of AI generated applications in the last few years and we have always rejected them - I think it'd be good to mention it directly on the wiki, which is what I'll reply to the main discussion thread that started this.
However, with all the hate that I harbor for LLMs, we have to keep in mind that a lot of new contributors simply do not know better or do not know why they are bad. It is important to encourage students and contributors, and to first assume that they do not intend any harm by using these LLMs. People who do want to contribute will be more than happy to not use LLMs for code generation, and will try and produce meaningful contributions.
For example, we quite often run into a situation where we have LLM-generated GSoC proposals because the student does not feel confident enough in English to write the proposal themselves. It's important to remind them that we are interested in reading what *they* have to say about their project, instead of what ChatGPT thinks, and that a much more interesting process is to use LLMs to help translate their native language rather than write the entire proposal.
We must continue to foster a welcoming space for anyone even remotely interested in contributing to compilers, and have to be patient even when reviewing clear AI generated content (and I'm not saying that you were implying anything other than this).
I'm happy for you to submit modifications to the README if you want! It's something I've been meaning to address for a few months now, and the AI craze still hasn't died (sadly), so I think it is more important than ever for gccrs to take a public stance on this.
Thanks for talking about this, Arthur
On 1/20/26 1:47 PM, Tucker Taft wrote:We plan to submit another project to implement Ada 2022 features in the GCCAda front end that have not yet been implemented. Last year's implementation of the Ada 2022 parallel features was successful, andreceived a lot of interest. A related feature is compile-time checking of the safe use of global variables and other shared variables in the contextof parallel processing, and would have the effect of detecting data races at compile time, ensuring that the parallel features are being used correctly. -Tucker Taft and Richard Wai On Mon, Jan 19, 2026 at 10:11 AM Martin Jambor <[email protected]> wrote:Hello, another year has passed, Google has announced there will be again GoogleSummer of Code (GsoC) in 2026 and the deadline for organizations to applyis already approaching (February 3rd). I'd like to volunteer to be the main org-admin for GCC again but let me know if you think I shouldn't orthat someone else should or if you want to do it instead. Otherwise I'llassume that I will and I hope that I can continue to rely on Thomas Schwinge and David Edelsohn to back me up and help me with some decision making along the way as my co-org-admins.======================== The most important bit: ========================I would like to ask all (moderately) seasoned GCC contributors to consider mentoring a contributor this year and ideally also come up with a project that they would like to lead. We are collecting proposal on our wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the top list there. Or, if you are unsure, post your offer and project idea as areply here to the mailing list. Additionally, if you have added an idea to the list in recent years, please review it whether it is still up-to-date or needs adjusting or should be removed altogether. ========================================================================= At this point, we need to collect list of project ideas. Eventually, each listed project idea should have: a) a project title, b) more detailed description of the project (2-5 sentences), c) expected outcomes (we do have a catch-almost-all formulation that outcome is generally patches at the bottom of the list on the wiki), d) project size - whether it is expected to take approximately 350, 175 or just 90 hours (see below about the last option), e) difficulty (easy, hard or medium, but we don't really have easy projects), f) expected mentors, g) skills required/preferred, and...h) [this is new] ...pointers to things applicant should study in orderto learn about the topic. Please think also about a way to verifythey can get basic stiff done (post test results, look up basic stuff in a gdb session... etc) though these do not need to be listed, these can be requested when they approach us. (See notes from Cauldron 2025 GSoC BoF: https://gcc.gnu.org/pipermail/gcc/2025- October/246780.html). Project ideas that come without an offer to also mentor them are always fun to discuss, by all means feel free to reply to this email with yours and I will attempt to find a mentor, but please be aware that we can only use the suggestion it if we actually find one or ideally two. Everybody in the GCC community is invited to go over https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or otherwise bad project suggestions and help improve viable ones. Finally, please continue helping (prospective) students figure stuff out about GCC like you have always done in the past. GSoC 2026 should be quite similar to the last year, the most important parameters probably are these: - Contributors (formerly students) must either be full-time students or be "beginners to open source." - There are now three project sizes: roughly 90 hors (small), roughly 175 hours (medium-sized) and roughly 350 hours (large) of work in total. The small option was introduced in 2024 but because our projects usually have a lengthy learning period, I think we will almost always want to stick to the medium and large variants. - Timing should be pretty much as flexible as last year. The recommended "standard" duration is 12 weeks but depending on contributor's and mentor's needs and circumstances, projects can take anywhere between 10 and 22 weeks. There will be one mid-term and one final evaluation. For further details you can see: - The announcement of GSoC 2026:https://opensource.googleblog.com/2025/12/shape-future-with-google- summer-of-code.html- GSoC rules: https://summerofcode.withgoogle.com/rules - Detailed GSoC 2026 timeline: https://developers.google.com/open-source/gsoc/timeline - Elaborate project idea guidelines: https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list Thank you very much for your participation and help. Let's hope we attract some great contributors again this year. Martin
OpenPGP_0x1B3465B044AD9C65.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
