Re: [GSoC 2026] Enhance OpenACC support - Formal proposal draft
Hi Thomas, > > Once again, good improvements, thanks! > Thanks to you for your valuable time and comments! In the meantime, I’ll look at the bugs that I mention and start another thread if it’s needed. Thanks again, Best, Sebastian > >
Re: [GSoC 2026] Enhance OpenACC support - Formal proposal draft
Hi Sebastian! On 2026-03-30T23:24:02-0400, Sebastian Galindo wrote: > This is the next iteration of the proposal. > https://drive.google.com/file/d/1n0fHE8i7EtLMk9WiAY-uWJcefftWZydm/view?usp=sharing > > Let me know if you have comments. Once again, good improvements, thanks! I also confirm seeing your submission to the GSoC system. Grüße Thomas
Re: [GSoC 2026] Enhance OpenACC support - Formal proposal draft
Hi Thomas, hope you're doing well This is the next iteration of the proposal. https://drive.google.com/file/d/1n0fHE8i7EtLMk9WiAY-uWJcefftWZydm/view?usp=sharing Let me know if you have comments. Best, Sebastian
Re: [GSoC 2026] Enhance OpenACC support - Formal proposal draft
Hi Thomas, thanks for the input. However, just for consideration: I don't know if project sizes have any (deterministic) impact on how many GSoC slots Google allocates for GCC, and therefore project size (of this in combination with other projects) implicitly affects the chances that your project may or may not get selected. We can't tell... Yeah but, I mean, my primary intention is contributing (Hopefully get some mentoring from you guys!), if I do not get accepted, I'll contribute anyways and keep asking things if you don't mind... The GSoC is a huge help because I get mentoring somehow, but if isn't the case I'll look forward to contribute aswell. That does not mean that I'm assuming that if I'm not getting the GSoC proposal approved I'll take your time anyways, I know that you guys are really busy and I would not expect (even with the GSoC project) you to answer quickly and spend a lot of time on me. Just reading this proposal is a huge work, thanks for that :-) We're not judging here the reasons either way, but it's very useful to acknowledge this upfront, instead of bad surprises later on. No worries, it's ok Task 3. and assuming that making that one work for OpenACC isn't actually more complex than additionally coding up the simpler OpenACC requirements. We shall see. Good point, I was considering follow like the OpenMP path because the routine directive already maps to some OpenMP construct. But it could be a point to consider if it's more feasible implement OpenACC specific code as I see that the GIMPLE also have some oacc function attribute. At which point in the compilation pipeline might this be done? Consider the GCC offloading compilation flow. I would say in the middle end, when we are traversing the clause list in GIMPLE for the directives, we could know if the compilation is happening inside a offload device using the ACCEL_COMPILER variable, then we can drop the mismatching clauses. Look for a GCC feature, that is available in a generic form, and then expanded in back end-specific ways if supported, or otherwise ignored. Searching cache strategies with GCC I found https://gcc.gnu.org/projects/prefetch.html which mention the __builtin_prefetch function, it would be useful? In the article also mention that is only implemented by some back-ends. (..., and we may have to implement support in the GPU back end(s).) Are you referring to that by chance? Thanks for the input! I'll make the changes. Best, Sebastian
Re: [GSoC 2026] Enhance OpenACC support - Formal proposal draft
Hi Sebastian! On 2026-03-30T07:00:17-0400, Sebastian Galindo wrote: > Sorry for the delay, in the following link I uploaded the fixed draft of > the proposal. > https://drive.google.com/file/d/1n76zvxaZqSyv52KD6kq4fsehFOOoHZ_i/view?usp=sharing > > Looking forward to your comments! Thanks, good improvements in there! I suggest you submit this as soon as possible, so that we've got it in the system. You're then still able to update your submission. On 2026-03-27T13:11:22-0400, Sebastian Galindo wrote: >> Have you intentionally chosen to make this a 175 h (medium) project >> instead of a 350 h (large) one? Is the end date of 2026-08-16 fixed, or >> do we have some flexibility there, if needed? > > I was looking at the official GSoC timeline to have a reference, but I > understand that the project could extend till November or something like > that. I have a lot of flexibility in that sense, and I would be happy to > work on it for a longer period. > > According to that, do you think it would make more sense to define it as > a large project? I would be open to that. In that case, I would keep the > current tasks as the core goals, and extend the work to additional > OpenACC features depending on progress. That works for me; happy to get more stuff done. However, just for consideration: I don't know if project sizes have any (deterministic) impact on how many GSoC slots Google allocates for GCC, and therefore project size (of this in combination with other projects) implicitly affects the chances that your project may or may not get selected. We can't tell... If you choose to stay with "large", please update your 355 to 350 h. ;-) In that case, for consistency, in your "Project Timeline", in the enumeration please also include the "5. Newer OpenACC features", as you mention them in the "Period / Tasks / Est. hrs" table right after, and also in the text at the beginning of the document. As we're in the year 2026..., we'd appreciate some commentary added regarding AI/LLM usage in the project proposal. For example, some color coding scheme or descriptive text, so that it's clear to those reviewing the proposals, which parts of your application are entirely your own writing, or have been "heavily inspired" by AI/LLM usage, or been "filtered" through AI/LLM, or are entirely AI/LLM-generated. We're not judging here the reasons either way, but it's very useful to acknowledge this upfront, instead of bad surprises later on. (And please note that this request is not specific to your application. I acknowledge that you've already got a little bit on (non-)use of "AI" in "Project Timeline", regarding the implementation.) If you've still got time until the end of the proposal submission period: Task 3. Indeed the related OpenMP infrastructure is something to consider. ... even if we don't need all its complexity, and assuming that making that one work for OpenACC isn't actually more complex than additionally coding up the simpler OpenACC requirements. We shall see. Task 4. You're right that we'll have to carry around some linked-list or similar representation through the middle end passes. At some point in time, we'll have to resolve to one specific type (and its applicable clauses), and drop all the others (and the non-applicable clauses). At which point in the compilation pipeline might this be done? Consider the GCC offloading compilation flow. Task 2. Yes, the OpenMP features that you've listed may be worth considering in certain use cases. However, there is also some generic (non-OpenMP) GCC infrastructure that may be worth exploring, for requesting that data (such as array elements) be made available, because it'll soon be accessed (for example, in the next loop iteration). Look for a GCC feature, that is available in a generic form, and then expanded in back end-specific ways if supported, or otherwise ignored. (..., and we may have to implement support in the GPU back end(s).) Grüße Thomas
Re: [GSoC 2026] Enhance OpenACC support - Formal proposal draft
Hi, hope you're doing well! Sorry for the delay, in the following link I uploaded the fixed draft of the proposal. https://drive.google.com/file/d/1n76zvxaZqSyv52KD6kq4fsehFOOoHZ_i/view?usp=sharing Looking forward to your comments! Best, Sebastian Galindo
Re: [GSoC 2026] Enhance OpenACC support - Formal proposal draft
Hi Thomas, First of all, thanks for the review! Just for completeness, might note that OpenACC middle end handling is not only lowering/'gcc/omp-low.cc', but also other middle end code, and down to the GPU back ends. Some "C++" things are missing next to "C" ones that you mention. Also, 'libgomp/testsuite/' for runtime/execution test cases, including all code offloading testing. Ok, got it, thanks for the specification. I'm fine to have those as "stretch goals" in the proposal, and I agree to start with your Task 1, and then Task 3. Great, maybe I'll include explicitly that I want these tasks to be stretch goals. Which parts of GCC do we need to touch for Tasks 2, 3, 4: abstractly, and then in terms of GCC implementation (to the extent that you're already able to understand)? For Task 2, is there any existing non-OpenACC/OpenMP infrastructure in GCC that we may be able to build upon? Got it, I'll definitely include that, thanks! Have you intentionally chosen to make this a 175 h (medium) project instead of a 350 h (large) one? Is the end date of 2026-08-16 fixed, or do we have some flexibility there, if needed? I was looking at the official GSoC timeline to have a reference, but I understand that the project could extend till November or something like that. I have a lot of flexibility in that sense, and I would be happy to work on it for a longer period. According to that, do you think it would make more sense to define it as a large project? I would be open to that. In that case, I would keep the current tasks as the core goals, and extend the work to additional OpenACC features depending on progress. One concern I have is that, given the proposal deadline is close, I may not be able to like fully specify the newer OpenACC features implementation (Or yes?), maybe in a very abstract way. Thanks for the input! Best, Sebastian
Re: [GSoC 2026] Enhance OpenACC support - Formal proposal draft
Hi Sebastian! On 2026-03-26T20:45:46-0400, Sebastian Galindo wrote: > In the following link I'm sharing the first draft for GSoC 2026 proposal. > > https://drive.google.com/file/d/1Mui6Lej8y6o8J4Vaua94s5x3bSSl9mRD/view?usp=sharing Thanks! > Let me know your comments or which parts should I change. Just for completeness, might note that OpenACC middle end handling is not only lowering/'gcc/omp-low.cc', but also other middle end code, and down to the GPU back ends. Some "C++" things are missing next to "C" ones that you mention. Also, 'libgomp/testsuite/' for runtime/execution test cases, including all code offloading testing. I acknowledge that the OpenACC 'cache' directive, and OpenACC 'device_type' clause are more challenging than the other ones in your list. The good thing is that improvements/implementation can be done incrementally; I'm fine to have those as "stretch goals" in the proposal, and I agree to start with your Task 1, and then Task 3. You've explicitly chosen the OpenACC features listed on our GSoC project ideas page -- which is fine, of course, but in case there are any other OpenACC features (from later OpenACC standard versions, for example) that you'd like to look into, that's also possible. It'll be good to add some more detail, be a bit more specific, regarding the individual implementation tasks. What you currently have is mostly relevant for your Task 1 -- and, I suppose, mostly sourced from my text on the GSoC project ideas page. Which parts of GCC do we need to touch for Tasks 2, 3, 4: abstractly, and then in terms of GCC implementation (to the extent that you're already able to understand)? For Task 2, is there any existing non-OpenACC/OpenMP infrastructure in GCC that we may be able to build upon? Once you've got the remaining hurdle sorted out, please add a little bit of text to demonstrate that you're able to build GCC with GPU code offloading, and use that to compile and run a simple program with GPU code offloading execution. Run the program with 'GOMP_DEBUG=1', 'GCN_DEBUG=1' set in the environment, to produce debugging output, showing GPU kernel launches. I appreciate your desire to do some bug fixing etc. during the Community Bonding period. Please add some text about other time commitments that you may have during project execution. Have you intentionally chosen to make this a 175 h (medium) project instead of a 350 h (large) one? Is the end date of 2026-08-16 fixed, or do we have some flexibility there, if needed? > Or if I should switch the writing style or something like that. That's fine. Grüße Thomas
