Hi Sebastian! On 2026-03-30T07:00:17-0400, Sebastian Galindo <[email protected]> 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 <[email protected]> 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
