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
On 1/20/26 1:47 PM, Tucker Taft wrote:
We plan to submit another project to implement Ada 2022 features in the GCC
Ada front end that have not yet been implemented. Last year's
implementation of the Ada 2022 parallel features was successful, and
received a lot of interest. A related feature is compile-time checking of
the safe use of global variables and other shared variables in the context
of 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 Google
Summer of Code (GsoC) in 2026 and the deadline for organizations to apply
is 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 or
that someone else should or if you want to do it instead. Otherwise I'll
assume 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 a
reply 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 order
to learn about the topic. Please think also about a way to verify
they 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
