GCC GSoC 2026: Call for project ideas and mentors

GCC GSoC 2026: Call for project ideas and mentors

[Martin Jambor]

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

Re: GCC GSoC 2026: Call for project ideas and mentors

[Richard Biener]

On Mon, Jan 19, 2026 at 4:08 PM Martin Jambor <mjambor@suse.cz> 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).

If GSoC does not have, we should, at least, set a clear expectation as to
how usage of AI in completing the project is [not] allowed and should be
documented.

Richard.

> 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

Re: GCC GSoC 2026: Call for project ideas and mentors

[Ville Voutilainen]

On Mon, 19 Jan 2026 at 20:36, Richard Biener <richard.guenther@gmail.com> wrote:
> If GSoC does not have, we should, at least, set a clear expectation as to
> how usage of AI in completing the project is [not] allowed and should be
> documented.

Yes, please. The GSoC mentors' discussions I can find in my inbox
don't exactly suggest such a clear policy
being in place, and various participating organizations have their
own. And I would venture a suggestion
that such a policy should be there in general for GCC, not just for
GCC GSoC projects.

In various places, people are being reminded, rather than newly told,
that blindly merging LLM-generated code
is as bad (and in some ways exactly as bad) as blindly copying code
from a random internet site, even if the
name of that site is "StackOverflow" and you really really like the
site. The problems are identical, and such blind copying can't be
accepted,
due to copyright reasons.

Re: GCC GSoC 2026: Call for project ideas and mentors

[Richard Biener]

On Mon, Jan 19, 2026 at 7:46 PM Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> On Mon, 19 Jan 2026 at 20:36, Richard Biener <richard.guenther@gmail.com> wrote:
> > If GSoC does not have, we should, at least, set a clear expectation as to
> > how usage of AI in completing the project is [not] allowed and should be
> > documented.
>
> Yes, please. The GSoC mentors' discussions I can find in my inbox
> don't exactly suggest such a clear policy
> being in place, and various participating organizations have their
> own. And I would venture a suggestion
> that such a policy should be there in general for GCC, not just for
> GCC GSoC projects.

The DCO, even though I think it's obvious, might also get a clarifying
amendment that what an AI tool produced is not obviously your work
or can be considered OK to contribute.  Same holds for people
contributing using FSF assignment - you can only assign sth you
have rights on.

Richard.

> In various places, people are being reminded, rather than newly told,
> that blindly merging LLM-generated code
> is as bad (and in some ways exactly as bad) as blindly copying code
> from a random internet site, even if the
> name of that site is "StackOverflow" and you really really like the
> site. The problems are identical, and such blind copying can't be
> accepted,
> due to copyright reasons.

Re: GCC GSoC 2026: Call for project ideas and mentors

[Toon Moene]

On 1/19/26 19:51, Richard Biener wrote:

> On Mon, Jan 19, 2026 at 7:46 PM Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:

> The DCO, even though I think it's obvious, might also get a clarifying
> amendment that what an AI tool produced is not obviously your work
> or can be considered OK to contribute.  Same holds for people
> contributing using FSF assignment - you can only assign sth you
> have rights on.

This might seem far fetched for people who do not know how Machine 
Learning works - but it is not impossible that the suggested code it 
comes up with is in whole or in a very large part someone's actually 
published work.

My own brother encountered this when quotes from his text book on 
air-surface interaction in boundary layer meteorology showed up in 
students' work *that could be traced back* to the use of AI tools.

Kind regards,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Re: GCC GSoC 2026: Call for project ideas and mentors

[Ville Voutilainen]

On Mon, 19 Jan 2026 at 21:00, Toon Moene <toon@moene.org> wrote:
>
> On 1/19/26 19:51, Richard Biener wrote:
>
> > On Mon, Jan 19, 2026 at 7:46 PM Ville Voutilainen
> > <ville.voutilainen@gmail.com> wrote:
>
> > The DCO, even though I think it's obvious, might also get a clarifying
> > amendment that what an AI tool produced is not obviously your work
> > or can be considered OK to contribute.  Same holds for people
> > contributing using FSF assignment - you can only assign sth you
> > have rights on.
>
> This might seem far fetched for people who do not know how Machine
> Learning works - but it is not impossible that the suggested code it
> comes up with is in whole or in a very large part someone's actually
> published work.
>
> My own brother encountered this when quotes from his text book on
> air-surface interaction in boundary layer meteorology showed up in
> students' work *that could be traced back* to the use of AI tools.

There's also more and more newbies who don't grok that, and work based
on hearsay. "I thought LLM output
isn't considered copyrightable", I heard today from a very surprising
source. I did explain that it's not about
someone slapping some additional copyright on a tool's output, but the
tool regurgitating copyrighted material
it has used as some sort of input. That explanation rang all the right
bells quickly enough, but going forward,
I think it wouldn't hurt to remind people about what's what more often
and in more places.

I also heard today from a slightly surprising source that there are
places where the no-LLM policies say "doesn't
apply to documentation" and I need to go and fix their misconceptions. :D

Re: GCC GSoC 2026: Call for project ideas and mentors

[Martin Jambor]

Hello,

On Mon, Jan 19 2026, Richard Biener wrote:
> On Mon, Jan 19, 2026 at 4:08 PM Martin Jambor <mjambor@suse.cz> 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).
>
> If GSoC does not have, we should, at least, set a clear expectation as to
> how usage of AI in completing the project is [not] allowed and should be
> documented.

That is a good point.  I believe GSoC leaves it to the participating
organizations to decide what is permitted.

The question is however larger than just GSoC, and I am not particularly
inlined to try to steer that more general discussion - nor am I in a
position to attempt to.

Nevertheless, I guess in the context of GSoC I cannot avoid it and plan
to basically explicitely ban it, if only because I definitely do not
want the relationship between GSoC mentors and contributors deteriorate
into mentors just talking to an LLM through "contributors."

I'm not sure what the best wording is yet.  Probably something like:

  "It is not permitted to use Large Language Model (such as ChatGPT,
   Gemini, Copilot etc.) to generate any non-trivial (legally
   significant) part of code that is produced as a part of GCC GSoC."

I may add an exception for testcases (explicitely marked as such), that
seems harmless and potentially useful.  Suggestions how to improve the
wording - in the context of GSoC only - welcome.

(Also, please note that we have not been accepted to the program in 2026
yet.)

Thanks for raising this important point,

Martin


>> 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

Re: GCC GSoC 2026: Call for project ideas and mentors

[Richard Biener]

On Tue, Jan 20, 2026 at 11:29 AM Martin Jambor <mjambor@suse.cz> wrote:
>
> Hello,
>
> On Mon, Jan 19 2026, Richard Biener wrote:
> > On Mon, Jan 19, 2026 at 4:08 PM Martin Jambor <mjambor@suse.cz> 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).
> >
> > If GSoC does not have, we should, at least, set a clear expectation as to
> > how usage of AI in completing the project is [not] allowed and should be
> > documented.
>
> That is a good point.  I believe GSoC leaves it to the participating
> organizations to decide what is permitted.
>
> The question is however larger than just GSoC, and I am not particularly
> inlined to try to steer that more general discussion - nor am I in a
> position to attempt to.
>
> Nevertheless, I guess in the context of GSoC I cannot avoid it and plan
> to basically explicitely ban it, if only because I definitely do not
> want the relationship between GSoC mentors and contributors deteriorate
> into mentors just talking to an LLM through "contributors."
>
> I'm not sure what the best wording is yet.  Probably something like:
>
>   "It is not permitted to use Large Language Model (such as ChatGPT,
>    Gemini, Copilot etc.) to generate any non-trivial (legally
>    significant) part of code that is produced as a part of GCC GSoC."
>
> I may add an exception for testcases (explicitely marked as such), that
> seems harmless and potentially useful.  Suggestions how to improve the
> wording - in the context of GSoC only - welcome.
>
> (Also, please note that we have not been accepted to the program in 2026
> yet.)

Maybe also prominently add to the wiki that AI generated applications
will be immediately disregarded (I expect the level of "spam" applications
to rise considerably this year...)

Richard.

> Thanks for raising this important point,
>
> Martin
>
>
> >> 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

Re: GCC GSoC 2026: Call for project ideas and mentors

[Richard Kenner]

>   "It is not permitted to use Large Language Model (such as ChatGPT,
>    Gemini, Copilot etc.) to generate any non-trivial (legally
>    significant) part of code that is produced as a part of GCC GSoC."

I like this language. It's very similar to what large companies
are starting to add into their standard purchase terms and conditions.

> I may add an exception for testcases (explicitely marked as such), that
> seems harmless and potentially useful.  

I agree except that I don't see the reason to identify them as such
and saying that adds complexity.

> Suggestions how to improve the
> wording - in the context of GSoC only - welcome.

I'd replace "legally significant" because we really don't want people
to feel they have to make legal decisions.  "de mimimus" isn't known
to lots of people either, but at least they can look it up.

I'd suggest: 

    You may not used use a Large Language Model (an "AI" such as
    ChatGPT, Gemini, and Copilot.) to generate any non-trivial (more
    than de-minimus) amount of code that you produce as a participant
    of GCC GSoC except for test cases.

Re: GCC GSoC 2026: Call for project ideas and mentors

[Richard Kenner]

>   "It is not permitted to use Large Language Model (such as ChatGPT,
>    Gemini, Copilot etc.) to generate any non-trivial (legally
>    significant) part of code that is produced as a part of GCC GSoC."

Actually, let me get back to this because there's an ambiguity here.
We certainly have no issue with people using an LLM to assist in their
work (by answering questions).  "Used to generate" could include this
scenario.  The issue isn't whether they are *using* an LLM, but about
including *code generated* by an LLM.  (And I had a typo.)  So let me
change my suggestion to:

    With the exception of test cases, you may not include any non-trivial
    (more than de-minimus) amount of code generated by a Large Language
    Model (an "AI" such as ChatGPT, Gemini, and Copilot.) in code that you
    submit as a participant of GCC GSoC.

Re: GCC GSoC 2026: Call for project ideas and mentors

[Richard Kenner]

>   "It is not permitted to use Large Language Model (such as ChatGPT,
>    Gemini, Copilot etc.) to generate any non-trivial (legally
>    significant) part of code that is produced as a part of GCC GSoC."

Actually, let me get back to this because there's an ambiguity here.
We certainly have no issue with people using an LLM to assist in their
work (by answering questions).  "Used to generate" could include this
scenario.  The issue isn't whether they are *using* an LLM, but about
including *code generated* by an LLM.  (And I had a typo.)  So let me
change my suggestion to:

    With the exception of test cases, you may not include any non-trivial
    (more than de-minimus) amount of code generated by a Large Language
    Model (an "AI" such as ChatGPT, Gemini, and Copilot.) in code that you
    submit as a participant of GCC GSoC.

Re: GCC GSoC 2026: Call for project ideas and mentors

[Tucker Taft]

[-- Attachment #1: Type: text/plain, Size: 5261 bytes --]

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 <mjambor@suse.cz> 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
>

Re: GCC GSoC 2026: Call for project ideas and mentors

[Ville Voutilainen]

On Tue, 20 Jan 2026 at 15:12, Richard Kenner <kenner@adacore.com> wrote:
>
> >   "It is not permitted to use Large Language Model (such as ChatGPT,
> >    Gemini, Copilot etc.) to generate any non-trivial (legally
> >    significant) part of code that is produced as a part of GCC GSoC."
>
> Actually, let me get back to this because there's an ambiguity here.
> We certainly have no issue with people using an LLM to assist in their
> work (by answering questions).  "Used to generate" could include this
> scenario.  The issue isn't whether they are *using* an LLM, but about
> including *code generated* by an LLM.  (And I had a typo.)  So let me
> change my suggestion to:
>
>     With the exception of test cases, you may not include any non-trivial
>     (more than de-minimus) amount of code generated by a Large Language
>     Model (an "AI" such as ChatGPT, Gemini, and Copilot.) in code that you
>     submit as a participant of GCC GSoC.

FWIW, I don't find the original suggestion ambiguous. "Use to
generate" is very different from
"Use to learn how to write".

Re: GCC GSoC 2026: Call for project ideas and mentors

[Richard Kenner]

> FWIW, I don't find the original suggestion ambiguous. "Use to
> generate" is very different from
> "Use to learn how to write".

It is different, but I still think "use" is too broad.  I might want
to write something, but be unsure of the best algorithm to use.  Or
the best way to interface to, say, the GCC tree.  So I ask ChatGPT
questions about that. I'm "using" those answers to generate code, but
not including code generated by ChatGPT.

Re: GCC GSoC 2026: Call for project ideas and mentors

[Ville Voutilainen]

On Tue, 20 Jan 2026 at 16:04, Richard Kenner <kenner@adacore.com> wrote:
>
> > FWIW, I don't find the original suggestion ambiguous. "Use to
> > generate" is very different from
> > "Use to learn how to write".
>
> It is different, but I still think "use" is too broad.  I might want
> to write something, but be unsure of the best algorithm to use.  Or
> the best way to interface to, say, the GCC tree.  So I ask ChatGPT
> questions about that. I'm "using" those answers to generate code, but
> not including code generated by ChatGPT.

Ah, let me clarify why I don't think the original is ambiguous: I
consider 'generate' a word-of-power.
It means using an actual generator to generate the code, not the
general act of generating code via
whichever means including typing it manually.

Re: GCC GSoC 2026: Call for project ideas and mentors

[Richard Kenner]

> Ah, let me clarify why I don't think the original is ambiguous: I
> consider 'generate' a word-of-power.
> It means using an actual generator to generate the code, not the
> general act of generating code via
> whichever means including typing it manually.

But others, including me, have a more generic definition.  So I think
we should be more specific.

Re: GCC GSoC 2026: Call for project ideas and mentors

[David Malcolm]

On Mon, 2026-01-19 at 16:08 +0100, Martin Jambor 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).

Thanks for volunteering to organize.

I can mentor a -fanalyzer GCC GSoC project this year.  I've gone
through the list of -fanalyzer ideas in:
  https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas
and the four of them still look good.  For (h) above, I've added this
note: "Applicants should familiarize themselves with GCC's GIMPLE
representation, and the internals of the static analyzer" (with a link
to the pertinent part of the gcc internals html).


[...]

Dave

Re: GCC GSoC 2026: Call for project ideas and mentors

[Martin Jambor]

Hello Tucker,

On Tue, Jan 20 2026, 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

this is great, but we need to have the list of project ideas ready by
couple of hours ago.  Sorry that I am only replying now, I was ill and
in bed the entire last week.

In reality I hope that we still have a few (but really only few) days to
add it.  Can you please write the project idea down and either directly
enter it to the wiki or email it to me?

I do need all the information described in points a - g below, but the
actual description really only needs to be 5-2 sentences and most of the
rest is even shorter.  Point h can be provided later but please think
about it so that you have something when students start applying.

Thanks a lot,

Martin


>
> On Mon, Jan 19, 2026 at 10:11 AM Martin Jambor <mjambor@suse.cz> 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
>>

Re: GCC GSoC 2026: Call for project ideas and mentors

[Martin Jambor]

Hello,

On Tue, Jan 20 2026, Richard Kenner wrote:
>>   "It is not permitted to use Large Language Model (such as ChatGPT,
>>    Gemini, Copilot etc.) to generate any non-trivial (legally
>>    significant) part of code that is produced as a part of GCC GSoC."
>
> Actually, let me get back to this because there's an ambiguity here.
> We certainly have no issue with people using an LLM to assist in their
> work (by answering questions).  "Used to generate" could include this
> scenario.  The issue isn't whether they are *using* an LLM, but about
> including *code generated* by an LLM.  (And I had a typo.)  So let me
> change my suggestion to:
>
>     With the exception of test cases, you may not include any non-trivial
>     (more than de-minimus) amount of code generated by a Large Language
>     Model (an "AI" such as ChatGPT, Gemini, and Copilot.) in code that you
>     submit as a participant of GCC GSoC.

Thanks, eventually I have used the above.  Along with a line about
quickly disregarding LLM generated applications.

Martin

Re: GCC GSoC 2026: Call for project ideas and mentors

[Tucker Taft]

[-- Attachment #1: Type: text/plain, Size: 8708 bytes --]

Sorry, we missed out on this stage of the process last year, so I was
unaware that you needed a concrete list of projects at this point.

Below is the proposal.

Sincerely,
-Tucker Taft

-----------------------------

Project title: Compile-time data-race detection and global variable analysis

Description:
  Ada 2022 specifies a series of levels of checking for data races and
global variable usage.
We propose to implement the Global variable analysis specified in the Ada
2022 RM section 6.1.2,
which checks that any use of global variables within a subprogram
correspond to the usages
specified by the "Global" aspect for the subprogram.  We also propose to
implement the compile-time
parallel conflict checking specified in section 9.10.1 as
"All_Parallel_Conflict_Checks" which verifies
that a parallel construct only reads or updates global variables that are
"synchronized" objects.

Expected outcome:
  The compiler will recognize the Global aspect for subprograms, and detect
uses
of global variables that exceed the specification for a given subprogram.
The compiler
will recognize the Conflict_Check_Policy pragma, and will detect uses of
non-synchronized
global variables by parallel constructs.

Project size:
   This could be a medium or large project (175 or 350 hours), depending
on the applicant's familiarity with the GCC Ada front end (GNAT).

Difficulty:
   This would be of medium difficulty, as this is only enforcing
compile-time restrictions,
and has no effect on the generated code.

Expected Mentors:
   Tucker Taft and Richard Wai

Skills required:
   Basic understanding of compiler front-end syntax and static semantic
processing.
Experience with writing significant programs in Ada.  Ideally, some
familiarity with
the GCC Ada front end (GNAT).

Study materials:
   Documentation of the GCC Ada front end (GNAT) which is included within
the
Ada source code for critical packages.  The Ada 2022 Reference Manual.  The
textbook
"Programming in Ada 2022" (John Barnes).  A compiler textbook with good
coverage
of compiler front end structure, such as Appel's "Modern Compiler
Implementation".


On Tue, Feb 3, 2026 at 6:46 PM Martin Jambor <mjambor@suse.cz> wrote:

> Hello Tucker,
>
> On Tue, Jan 20 2026, 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
>
> this is great, but we need to have the list of project ideas ready by
> couple of hours ago.  Sorry that I am only replying now, I was ill and
> in bed the entire last week.
>
> In reality I hope that we still have a few (but really only few) days to
> add it.  Can you please write the project idea down and either directly
> enter it to the wiki or email it to me?
>
> I do need all the information described in points a - g below, but the
> actual description really only needs to be 5-2 sentences and most of the
> rest is even shorter.  Point h can be provided later but please think
> about it so that you have something when students start applying.
>
> Thanks a lot,
>
> Martin
>
>
> >
> > On Mon, Jan 19, 2026 at 10:11 AM Martin Jambor <mjambor@suse.cz> 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
> >>
>

Re: GCC GSoC 2026: Call for project ideas and mentors

[Martin Jambor]

Hi,


On Tue, Feb 03 2026, Tucker Taft wrote:
> Sorry, we missed out on this stage of the process last year, so I was
> unaware that you needed a concrete list of projects at this point.
>

I guess I should have been more clear about this.  A good project idea
list is an important criteria when Organisation applications are
evaluated so we need to have it (almost) ready by the application
deadline (which was yesterday).

> Below is the proposal.

Wonderful, thanks a lot, I have added it to our Summer of Code page.

Martin


>
> Sincerely,
> -Tucker Taft
>
> -----------------------------
>
> Project title: Compile-time data-race detection and global variable analysis
>
> Description:
>   Ada 2022 specifies a series of levels of checking for data races and
> global variable usage.
> We propose to implement the Global variable analysis specified in the Ada
> 2022 RM section 6.1.2,
> which checks that any use of global variables within a subprogram
> correspond to the usages
> specified by the "Global" aspect for the subprogram.  We also propose to
> implement the compile-time
> parallel conflict checking specified in section 9.10.1 as
> "All_Parallel_Conflict_Checks" which verifies
> that a parallel construct only reads or updates global variables that are
> "synchronized" objects.
>
> Expected outcome:
>   The compiler will recognize the Global aspect for subprograms, and detect
> uses
> of global variables that exceed the specification for a given subprogram.
> The compiler
> will recognize the Conflict_Check_Policy pragma, and will detect uses of
> non-synchronized
> global variables by parallel constructs.
>
> Project size:
>    This could be a medium or large project (175 or 350 hours), depending
> on the applicant's familiarity with the GCC Ada front end (GNAT).
>
> Difficulty:
>    This would be of medium difficulty, as this is only enforcing
> compile-time restrictions,
> and has no effect on the generated code.
>
> Expected Mentors:
>    Tucker Taft and Richard Wai
>
> Skills required:
>    Basic understanding of compiler front-end syntax and static semantic
> processing.
> Experience with writing significant programs in Ada.  Ideally, some
> familiarity with
> the GCC Ada front end (GNAT).
>
> Study materials:
>    Documentation of the GCC Ada front end (GNAT) which is included within
> the
> Ada source code for critical packages.  The Ada 2022 Reference Manual.  The
> textbook
> "Programming in Ada 2022" (John Barnes).  A compiler textbook with good
> coverage
> of compiler front end structure, such as Appel's "Modern Compiler
> Implementation".
>
>
> On Tue, Feb 3, 2026 at 6:46 PM Martin Jambor <mjambor@suse.cz> wrote:
>
>> Hello Tucker,
>>
>> On Tue, Jan 20 2026, 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
>>
>> this is great, but we need to have the list of project ideas ready by
>> couple of hours ago.  Sorry that I am only replying now, I was ill and
>> in bed the entire last week.
>>
>> In reality I hope that we still have a few (but really only few) days to
>> add it.  Can you please write the project idea down and either directly
>> enter it to the wiki or email it to me?
>>
>> I do need all the information described in points a - g below, but the
>> actual description really only needs to be 5-2 sentences and most of the
>> rest is even shorter.  Point h can be provided later but please think
>> about it so that you have something when students start applying.
>>
>> Thanks a lot,
>>
>> Martin
>>
>>
>> >
>> > On Mon, Jan 19, 2026 at 10:11 AM Martin Jambor <mjambor@suse.cz> 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
>> >>
>>

Re: GCC GSoC 2026: Call for project ideas and mentors

[Martin Jambor]

Hello everyone,

I am pleased that I can announce that we have been accepted to be a GSoC
mentoring organization also in 2026!.

This also means that students are now really starting to look at our
idea page and so if anyone wants to add a project, it is still possible
but we should not delay it much longer.  More information is in my call
for projects quoted below.

I have also re-generated invites for past mentors to join the current
GSoC year in the "GSoC dashboard."  Unfortunately it seems that if you
have "joined" before we accepted, it may not count and you have to do it
again.  Or so it seems from what I can see in the dashboard.  So please,
if you want to take part, have a look if you need to re-join.

Thanks to everyone who helped me with this so far. I am very happy that
we'll get another chance to attract new contributors again this year.

Martin


On Mon, Jan 19 2026, Martin Jambor 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

GCC GSoC 2026: Call for project ideas and mentors

[Basile Starynkevitch]

Hello all,

On the gcc@gcc.gnu.org mailing list (archived at https://gcc.gnu.org/pipermail/gcc/ ..) I read
several messages about GCC GSoC (google summer of code) 2026.

I (Basile Starynkevitch in France) am volunteering to mentor one project.

I am currently teaching Linux programming at https://www.greenup-academy.fr/
and no longer working at CEA (see www.cea.fr and https://arxiv.org/abs/1109.0779 ...)

My project idea is to develop some open source expert system to improve GCC static analysis techniques
(working at the Gimple level) for ad-hoc static source code analysis and improved warnings to check
project specific coding rules (e.g. like those inside Qt or GTK ....)

(I even have a few dozen thousands of C++ lines on github, see RefPerSys/RefPerSys there).

I might have some students interested by that idea. They all are using Linux systems.

I need to understand how to proceed further (the bureaucracy on transferring copyright to FSF 
may be very challenging in France or in Africa, since GreenUp academy engineering school have ties 
and official partners in Cameroun).

Thanks

-- 

Basile STARYNKEVITCH                    basile AT starynkevitch DOT net
8 rue de la Faïencerie                       http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                         https://github.com/bstarynk
France                                https://github.com/RefPerSys/RefPerSys
                  https://orcid.org/0000-0003-0908-5250