subject:"GSOC"

Hello,

I actually forgot to CC the mailing list as I promised to, so
re-sending.

Sorry,

Martin


On Sat, Mar 30 2024, Martin Jambor wrote:
> Hello,
>
> and sorry for replying late, I have faced a few urgent interruptions
> last week and unfortunately it is also a short week because of Easter -
> and so will be the upcoming one, I'm afraid, as Monday is also public
> holiday in many countries.
>
> Some comments are inline below.
>
> On Wed, Mar 27 2024, M Hamza Nadeem wrote:
>> Hi Martin,
>>
>> *Firstly* ,I have diligently followed the instructions provided in the
>> "Before you apply" section of the GCC GSoC page and successfully completed
>> the tasks outlined therein. I have built, installed, and tested GCC . I
>> have attached the screenshot of it below .
>> [image: gmail.png]
>>
>>  *Secondly*, I had Generated dumps of the Intermediate Representation of a
>> simple compiled program and stepped through some functions during
>> compilation using a debugger. I am studying  more deeply this concept at
>> https://www.geeksforgeeks.org/intermediate-code-generation-in-compiler-design/
>>  .
>>
>
> Thank you, that is important.
>
>> *Thirdly *, After conducting a thorough review of the available projects
>> listed on the GCC GSoC page, I have identified a project that aligns
>> closely with my interests and skill set. The project titled "Improve
>> nothrow Detection in GCC," under the mentorship of Jan Hubička,
>> particularly caught my attention.
>>
>> The prospect of extending the GCC middle-end to comprehend the semantics of
>> a __cxa_throw call and enable type-sensitive propagation of thrown
>> exceptions  I am particularly drawn to this project due to its intersection
>> with my academic background and professional interests.
>>
>> As __cxa_throw is a low-level function provided by the C/C++ ABI
>> (Application Binary Interface) used for throwing exceptions in C/C++
>> programs. It is typically implemented as part of the C/C++ runtime library.
>> This function is invoked when a throw statement is encountered in C/C++
>> code.
>>
>> Throughout my university studies, I have undertaken in-depth coursework in
>> Assembly language. This foundational knowledge has equipped me with a solid
>> understanding of low-level keywords , their significance within the context
>> of compiler design.
>>
>> Furthermore, my academic curriculum has provided me with a comprehensive
>> understanding of core programming concepts, including polymorphism,
>> inheritance, aggregation, data structures and Inter-process communication .
>> I have also gained practical experience in implementing these concepts
>> through various programming assignments and projects.
>>
>> I firmly believe that my academic background, coupled with my enthusiasm
>> for compiler technology  positions me well to contribute meaningfully to
>> the improvement of nothrow detection in GCC. With the guidance and
>> mentorship of experienced professionals ,  I am confident in my ability to
>> navigate the complexities of this project and propose effective solutions.
>>
>> *Fourthly *, As the deadline for submitting proposals for the GSoC 2024
>> program approaches rapidly, I am reaching out to seek your guidance on the
>> essential topics that should be addressed within my proposal for securing
>> an internship position within the GNU Compiler Collection (GCC).
>
> In a general form, it is all described here:
> https://gcc.gnu.org/wiki/SummerOfCode#Application
>
> More information about this project has been given for example at the
> end of https://gcc.gnu.org/pipermail/gcc/2024-March/243512.html (don't
> be confused by the subject, the thread discusses two projects).
>
> Which brings me to the point that , these questions should be directed
> to the mailing list (which I am CCing) where you can reach mentors and
> other people who know more about these things than me.
>
> Good luck,
>
> Martin
>
>
>>
>> Warm regards,
>> M Hamza Nadeem
>>
>> On Mon, Mar 25, 2024 at 9:54 PM M Hamza Nadeem 
>> wrote:
>>
>>> Thanks, I'll check them out.
>>>
>>> On Mon, 25 Mar 2024, 9:50 pm Martin Jambor,  wrote:
>>>
>>>> Hello,
>>>>
>>>> On Sun, Mar 24 2024, M Hamza Nadeem via Gcc wrote:
>>>> > Hi Sir / mam,
>>>> >
>>>> >
>>>> > I hope this email finds you well. As an enthusiastic contributor with a
>>>> > strong grasp of C/C++ and familiarity with Rust, I am e

Re: GSoC

Hello Abhinav,

sorry for a very brief answer, I'm not much online during Easter (the
timing of the application deadline is a bit unfortunate in this regard).

On Sat, Mar 30 2024, Abhinav Gupta wrote:
> Hello GCC community,
>  Since resuming work for the GSoC proposal recently, I have made
> significant progress in understanding the code snippets provided by
> Mr. Jambor and delved into the libgomp folder, compiling random
> snippets in the examples folder and reading the IR. Building GCC from
> source has also provided me with a deeper understanding of its inner
> workings.
> I've also looked at the GOMP_target_ext function and its
> implementations for both the existing targets as pointed out by Mr.
> Schwinge, these config folders have also given me an understanding of
> what is actually expected for this project, however I need some
> clarity regarding a few things-
>
> The GOMP_* functions calls for different targets: I need further
> assistance to understand how they should be implemented for the host
> machine, I am aware that this is exactly what the project is, I am
> just looking for a start point.

Look at functions with names starting with GOMP_OFFLOAD (such as
GOMP_OFFLOAD_run) in files in src/libgomp/plugin/*.c - those are the
things you'll need to implement but instead of setting up a GPU and
talking to AMD HSA or Nvidia CUDA you'll be setting up a new process and
communicating with it.

The entire list of functions that a plugin can have (probably not all
have to be implemented) is in struct gomp_device_descr in libgomp.h.

>
> Host Fallback Mode: I came across mentions of a host fallback mode in
> the offloading Wiki page and as you mentioned that there is already a
> oacc-host.c api. Could you please provide more clarity on whether this
> existing feature can be repurposed for offloading to a separate
> process on the same host? If not, could you elaborate on what exactly
> the host fallback mode is and how it differs from the proposed
> offloading mechanism?

Partially.  The host fallback means that, for one reason or another
(most commonly because the machine does not have any accelerators to
which it can offload), the OpenMP run time simply runs the target
regions on the CPU, almost as if it was not there (but there are
caveats, of course).

Which means that the outlined regions can be compiled basically as they
are for host fallback (though doing it with the same compiler will be
funny), on the GOMP side, things will need to look very differently.

I hope this helps,

Martin


>
> Thanking you
> Abhinav
>
> On Fri, 15 Mar 2024 at 03:54, Thomas Schwinge  wrote:
>>
>> Hi Abhinav!
>>
>> Thanks for your interest in contributing to GCC, and thanks to Martin for
>> all the information you already provided.  Just a bit more, to get you
>> started on developing a proper project proposal:
>>
>> On 2024-03-13T14:54:52+0100, Martin Jambor  wrote:
>> > On Tue, Mar 12 2024, Abhinav Gupta wrote:
>> >> I looked at all the links you provided in the reply and read the
>> >> paper cited on the GCC page for GSoC. I also looked into the rust
>> >> frontend project during this time, and the Offloading project
>> >> interests me more, so I will focus solely on it in the remaining seven
>> >> days before the deadline for GSoC application submission.
>> >
>> > AFAIU, in five days (from now) the application period *opens*, the
>> > deadline is 2nd April.  Still it is good idea not to lose any time.
>>
>> Indeed, no rush yet.  :-)
>>
>> >> Are there other resources I can look at to better understand the whole
>> >> process?
>>
>> At some point, no too late, you should spend some time on learning how to
>> build GCC, and run the test suite.
>> <https://gcc.gnu.org/wiki/SummerOfCode> and
>> <https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development> have
>> some pointers to get started.  If you have specific questions, we're
>> happy to help, of course.
>>
>> >> Reading the git commit on the website is proving to be very
>> >> slow.
>>
>> Yes, that's not going to be necessary.
>>
>> >> I think the git commit about Intel MIC would be like a
>> >> "template" in loose terms
>>
>> Right, that's in fact a very good description.  The idea here is not to
>> bring back the whole Intel MIC emulator, but something very much simpler.
>>
>> >> to implement the host-ISA mode at least, but
>> >> for the libgomp plugin, I need a better understanding.
>>
>> Find existing libgomp plugins as 'libgomp/plugin/pl

Re: Initial draft of GSOC proposal - Offloading to a separate process on the same host.

Hello,

On Wed, Mar 27 2024, Soumya Ranjan wrote:
> Hello!
> Thanks for your response Martin!
> Sorry for the late response, I've been researching the project, going over
> the source code and preparing the proposal. After a lot of thought, I've
> decided to go with the "Offloading to a separate process on the same host"
> project, mostly because I feel like I've reasonable background on this
> project, as I've worked on OpenMP, GPU Programming and have done coursework
> on compilers and operating systems. Yes, I am no longer a student. I
> recently graduated from the University of California, Irvine with a
> master's degree in Computer Engineering (About 3 months back) and I've
> recently joined Qualcomm as a firmware engineer. I realized that I have a
> lot of free time, that I mostly spend playing video games, and I've always
> wanted to get into open source development, so I thought this would be a
> good opportunity, given how much I use gcc for everything.
>

This sounds great.

First, please note that timing of the GSoC contributor application
deadline (on the upcoming Tuesday) is a bit unfortunate because of
Easter, many involved mentors have a long weekend (public holiday on
Friday or Monday or, like me, both).  So please even if you do not
receive any feedback, make sure to apply - and don't leave it until the
last day.  IIUC a proposal can be always updated later.

I'll have to admit that I read your proposal only quickly and it makes
sense.  I'd just like to point out that the VGPU part is really a second
(though perhaps much larger and interesting) part of the project, the
first part would be to simulate a CPU-like accelerator with a separate
memory.  But most of this work would be necessary for VGPU part too.
What is more, the VGPU part is likely to be hard, so if your time
constraints allow it and doing both is your goal, I'd suggest to apply
for an 350-hour (large) project.

I'll see if I can cough out any more feedback in time but as I wrote
above, generally it is good and don't wait - t least not with the
initial application.

Good luck!

Martin


> Why specifically this project -
> OpenMP's support for offloading to physical GPUs broadens the horizon for
> high-performance computing applications, the complexity of setting up such
> environments and the lack of adequate tooling for development and debugging
> can hinder productivity. The VGPU project directly addresses these
> challenges by providing a developer-friendly offloading target that
> emulates GPU execution on the host CPU, bridging the existing tooling gap
> and significantly enhancing developer productivity in the realm of parallel
> computing.
>
> Anyway, getting into the details of the project, from my understanding, the
> goals are -
> 1) To implement a virtual GPU (VGPU) environment that mirrors physical GPU
> architecture including support for different levels of parallelism (warp,
> thread block, etc.).
> 2) To enable the VGPU to serve as an offload target within the LLVM/OpenMP
> framework. This includes adding a host-ISA offloaded code generation mode
> that allows the compilation of OpenMP applications using GPU-specific paths
> and runtimes, facilitating a more accurate emulation of GPU environments.
> 3) To implement a plugin for libgomp that communicates with the libgomp
> offloading machinery to manage the execution of offloaded code in a new
> process, simulating the behavior of actual GPU devices.
> 4) To optimize the VGPU to ensure that OpenMP applications executed on it
> incur minimal performance overhead compared to native host execution,
> thereby making it a viable option for development and testing purposes.
>
> Here's a rough timeline (Based on the timeline on the gsoc website) -
> Pre-coding (Until May 27) -
> 1) Setting up a development environment including LLVM/OpenMP and necessary
> debugging tools.
> 2) Conducting thorough literature review on existing GPU simulation
> techniques and OpenMP offloading mechanisms.
>
> Week 1-3: Initial Infrastructure
> 1) Design VGPU architecture (simulate gpu parallel execution models (warps,
> blocks) and memory hierarchy (global, shared, private))
> 2) Implement the core vgpu infrastructure, like basic memory management.
>
> Week 4-6: Integration with LLVM/OpenMP and Host-ISA Offload Mode
> 1) Develop LLVM IR generation for VGPU target, thereby ensuring openMP
> directives can be compiled into vgpu-compatible code.
> 2) Add a new mode in the LLVM/OpenMP framework for generating offloaded
> code specifically for the VGPU target.
> 3) Get simple openMP applications to compile and execute on the VGPU.
>
> By Midterm evaluation, hopefully should have basic openmp applications
> offloaded on t

Re: GSoC 2024 [Fortran - DO CONCURRENT] Seeking feedback/suggestions for project proposal

Hello Anuj,

On Thu, Mar 28 2024, Anuj Mohite wrote:
> Hi,
> I'm Anuj M, an undergraduate student interested in participating in GSoC
> 2024 with GCC. I would like to work on the project improving the DO
> CONCURRENT construct in the GFortran compiler.The current implementation in
> GFortran has limitations in handling locality clauses, supporting reduction
> operations, and parallelization strategies for DO CONCURRENT loops. So the
> proposal aims to address these limitations:

timing of the GSoC contributor application deadline (on the upcoming
Tuesday) is a bit unfortunate because of Easter, many involved mentors
have a long weekend (public holiday on Friday or Monday or, like me,
both).  So please even if you do not receive any more feedback, make
sure to apply - and don't leave it until the last day.  IIUC a proposal
can be always updated later.

I admit that I managed to have only a very quick look at your proposal
but it all looked good to me.

Good luck!

Martin

>
>1. Implementing locality clauses and ensuring correct handling of data
>dependencies.
>2. Supporting reduction operations in DO CONCURRENT loops.
>3. Developing parallelization strategies, including OpenMP-based
>parallelization and OpenMP offloading.
>
> I have added a detailed project proposal outlining the implementation
> approach, timeline, my relevant background, and experience.
>
> I would greatly appreciate feedback or suggestions from the GCC community
> regarding this project proposal.
>
> Best regards,
> Anuj M
>
> ## GCC, the GNU Compiler Collection - Google Summer Of Code 24 Proposal -
> Anuj Mohite
>
> Project: Fortran - DO CONCURRENT
>
> Abstract:
>
> The `DO CONCURRENT` construct, introduced in the Fortran 2018 standard,
> provides a mechanism to express parallelism in Fortran programs. However,
> fully leveraging its potential requires a systematic and comprehensive
> implementation within Fortran compilers. This proposal outlines a robust
> solution for implementing `DO CONCURRENT` support, encompassing parsing and
> handling of locality clauses, enabling reduction operations, and developing
> parallelization strategies utilising OpenMP.
> To ensure efficient parallel execution, performance optimization techniques
> will be employed. By facilitating efficient parallelization of `DO
> CONCURRENT` loops, this project aims to contribute to Fortran's continued
> performance in high-performance computing domains, further enhancing its
> capabilities in this crucial area.
>
> Current State of Feature:
>
> At present, the support for the `DO CONCURRENT` construct in the GFortran
> compiler is limited. The existing implementation only partially handles the
> locality clauses introduced in the Fortran 2018 standard, and it lacks
> support for reduction operations and parallelization strategies. As a
> result, the performance gains achievable through the `DO CONCURRENT`
> construct are not fully realised.
>
> The current implementation in GFortran involves a basic parser for the `DO
> CONCURRENT` construct and its locality clauses. However, the semantic
> analysis and code generation phases are incomplete, leading to incorrect
> handling of data dependencies and potential race conditions. Additionally,
> the compiler does not support reduction operations or any parallelization
> strategies for `DO CONCURRENT` loops, effectively executing them in a
> serial manner.
>
> Other Fortran compilers, such as those from NVIDIA's nvfortran and Intel's
> ifort, have implemented varying levels of support for `DO CONCURRENT`.
> However, their implementations often have limitations or restrictions, and
> their performance can vary depending on the specific workload and hardware
> architecture.
>
> Furthermore, as the Fortran language continues to evolve, with the upcoming
> Fortran 202x standard introducing additional features and enhancements
> related to the `DO CONCURRENT` construct, it is crucial for compilers to
> stay up-to-date and provide comprehensive support for these language
> features.
> Project Goals
>
> The primary goals of this project are:
>
> 1. Implement Locality Clauses:
>
> * Extend the GFortran compiler to support locality clauses specified in the
> Fortran 2018 standard for the `DO CONCURRENT` construct.
> * Include parsing, semantic analysis, and code generation phases to handle
> specified data dependencies correctly.
> * Modify the compiler's parser to recognize new syntax for `DO CONCURRENT`
> loops and locality clauses, constructing an accurate AST.
> * Enhance semantic analysis phase to perform data dependency analysis,
> loop-carried dependency analysis, and alias analysis.
> * Resolve data dependenci

Re: GSoC

2024-03-30 Thread Abhinav Gupta via Gcc

Hello GCC community,
 Since resuming work for the GSoC proposal recently, I have made
significant progress in understanding the code snippets provided by
Mr. Jambor and delved into the libgomp folder, compiling random
snippets in the examples folder and reading the IR. Building GCC from
source has also provided me with a deeper understanding of its inner
workings.
I've also looked at the GOMP_target_ext function and its
implementations for both the existing targets as pointed out by Mr.
Schwinge, these config folders have also given me an understanding of
what is actually expected for this project, however I need some
clarity regarding a few things-

The GOMP_* functions calls for different targets: I need further
assistance to understand how they should be implemented for the host
machine, I am aware that this is exactly what the project is, I am
just looking for a start point.

Host Fallback Mode: I came across mentions of a host fallback mode in
the offloading Wiki page and as you mentioned that there is already a
oacc-host.c api. Could you please provide more clarity on whether this
existing feature can be repurposed for offloading to a separate
process on the same host? If not, could you elaborate on what exactly
the host fallback mode is and how it differs from the proposed
offloading mechanism?

Thanking you
Abhinav

On Fri, 15 Mar 2024 at 03:54, Thomas Schwinge  wrote:
>
> Hi Abhinav!
>
> Thanks for your interest in contributing to GCC, and thanks to Martin for
> all the information you already provided.  Just a bit more, to get you
> started on developing a proper project proposal:
>
> On 2024-03-13T14:54:52+0100, Martin Jambor  wrote:
> > On Tue, Mar 12 2024, Abhinav Gupta wrote:
> >> I looked at all the links you provided in the reply and read the
> >> paper cited on the GCC page for GSoC. I also looked into the rust
> >> frontend project during this time, and the Offloading project
> >> interests me more, so I will focus solely on it in the remaining seven
> >> days before the deadline for GSoC application submission.
> >
> > AFAIU, in five days (from now) the application period *opens*, the
> > deadline is 2nd April.  Still it is good idea not to lose any time.
>
> Indeed, no rush yet.  :-)
>
> >> Are there other resources I can look at to better understand the whole
> >> process?
>
> At some point, no too late, you should spend some time on learning how to
> build GCC, and run the test suite.
> <https://gcc.gnu.org/wiki/SummerOfCode> and
> <https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development> have
> some pointers to get started.  If you have specific questions, we're
> happy to help, of course.
>
> >> Reading the git commit on the website is proving to be very
> >> slow.
>
> Yes, that's not going to be necessary.
>
> >> I think the git commit about Intel MIC would be like a
> >> "template" in loose terms
>
> Right, that's in fact a very good description.  The idea here is not to
> bring back the whole Intel MIC emulator, but something very much simpler.
>
> >> to implement the host-ISA mode at least, but
> >> for the libgomp plugin, I need a better understanding.
>
> Find existing libgomp plugins as 'libgomp/plugin/plugin-*.c'.  The
> 'GOMP_OFFLOAD_[...]' functions implement the entry points, the offloading
> plugin API.  Actually also the very simple 'libgomp/oacc-host.c' should
> be helpful.  That's essentially the API you need to care about (for
> OpenACC; but OpenMP 'target' also won't require much more, for a start).
>
> Make some thoughts (or actual experiments) about how we could
> use/implement a separate host process for code offloading.
>
> And otherwise, as Martin said:
>
> > You need to understand how OpenMP programs are internally represented.
> >
> > Look at the following (hopefully correct, at least as long as you try it
> > on a system without any Offloading enabled) simple testcase for OpenMP
> > target construct:
> >
> > --
> > #include 
> >
> > volatile int v = 1;
> >
> > int main (int argc, char **argv)
> > {
> >   int i = v;
> >
> > #pragma omp target map(to:i)
> >   {
> > printf ("OpenMP target hello world, i is: %i\n", i);
> >   }
> >
> >   return 0;
> > }
> > --
> >
> > and compile it with:
> >
> >   gcc -fopenmp omptgt-hello.c -O2 -fdump-tree-optimized
> >
> > and then look at the ge

Re: GSoC Timeline Review

2024-03-30 Thread Nada Elsayed via Gcc

I think that I didn't fully understand the project, so I read more and
updated the Timeline Suggestion.

Suggested Timeline:

   -

   May 1-26:
   -

  Explore Cython modules and try more realistic codes to see how it
  translates Python to c/c++.
  -

  Know more about entry-points that Cython uses.
  -

  Understand common bugs that happen when converting Python to c/c++.



   -

   Explore static analysis tool for CPython Extension code -which is
   written in Python- and try this analyzer to understand the bugs in
   translated Python code fully.
   -

   Know how we can emit warnings and errors.



   -

   Debug the codebase to grasp its structure and potential areas for
   improvement.


   -

   Weeks 1-2:
   -

  Understand more about reference counting verification.
  -

  Develop verifying reference counts for PyObjects passed as parameters.
  -

   Weeks 3-4:
   -

  Begin to investigate Error Handling Checking.
  -

  Understand how the Static Analysis tool does Error Handling checking.
  -

  Implement these checks in the plugin.
  -

   Weeks 5-7:
   -

  Begin to investigate Exception Handling Checking.
  -

  Understand how the Static Analysis tool does Exception Handling
  checking.
  -

  Implement these checks in the plugin.
  -

   Weeks 8-11
   -

  Begin to investigate Format String Checking.
  -

  Understand how the Static Analysis tool does Format String Checking.
  -

  Implement these checks in the plugin.
  -

   Week 12
   -

  Writing the GSoC wrapping-up document.


‫في الأربعاء، 27 مارس 2024 في 2:31 ص تمت كتابة ما يلي بواسطة ‪Nada
Elsayed‬‏ <‪nadaelsayed...@gmail.com‬‏>:‬

> Greetings All,
> Hope this email finds you well.
> I am interested in "Extend the plugin to add checking for usage of the
> CPython API" project. First of all, I built the library, and now I am
> trying to debug it. Then, I also used Cpython in 3 demos to understand how
> it works. Finally, I read the uploaded patch comments to understand the
> codebase and file structure.
>
> I was wondering if you could review my suggested timeline?
> suggested Timeline:
>
>-
>
>May 1-26:
>-
>
>   Explore Cython modules, emphasizing entry-points and bug
>   identification.
>   -
>
>   Study analyzers, particularly cpy-analyzer, to enhance
>   understanding.
>   -
>
>   Debug the codebase to grasp its structure and potential areas for
>   improvement.
>   -
>
>   Focus investigation on "errors in GIL handling" and "tp_traverse
>   errors".
>   -
>
>Weeks 1-6:
>-
>
>   Investigate GIL (Global Interpreter Lock) errors extensively.
>   -
>
>   Engage in discussions and develop viable solutions to address
>   identified issues.
>
>
>
>-
>
>Weeks 7-12:
>-
>
>   Gain insight into the functioning of the Garbage Collector.
>   -
>
>   Implement checks to mitigate traverse errors effectively.
>   -
>
>   Ensure robust error handling mechanisms are in place through
>   thorough study and practical implementation.
>
>

"GSoC"

2024-03-29 Thread M Hamza Nadeem via Gcc

Hi Martin,

I wanted to write GSoC proposal on Improve nothrow Detection in GCC, . What
are the main points to be added in proposal ?

Initial draft of GSOC proposal - Offloading to a separate process on the same host.

2024-03-27 Thread Soumya Ranjan via Gcc

Hello!
Thanks for your response Martin!
Sorry for the late response, I've been researching the project, going over
the source code and preparing the proposal. After a lot of thought, I've
decided to go with the "Offloading to a separate process on the same host"
project, mostly because I feel like I've reasonable background on this
project, as I've worked on OpenMP, GPU Programming and have done coursework
on compilers and operating systems. Yes, I am no longer a student. I
recently graduated from the University of California, Irvine with a
master's degree in Computer Engineering (About 3 months back) and I've
recently joined Qualcomm as a firmware engineer. I realized that I have a
lot of free time, that I mostly spend playing video games, and I've always
wanted to get into open source development, so I thought this would be a
good opportunity, given how much I use gcc for everything.

Why specifically this project -
OpenMP's support for offloading to physical GPUs broadens the horizon for
high-performance computing applications, the complexity of setting up such
environments and the lack of adequate tooling for development and debugging
can hinder productivity. The VGPU project directly addresses these
challenges by providing a developer-friendly offloading target that
emulates GPU execution on the host CPU, bridging the existing tooling gap
and significantly enhancing developer productivity in the realm of parallel
computing.

Anyway, getting into the details of the project, from my understanding, the
goals are -
1) To implement a virtual GPU (VGPU) environment that mirrors physical GPU
architecture including support for different levels of parallelism (warp,
thread block, etc.).
2) To enable the VGPU to serve as an offload target within the LLVM/OpenMP
framework. This includes adding a host-ISA offloaded code generation mode
that allows the compilation of OpenMP applications using GPU-specific paths
and runtimes, facilitating a more accurate emulation of GPU environments.
3) To implement a plugin for libgomp that communicates with the libgomp
offloading machinery to manage the execution of offloaded code in a new
process, simulating the behavior of actual GPU devices.
4) To optimize the VGPU to ensure that OpenMP applications executed on it
incur minimal performance overhead compared to native host execution,
thereby making it a viable option for development and testing purposes.

Here's a rough timeline (Based on the timeline on the gsoc website) -
Pre-coding (Until May 27) -
1) Setting up a development environment including LLVM/OpenMP and necessary
debugging tools.
2) Conducting thorough literature review on existing GPU simulation
techniques and OpenMP offloading mechanisms.

Week 1-3: Initial Infrastructure
1) Design VGPU architecture (simulate gpu parallel execution models (warps,
blocks) and memory hierarchy (global, shared, private))
2) Implement the core vgpu infrastructure, like basic memory management.

Week 4-6: Integration with LLVM/OpenMP and Host-ISA Offload Mode
1) Develop LLVM IR generation for VGPU target, thereby ensuring openMP
directives can be compiled into vgpu-compatible code.
2) Add a new mode in the LLVM/OpenMP framework for generating offloaded
code specifically for the VGPU target.
3) Get simple openMP applications to compile and execute on the VGPU.

By Midterm evaluation, hopefully should have basic openmp applications
offloaded on the VGPU.

Week 7-9: Extending functionality and Implementing libgomp Plugin
1) Extend VGPU to support more functionality like loops, sections, parallel
blocks.
2) Implement a plug-in for libgomp that interfaces with its offloading
machinery.
3) Maybe look to integrate with debugging tools, so users can step through
offloaded regions and profile code.

Week 10-12: Evaluation and Final Submission
1) Benchmark against physical GPU's to evaluate the VGPU's performance.
2) Prepare a final project report documenting the development process,
challenges, results and future work.

I know this is a pretty high-level description, but I will try my best to
stick to this. This submission is mainly to go over the content. I would
appreciate any feedback I can get, and will make sure to submit a more
detailed description on my final submission. Awaiting your feedback.
Thanks,
Soumya Ranjan

GSoC 2024 [Fortran - DO CONCURRENT] Seeking feedback/suggestions for project proposal

2024-03-27 Thread Anuj Mohite via Gcc

Hi,
I'm Anuj M, an undergraduate student interested in participating in GSoC
2024 with GCC. I would like to work on the project improving the DO
CONCURRENT construct in the GFortran compiler.The current implementation in
GFortran has limitations in handling locality clauses, supporting reduction
operations, and parallelization strategies for DO CONCURRENT loops. So the
proposal aims to address these limitations:

   1. Implementing locality clauses and ensuring correct handling of data
   dependencies.
   2. Supporting reduction operations in DO CONCURRENT loops.
   3. Developing parallelization strategies, including OpenMP-based
   parallelization and OpenMP offloading.

I have added a detailed project proposal outlining the implementation
approach, timeline, my relevant background, and experience.

I would greatly appreciate feedback or suggestions from the GCC community
regarding this project proposal.

Best regards,
Anuj M

## GCC, the GNU Compiler Collection - Google Summer Of Code 24 Proposal -
Anuj Mohite

Project: Fortran - DO CONCURRENT

Abstract:

The `DO CONCURRENT` construct, introduced in the Fortran 2018 standard,
provides a mechanism to express parallelism in Fortran programs. However,
fully leveraging its potential requires a systematic and comprehensive
implementation within Fortran compilers. This proposal outlines a robust
solution for implementing `DO CONCURRENT` support, encompassing parsing and
handling of locality clauses, enabling reduction operations, and developing
parallelization strategies utilising OpenMP.
To ensure efficient parallel execution, performance optimization techniques
will be employed. By facilitating efficient parallelization of `DO
CONCURRENT` loops, this project aims to contribute to Fortran's continued
performance in high-performance computing domains, further enhancing its
capabilities in this crucial area.

Current State of Feature:

At present, the support for the `DO CONCURRENT` construct in the GFortran
compiler is limited. The existing implementation only partially handles the
locality clauses introduced in the Fortran 2018 standard, and it lacks
support for reduction operations and parallelization strategies. As a
result, the performance gains achievable through the `DO CONCURRENT`
construct are not fully realised.

The current implementation in GFortran involves a basic parser for the `DO
CONCURRENT` construct and its locality clauses. However, the semantic
analysis and code generation phases are incomplete, leading to incorrect
handling of data dependencies and potential race conditions. Additionally,
the compiler does not support reduction operations or any parallelization
strategies for `DO CONCURRENT` loops, effectively executing them in a
serial manner.

Other Fortran compilers, such as those from NVIDIA's nvfortran and Intel's
ifort, have implemented varying levels of support for `DO CONCURRENT`.
However, their implementations often have limitations or restrictions, and
their performance can vary depending on the specific workload and hardware
architecture.

Furthermore, as the Fortran language continues to evolve, with the upcoming
Fortran 202x standard introducing additional features and enhancements
related to the `DO CONCURRENT` construct, it is crucial for compilers to
stay up-to-date and provide comprehensive support for these language
features.
Project Goals

The primary goals of this project are:

1. Implement Locality Clauses:

* Extend the GFortran compiler to support locality clauses specified in the
Fortran 2018 standard for the `DO CONCURRENT` construct.
* Include parsing, semantic analysis, and code generation phases to handle
specified data dependencies correctly.
* Modify the compiler's parser to recognize new syntax for `DO CONCURRENT`
loops and locality clauses, constructing an accurate AST.
* Enhance semantic analysis phase to perform data dependency analysis,
loop-carried dependency analysis, and alias analysis.
* Resolve data dependencies and identify potential parallelization
opportunities.

2. Support Reduction Operations:

* add support for reduction operations in the `DO CONCURRENT` construct, as
introduced in the upcoming Fortran 202x standard.
* Involve parsing reduction clauses, semantic analysis for correctness, and
generating optimized code for parallel reduction operations.
* Extend the compiler's parser to recognize new syntax for reduction
clauses, constructing an accurate AST.
* Enhance semantic analysis phase to analyze reduction clauses and loop
body, identifying potential dependencies and ensuring correctness of
reduction operation.
* Employ techniques like data dependency analysis and alias analysis to
accurately identify variables involved in reduction operation and ensure
they are not modified outside reduction context.

3. Parallelize DO CONCURRENT Loops:

* Develop and integrate parallelization strategies for `DO CONCURRENT`
loops into the GFortran compiler.
* Include Op

GSoC Timeline Review

2024-03-26 Thread Nada Elsayed via Gcc

Greetings All,
Hope this email finds you well.
I am interested in "Extend the plugin to add checking for usage of the
CPython API" project. First of all, I built the library, and now I am
trying to debug it. Then, I also used Cpython in 3 demos to understand how
it works. Finally, I read the uploaded patch comments to understand the
codebase and file structure.

I was wondering if you could review my suggested timeline?
suggested Timeline:

   -

   May 1-26:
   -

  Explore Cython modules, emphasizing entry-points and bug
  identification.
  -

  Study analyzers, particularly cpy-analyzer, to enhance understanding.
  -

  Debug the codebase to grasp its structure and potential areas for
  improvement.
  -

  Focus investigation on "errors in GIL handling" and "tp_traverse
  errors".
  -

   Weeks 1-6:
   -

  Investigate GIL (Global Interpreter Lock) errors extensively.
  -

  Engage in discussions and develop viable solutions to address
  identified issues.



   -

   Weeks 7-12:
   -

  Gain insight into the functioning of the Garbage Collector.
  -

  Implement checks to mitigate traverse errors effectively.
  -

  Ensure robust error handling mechanisms are in place through thorough
  study and practical implementation.

Re: "GSoC"

2024-03-25 Thread M Hamza Nadeem via Gcc

Thanks, I'll check them out.

On Mon, 25 Mar 2024, 9:50 pm Martin Jambor,  wrote:

> Hello,
>
> On Sun, Mar 24 2024, M Hamza Nadeem via Gcc wrote:
> > Hi Sir / mam,
> >
> >
> > I hope this email finds you well. As an enthusiastic contributor with a
> > strong grasp of C/C++ and familiarity with Rust, I am eager to explore
> > potential projects for Google Summer of Code (GSoC) 2024 within the GNU
> > Compiler Collection (GCC) ecosystem.
>
> we are delighted you found the prospect of contributing to GCC interesting.
>
> >
> > With my background in these languages and my passion for advancing
> compiler
> > technology, I believe I could make significant contributions to various
> GCC
> > projects.
> >
> > I would greatly appreciate any guidance on how to proceed further with
> > project selection or any additional insights into the GCC projects
> relevant
> > to my skill set.
>
> Please look again at the "Before you apply" section of our GSoC page at
> https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you
> are
> able to build, install and test GCC.  I strongly suggest that you also try
> generating dumps of the IR of a simple compiled program and stepping
> through
> some function during compilation in a debugger.
>
> Afterwards, look at the suggested projects, try to identify the portion of
> GCC
> source where it needs to be implemented and think about how.  Then email us
> back to this mailing list describing your current plan together with any
> technical questions you'd like to have answered to proceed further.  We'll
> be
> happy to help.
>
> Good luck,
>
> Martin
>
>

Re: "GSoC"

2024-03-25 Thread Martin Jambor

Hello,

On Sun, Mar 24 2024, M Hamza Nadeem via Gcc wrote:
> Hi Sir / mam,
>
>
> I hope this email finds you well. As an enthusiastic contributor with a
> strong grasp of C/C++ and familiarity with Rust, I am eager to explore
> potential projects for Google Summer of Code (GSoC) 2024 within the GNU
> Compiler Collection (GCC) ecosystem.

we are delighted you found the prospect of contributing to GCC interesting.

>
> With my background in these languages and my passion for advancing compiler
> technology, I believe I could make significant contributions to various GCC
> projects.
>
> I would greatly appreciate any guidance on how to proceed further with
> project selection or any additional insights into the GCC projects relevant
> to my skill set.

Please look again at the "Before you apply" section of our GSoC page at
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you are
able to build, install and test GCC.  I strongly suggest that you also try
generating dumps of the IR of a simple compiled program and stepping through
some function during compilation in a debugger.

Afterwards, look at the suggested projects, try to identify the portion of GCC
source where it needs to be implemented and think about how.  Then email us
back to this mailing list describing your current plan together with any
technical questions you'd like to have answered to proceed further.  We'll be
happy to help.

Good luck,

Martin

Re: GSoC

2024-03-25 Thread Martin Jambor

On Sat, Mar 23 2024, koushiki khobare via Gcc wrote:
> Respected sir,
>
> I am Koushiki Khobare from India and currently a first year
> student(Computer Science Student) studying in Pune Institute of
> Computer Technology, Pune, Maharashtra. Recently I heard about GSoC
> and got very excited to explore it. I will be very much thankful to
> you if you provide me some guidance and help me to explore more. I
> have learnt C programming language. So I visited your projects and
> they were all amazing and quite interesting to work upon.

We are delighted you found contributing to GCC interesting.  

Please note that apart from C (and C++!) coding skills, most projects
require some rudimentary theoretical background in compilers.

> One of them
> I am thinking to explore is “Rust Front End”.So I will be grateful to
> work with all my mentors- Mr.Pierre-Emmaunel Patry, Mr. Philip Herron,
> Mr.Arthur Cohen, all being excellent in their works.

Please note that Rust-GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the gcc-rust team:

https://gcc-rust.zulipchat.com/

So you may want to reach out to them there as well.

> I will be so much
> of grateful if I get to know what actual skills do you expect from me
> apart from mentioned on website and guide me with what all do I need
> to do in my proposal.

The skills mentioned on the website
(i.e. https://gcc.gnu.org/wiki/SummerOfCode ) should be quite
sufficient.  I can only advise that you look at the "Before you apply"
section and take (most of) the steps described there.

> I request you to provide me some guidance with my proposal.

You need to select a particular project and make at least a few first
steps (again, at look at those described at
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply ) yourself.  Then
we can help you to polish things up.

Good luck!

Martin Jambor

Re: Interest in Contributing to OpenACC Support & Code Offloading Projects for GSOC

2024-03-25 Thread Martin Jambor

Hello,

On Thu, Mar 21 2024, Soumya Ranjan via Gcc wrote:
> Hello,
>
> I hope this message finds you well. My name is Soumya Ranjan, and I hold a
> Bachelor's degree in Electrical Engineering and a Master's in Computer
> Engineering. I am currently working as a Firmware Engineer at Qualcomm
> Wireless R&D. I recently discovered your organization and the exciting GSOC
> projects you are proposing, namely "Offloading to a separate process on the
> same host" and "Enhance OpenACC support." I am writing to express my
> enthusiastic interest in potentially contributing to either of these
> projects and to inquire about the next steps to formally apply or draft a
> proposal.

The above suggests you are no longer a full time student (but then your
email address indicates you might be :-) so I suppose you fulfill the
7.1.(a).iv clause of GSoC rules by being a "beginner to open source
software development."  If so, we are delighted that you decided to
start your FOSS journey with us.

>
> My academic journey was enriched with substantial coursework in operating
> systems and parallel computing, sparking a deep interest in efficient
> computational strategies and optimizations. My professional experience has
> further developed my skills in C/C++, offloading compilation, and
> inter-process communication. Given this foundation, I am confident in my
> capacity to make a meaningful contribution to either the project focused on
> enhancing debugging capabilities for offloaded code or the one aimed at
> filling the existing gaps in OpenACC support, depending on where my skills
> can be best utilized.
>
> I realize I am reaching out at a time when proposals are likely already
> underway. I apologize for this timing and am committed to diligently
> catching up. I've started to familiarize myself with the "Before You Apply"
> guidelines on your website to ensure I understand the necessary preparatory
> steps.
>
> Could you kindly advise if there are any additional specific steps I should
> follow or particular aspects of either project you would recommend focusing
> on in my proposal? The prospect of contributing to advancements in either
> domain is highly motivating to me, and I am keen to align my efforts with
> the project's most pressing needs.

The generic steps are listed in the "Before You Apply" guidelines. 

As far as the "Offloading to a separate process" project is concerned,
please have a look at a recent discussions in the mailing list archive,
specifically at
  - https://gcc.gnu.org/pipermail/gcc/2024-March/243462.html and
  - https://gcc.gnu.org/pipermail/gcc/2024-March/243478.html

As far as I can tell, the project on enhancing the OpenACC has not been
discussed yet.  I am not really familiar with OpenACC myself, so can
only give rudimentary advice.  First, I'd make sure that I know what the
routines/directives that need to be implemented do.  Second, I'd then
find some basic OpenACC testcase and do a similar experiment as
described in the email messages linked above (but perhaps with
-fdump-tree-all and not just -fdump-tree-optimize).  That should give
you an idea where to look next.  

Please feel free to ask here on the mailing list for help with any
specific technical issue or question you encounter.

> I am eager to learn more about how I can integrate into your team and
> contribute effectively. I believe this opportunity aligns perfectly with my
> professional aspirations and skills, and I am excited about the potential
> collaboration.

Given the timing, I'd focus on the proposal.  The key should be to
convince us that you have the ability to complete the project.
I.e. that you understand what needs to be done and have a rough idea - a
very rough but mostly correct idea - what and where needs to be changed
to do so.

Good luck!

Martin

>
> Thank you very much for considering my application. I look forward to the
> opportunity to further discuss how I can contribute to the success of your
> project.
>
> Warm regards,
> Soumya Ranjan

"GSoC"

2024-03-24 Thread M Hamza Nadeem via Gcc

Hi Sir / mam,


I hope this email finds you well. As an enthusiastic contributor with a
strong grasp of C/C++ and familiarity with Rust, I am eager to explore
potential projects for Google Summer of Code (GSoC) 2024 within the GNU
Compiler Collection (GCC) ecosystem.

With my background in these languages and my passion for advancing compiler
technology, I believe I could make significant contributions to various GCC
projects.

I would greatly appreciate any guidance on how to proceed further with
project selection or any additional insights into the GCC projects relevant
to my skill set.

Thank you for considering my interest, and I look forward to your response.

Warm regards,
M Hamza Nadeem

GSoC

2024-03-23 Thread koushiki khobare via Gcc

Respected sir,
  I am Koushiki Khobare from India and currently a first year 
student(Computer Science Student) studying in Pune Institute of Computer 
Technology, Pune, Maharashtra. Recently I heard about GSoC and got very excited 
to explore it. I will be very much thankful to you if you provide me some 
guidance and help me to explore more. I have learnt C programming language. So 
I visited your projects and they were all amazing and quite interesting to work 
upon. One of them I am thinking to explore is “Rust Front End”.So I will be 
grateful to work with all my mentors- Mr.Pierre-Emmaunel Patry, Mr. Philip 
Herron, Mr.Arthur Cohen, all being excellent in their works. I will be so much 
of grateful if I get to know what actual skills do you expect from me apart 
from mentioned on website and guide me with what all do I need to do in my 
proposal. I request you to provide me some guidance with my proposal.

Yours faithfully,
Koushiki Khobare

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

Interest in Contributing to OpenACC Support & Code Offloading Projects for GSOC

2024-03-21 Thread Soumya Ranjan via Gcc

Hello,

I hope this message finds you well. My name is Soumya Ranjan, and I hold a
Bachelor's degree in Electrical Engineering and a Master's in Computer
Engineering. I am currently working as a Firmware Engineer at Qualcomm
Wireless R&D. I recently discovered your organization and the exciting GSOC
projects you are proposing, namely "Offloading to a separate process on the
same host" and "Enhance OpenACC support." I am writing to express my
enthusiastic interest in potentially contributing to either of these
projects and to inquire about the next steps to formally apply or draft a
proposal.

My academic journey was enriched with substantial coursework in operating
systems and parallel computing, sparking a deep interest in efficient
computational strategies and optimizations. My professional experience has
further developed my skills in C/C++, offloading compilation, and
inter-process communication. Given this foundation, I am confident in my
capacity to make a meaningful contribution to either the project focused on
enhancing debugging capabilities for offloaded code or the one aimed at
filling the existing gaps in OpenACC support, depending on where my skills
can be best utilized.

I realize I am reaching out at a time when proposals are likely already
underway. I apologize for this timing and am committed to diligently
catching up. I've started to familiarize myself with the "Before You Apply"
guidelines on your website to ensure I understand the necessary preparatory
steps.

Could you kindly advise if there are any additional specific steps I should
follow or particular aspects of either project you would recommend focusing
on in my proposal? The prospect of contributing to advancements in either
domain is highly motivating to me, and I am keen to align my efforts with
the project's most pressing needs.

I am eager to learn more about how I can integrate into your team and
contribute effectively. I believe this opportunity aligns perfectly with my
professional aspirations and skills, and I am excited about the potential
collaboration.

Thank you very much for considering my application. I look forward to the
opportunity to further discuss how I can contribute to the success of your
project.

Warm regards,
Soumya Ranjan

Re: Interest in GSoC Project (offloading to a separate process on the same host)

2024-03-19 Thread Martin Jambor

Hello Pranil,

We are delighted you found contributing to GCC interesting.

On Fri, Mar 15 2024, PRANIL DEY via Gcc wrote:
> Hello GCC Community,
>
> I am Pranil Dey, a 4th year undergraduate student of the Indian Institute
> of Technology Kharagpur currently pursuing a Bachelor's Degree in Computer
> Science and Engineering. I am interested in contributing to the GCC
> projects under GSoC, specifically the projects : "Offloading to a separate
> process on the same host" and "Improve nothrow detection in GCC".
> I have worked on inter process communication in college operating systems
> projects which have helped me understand more about shared memory, pipes
> and multithreading concepts. I have also taken compiler design theory and
> laboratory courses as a part of my institute curriculum. In the lab we
> designed a Tiny-C compiler (a subset of GCC). Although I have no experience
> with big projects like GCC, I have built the codebase and am currently
> trying to understand it further.

Great, you seem to be very well prepared!

> I would like some pointers to start
> understanding and contributing to these projects along with any
> helpful resources/reading material for delving deeper into the relevant
> topic. Any guidance on proposal formulation will also be appreciated
> greatly.

As far as the offloading to a separate process project is concerned, we
have had a brief discussion on this mailing list in the recent past,
have a look especially at
https://gcc.gnu.org/pipermail/gcc/2024-March/243462.html and
https://gcc.gnu.org/pipermail/gcc/2024-March/243478.html

As far as the nothrow detection project is concerned, let me quote Honza
Hubička from an email which, probably by mistake, did not reach the
mailing list:

--
GCC EH works in a way that it marks statements that can possibly throw
(these can be calls or non-call exceptions) and assigns them to EH
regions.  EH regions are organized into a tree structure which describes
what types are caught and handled.

This data structure is in except.h / except.cc and can be dumped
before/after every pass (I believe iwth -fdump-tree-all-details)

For optimization we have two predicates - can_throw_internal and
can_throw_external which are used to detect notrhow functions and if
function is notrhow we can save EH tables and optimize EH hadnling code
(especialy EH cleanup regions calling implicit destructors that are
quite frequent).

What we miss the ability to track type of a given exception and detect
that given function handles all exceptions that it can possibly receive.
As a result such code leads to unnecesary cleanups later.

So the work is to make middle-end aware of it - is probably quite
easily detectable from calls to __cxa_throw which takes the type as
parameter.  Then we need to add propagation which will understand what
kind of exceptions are rethrown which will let us to deterine list of
all types possibly thrown by the function.

So I think good start is to look into the data-structure EH is
represented and look into detecting types of __cxa_throw.

The nothrow discovery currently lives in pure-const pass and is very
simple minded: if something in function apsses can_throw_external then
function can throw.  So in the next step the propgation will need to be
added here.
--

Hope this help, if you have any specific issues you'd like to help with,
certainly feel free to ask here again.

Good luck!

Martin Jambor

Interest in GSoC Project (offloading to a separate process on the same host)

2024-03-15 Thread PRANIL DEY via Gcc

Hello GCC Community,

I am Pranil Dey, a 4th year undergraduate student of the Indian Institute
of Technology Kharagpur currently pursuing a Bachelor's Degree in Computer
Science and Engineering. I am interested in contributing to the GCC
projects under GSoC, specifically the projects : "Offloading to a separate
process on the same host" and "Improve nothrow detection in GCC".
I have worked on inter process communication in college operating systems
projects which have helped me understand more about shared memory, pipes
and multithreading concepts. I have also taken compiler design theory and
laboratory courses as a part of my institute curriculum. In the lab we
designed a Tiny-C compiler (a subset of GCC). Although I have no experience
with big projects like GCC, I have built the codebase and am currently
trying to understand it further. I would like some pointers to start
understanding and contributing to these projects along with any
helpful resources/reading material for delving deeper into the relevant
topic. Any guidance on proposal formulation will also be appreciated
greatly.

Thank You,
--
Pranil Dey
Student of Indian Institute of Technology Kharagpur
Dept. of Computer Science and Engineering

Re: GSoC

2024-03-14 Thread Thomas Schwinge

Hi Abhinav!

Thanks for your interest in contributing to GCC, and thanks to Martin for
all the information you already provided.  Just a bit more, to get you
started on developing a proper project proposal:

On 2024-03-13T14:54:52+0100, Martin Jambor  wrote:
> On Tue, Mar 12 2024, Abhinav Gupta wrote:
>> I looked at all the links you provided in the reply and read the
>> paper cited on the GCC page for GSoC. I also looked into the rust
>> frontend project during this time, and the Offloading project
>> interests me more, so I will focus solely on it in the remaining seven
>> days before the deadline for GSoC application submission.
>
> AFAIU, in five days (from now) the application period *opens*, the
> deadline is 2nd April.  Still it is good idea not to lose any time.

Indeed, no rush yet.  :-)

>> Are there other resources I can look at to better understand the whole
>> process?

At some point, no too late, you should spend some time on learning how to
build GCC, and run the test suite.
<https://gcc.gnu.org/wiki/SummerOfCode> and
<https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development> have
some pointers to get started.  If you have specific questions, we're
happy to help, of course.

>> Reading the git commit on the website is proving to be very
>> slow.

Yes, that's not going to be necessary.

>> I think the git commit about Intel MIC would be like a
>> "template" in loose terms

Right, that's in fact a very good description.  The idea here is not to
bring back the whole Intel MIC emulator, but something very much simpler.

>> to implement the host-ISA mode at least, but
>> for the libgomp plugin, I need a better understanding.

Find existing libgomp plugins as 'libgomp/plugin/plugin-*.c'.  The
'GOMP_OFFLOAD_[...]' functions implement the entry points, the offloading
plugin API.  Actually also the very simple 'libgomp/oacc-host.c' should
be helpful.  That's essentially the API you need to care about (for
OpenACC; but OpenMP 'target' also won't require much more, for a start).

Make some thoughts (or actual experiments) about how we could
use/implement a separate host process for code offloading.

And otherwise, as Martin said:

> You need to understand how OpenMP programs are internally represented.
>
> Look at the following (hopefully correct, at least as long as you try it
> on a system without any Offloading enabled) simple testcase for OpenMP
> target construct:
>
> --
> #include 
>
> volatile int v = 1;
>
> int main (int argc, char **argv)
> {
>   int i = v;
>
> #pragma omp target map(to:i)
>   {
> printf ("OpenMP target hello world, i is: %i\n", i);
>   }
>
>   return 0;
> }
> --
>
> and compile it with:
>
>   gcc -fopenmp omptgt-hello.c -O2 -fdump-tree-optimized
>
> and then look at the generated optimized dump.  This should give you an
> idea how OpenMP regions are internally represented (as outlined
> functions) and how calls into libgomp, the run-time library doing a lot
> of the magic, look like.
>
> You can try to do more similar exercises with more OpenMP testcase which
> you can find in sub-directory libgomp/testsuite/libgomp.c of in the GCC
> repository.
>
> And then you should perhaps have a look into libgomp itself (you'll find
> it in libgomp sub-directory) how GOMP_target_ext is implemented - though
> don't worry if you don't understand many of the details, it is complex
> stuff.  At this point hopefully more of the contents of the Offloading
> wiki page will make sense.
>
> Again, ask on the mailing list if you have any specific questions.


Grüße
 Thomas


>> On Thu, 7 Mar 2024 at 20:37, Martin Jambor  wrote:
>>>
>>> Hello,
>>>
>>> On Wed, Mar 06 2024, Abhinav Gupta via Gcc wrote:
>>> > Dear GCC Community,
>>> > I hope this email finds you well. My name is Abhinav Gupta. I am a
>>> > 3rd-year student at IIT Tirupati pursuing a bachelor's degree in
>>> > computer science and engineering. I am writing to express my interest
>>> > in contributing to the GCC project under GSoC.
>>>
>>> We are very happy that you find contributing to GCC interesting.
>>>
>>> > I am interested in two projects - Offloading to a separate process on
>>> > the same host, I am already working in parallel computing,
>>> > specifically parallelising tensor algorithms using various techniques
>>> > as part of my research project at IIT Tirupati. Al

Re: GSoC

2024-03-13 Thread Martin Jambor

Hello,

On Tue, Mar 12 2024, Abhinav Gupta wrote:
> Hi! Thank you for replying to my request!
> I looked at all the links you provided in the reply and read the
> paper cited on the GCC page for GSoC. I also looked into the rust
> frontend project during this time, and the Offloading project
> interests me more, so I will focus solely on it in the remaining seven
> days before the deadline for GSoC application submission.

AFAIU, in five days (from now) the application period *opens*, the
deadline is 2nd April.  Still it is good idea not to lose any time.

> Are there other resources I can look at to better understand the whole
> process? Reading the git commit on the website is proving to be very
> slow. I think the git commit about Intel MIC would be like a
> "template" in loose terms to implement the host-ISA mode at least, but
> for the libgomp plugin, I need a better understanding.

You need to understand how OpenMP programs are internally represented.

Look at the following (hopefully correct, at least as long as you try it
on a system without any Offloading enabled) simple testcase for OpenMP
target construct:

--
#include 

volatile int v = 1;

int main (int argc, char **argv)
{
  int i = v;

#pragma omp target map(to:i)
  {
printf ("OpenMP target hello world, i is: %i\n", i);
  }

  return 0;
}
--

and compile it with:

  gcc -fopenmp omptgt-hello.c -O2 -fdump-tree-optimized

and then look at the generated optimized dump.  This should give you an
idea how OpenMP regions are internally represented (as outlined
functions) and how calls into libgomp, the run-time library doing a lot
of the magic, look like.

You can try to do more similar exercises with more OpenMP testcase which
you can find in sub-directory libgomp/testsuite/libgomp.c of in the GCC
repository.

And then you should perhaps have a look into libgomp itself (you'll find
it in libgomp sub-directory) how GOMP_target_ext is implemented - though
don't worry if you don't understand many of the details, it is complex
stuff.  At this point hopefully more of the contents of the Offloading
wiki page will make sense.

Again, ask on the mailing list if you have any specific questions.

Good luck,

Martin

> Thanking you
> Abhinav
>
>
> On Thu, 7 Mar 2024 at 20:37, Martin Jambor  wrote:
>>
>> Hello,
>>
>> On Wed, Mar 06 2024, Abhinav Gupta via Gcc wrote:
>> > Dear GCC Community,
>> > I hope this email finds you well. My name is Abhinav Gupta. I am a
>> > 3rd-year student at IIT Tirupati pursuing a bachelor's degree in
>> > computer science and engineering. I am writing to express my interest
>> > in contributing to the GCC project under GSoC.
>>
>> We are very happy that you find contributing to GCC interesting.
>>
>> > I am interested in two projects - Offloading to a separate process on
>> > the same host, I am already working in parallel computing,
>> > specifically parallelising tensor algorithms using various techniques
>> > as part of my research project at IIT Tirupati. Although this is not
>> > directly related to compilers, I will be able to get going with the
>> > project quickly.
>>
>> I'd personally very much like to see this project implemented.  There is
>> a lot of information on offloading at
>> https://gcc.gnu.org/wiki/Offloading
>>
>> To give you a bit more context where the idea comes from, it was first
>> thought of in email thread starting with
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603984.html and
>> the patch that was "scrubbed" from the email archive eventually became
>> commit
>> https://gcc.gnu.org/cgit/gcc/commit/?id=e4cba49413ca429dc82f6aa2e88129ecb3fdd943
>>
>> I hope these pointers will further help help you find out where to look
>> when planning the project.  If you need more help, please feel free to
>> ask (I'm CCing Thomas who then is perhaps best placed to answer).
>>
>> > The second project is Rust Front-End - both the BIR location support
>> > and rustc testsuite adapter are of interest to me,
>>
>> Please note that Rust-GCC projects are a bit special in the sense that
>> they are often discussed primarily on Zulip of the gcc-rust team:
>>
>> https://gcc-rust.zulipchat.com/
>>
>> So you may want to reach out to them there as well.
>>
>> > having worked on
>> > compiler front ends as part of my college's compiler design course
>> > combined with my experience in working with large libraries written in
>>

Re: About gsoc

2024-03-11 Thread Julian Waters via Gcc

Hello again, Dave. Have you managed to learn how a basic language
Interpreter works before commenting on the significantly-more-complex
gcc's efficiency? Or were you not able to because your IQ is below the
freezing point of water and you can't even understand what a basic
tree walker is?

Then again, with an address like killthe.net, why should we even take
you seriously? Hell, even though I miraculously agree that stuff like
GNU and Linux is not beginner friendly, and gcc could do with some
improvements in that department, no one wants to take any advice from
a self righteous and idiotic piece of shit like yourself. At least
Stefan was smart enough to bail when others pointed out the holes in
his examples of gcc's instruction selection allegedly being poor. You,
not so much. I doubt the clang people want you either, so do them a
favour and stay the hell away from LLVM, and this is coming from
someone who doesn't really like LLVM in the first place

Re: About gsoc

2024-03-11 Thread Mark Wielaard

Hi Dave,

On Sun, Mar 10, 2024 at 08:17:31PM -0500, Dave Blanchard wrote:
> > > On Tue, 5 Mar 2024 at 01:59, Dave Blanchard  wrote:
> > > > Wow, what a fucking prick this guy is.
> > > > [...]
> You are one of the biggest assholes I've encountered in the open
> source world, and I've met some real dicks.

You have been warned before. Please stop sending these negative
unproductive messages to this list attacking well respected productive
maintainers of the project. Your attitude is not welcome.

Thanks,

Mark

Re: About gsoc

2024-03-10 Thread Dave Blanchard

On Tue, 5 Mar 2024 09:32:26 +
Jonathan Wakely  wrote:

> On Tue, 5 Mar 2024 at 09:31, Jonathan Wakely  wrote:
> >
> > On Tue, 5 Mar 2024 at 01:59, Dave Blanchard  wrote:
> > >
> > > On Mon, 4 Mar 2024 10:06:34 +
> > > Jonathan Wakely via Gcc  wrote:
> > >
> > > > On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc 
> > > >  wrote:
> > > > >
> > > > > Hello sir/mam
> > > > > I am mokshagna reddy from Mahindra university and i am currently in 
> > > > > my second year of under graduation in Btech artificial intelligence i 
> > > > > had intrest in your organization and i know programming languages 
> > > > > like c, c++,python   how can i contribute from now and can u send 
> > > > > details about the project . Thank you hope i will get reply as soon 
> > > > > as possible.
> > > >
> > > > If you want to apply for GSoC and convince people you're a suitable
> > > > candidate and would invest the necessary time and effort, maybe you
> > > > should find details of the project for yourself instead of asking
> > > > others to provide them.
> > > >
> > > > A simple web search would have found 
> > > > https://gcc.gnu.org/wiki/SummerOfCode
> > >
> > > Wow, what a fucking prick this guy is.
> > >
> > > My apologies to our friend Mr. Mokshagna Reddy for this extreme rudeness.
> > >
> > > Maybe he did you a favor with such a response. Why should anyone waste 
> > > their time and energy donating free work to a dumpster fire project like 
> > > GCC, when this is the thanks you get? I recommend contributing your 
> > > valuable time to LLVM/clang or some other non-GNU project instead, where 
> > > it will likely be more appreciated.
> >
> > GSoC isn't free work, it's paid. Get a clue, or go away.

Oh, I see! Since this poor young university student might expect to receive 
small payment  for his time spent in improving GCC--which is a very complex 
project that is not easily modified--therefore you're excused in treating him 
like yesterday's trash.

Makes perfect sense to you, I guess.

> 
> That's directed at Dave, in case it wasn't obvious. He contributes
> nothing here except bile.

Have you read any of your own posts? You are one of the biggest assholes I've 
encountered in the open source world, and I've met some real dicks. People like 
you have been driving newbies away from Linux/BSD for decades. You never learn.

What you call "bile" is merely me being the one guy who's willing to call you 
on your bullshit. This is hardly the first time you've shown your ass to 
someone who was trying to help the GCC project in some way. Remember Stefan 
Kanthak? Others may remember he pointed out serious problems with the GCC 
optimizer on x86-32 which you also rudely dismissed, calling him a noob, etc.

Are you an official representative of the GCC project, or just some random 
asshole who lurks here and thinks he owns the place? What do YOU actually 
contribute to this list that is so valuable it excuses your rudeness? I wonder 
if Mr. Stallman approves of you helping to drive away potential GNU 
contributors, at a time when this project needs fresh blood arguably more than 
ever. Let's find out.

Dave

Re: GSoC

2024-03-07 Thread Martin Jambor

Hello,

On Wed, Mar 06 2024, Abhinav Gupta via Gcc wrote:
> Dear GCC Community,
> I hope this email finds you well. My name is Abhinav Gupta. I am a
> 3rd-year student at IIT Tirupati pursuing a bachelor's degree in
> computer science and engineering. I am writing to express my interest
> in contributing to the GCC project under GSoC.

We are very happy that you find contributing to GCC interesting.

> I am interested in two projects - Offloading to a separate process on
> the same host, I am already working in parallel computing,
> specifically parallelising tensor algorithms using various techniques
> as part of my research project at IIT Tirupati. Although this is not
> directly related to compilers, I will be able to get going with the
> project quickly.

I'd personally very much like to see this project implemented.  There is
a lot of information on offloading at
https://gcc.gnu.org/wiki/Offloading

To give you a bit more context where the idea comes from, it was first
thought of in email thread starting with
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603984.html and
the patch that was "scrubbed" from the email archive eventually became
commit
https://gcc.gnu.org/cgit/gcc/commit/?id=e4cba49413ca429dc82f6aa2e88129ecb3fdd943

I hope these pointers will further help help you find out where to look
when planning the project.  If you need more help, please feel free to
ask (I'm CCing Thomas who then is perhaps best placed to answer).

> The second project is Rust Front-End - both the BIR location support
> and rustc testsuite adapter are of interest to me,

Please note that Rust-GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the gcc-rust team:

https://gcc-rust.zulipchat.com/

So you may want to reach out to them there as well.

> having worked on
> compiler front ends as part of my college's compiler design course
> combined with my experience in working with large libraries written in
> C++ (such as CTF) I believe that these two projects are something that
> I can do.

You seem to be quite ready!

>
> Proposed Timeline:
> I can start working as soon as my end-semester exams finish, i.e. 9th
> May 2024, and continue to work for however long it requires me to
> complete the project.
> Week 1-2 -> Knowing the existing code and understanding how it works.

Right, but please try to do a bit of this, at least on the high level,
also now when preparing the proposal.  There will be lots to learn in
the first weeks even so.  Mainly because...

> Week 3-8 -> Working on the implementation of whichever project we
> decide to move forward with
> Week 9-12 -> Testing and creating understandable documentation for the same.
>
> This is a very rough timeline,

...eventually the milestones in the application will have to be more
specific, mainly to demonstrate you have basic understanding of the
proposed project.

> and I will refine it further as we
> discuss the project idea. This email is more of a call for guidance
> than an application, and I would appreciate any feedback you give me.

This is a very good start.

Good luck!

Martin

Re: About gsoc

2024-03-07 Thread Martin Jambor

Hello,

On Mon, Mar 04 2024, mokshagnareddyc--- via Gcc wrote:
> Hello sir/mam
> I am mokshagna reddy from Mahindra university and i am currently in my
> second year of under graduation in Btech artificial intelligence i had
> intrest in your organization and i know programming languages like c,
> c++,python how can i contribute from now and can u send details about
> the project.

We are delighted you found contributing to GCC interesting.

Please note that apart from C/C++ coding skills, most projects require
some rudimentary theoretical background in compilers.

Please look again at the "Before you apply" section of our GSoC page at
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you
are able to build, install and test GCC.  I strongly suggest that you
also try generating dumps of the IR of a simple compiled program and
stepping through some function during compilation in a debugger.

Afterwards, look at the suggested projects, try to identify the portion
of GCC source where it needs to be implemented and think about how.
Then email us back to this mailing list describing your current plan
together with any technical questions you'd like to have answered to
proceed further.  We'll be happy to help.

Good luck,

Martin

GSoC

2024-03-05 Thread Abhinav Gupta via Gcc

Dear GCC Community,
I hope this email finds you well. My name is Abhinav Gupta. I am a
3rd-year student at IIT Tirupati pursuing a bachelor's degree in
computer science and engineering. I am writing to express my interest
in contributing to the GCC project under GSoC.
I am interested in two projects - Offloading to a separate process on
the same host, I am already working in parallel computing,
specifically parallelising tensor algorithms using various techniques
as part of my research project at IIT Tirupati. Although this is not
directly related to compilers, I will be able to get going with the
project quickly.
The second project is Rust Front-End - both the BIR location support
and rustc testsuite adapter are of interest to me, having worked on
compiler front ends as part of my college's compiler design course
combined with my experience in working with large libraries written in
C++ (such as CTF) I believe that these two projects are something that
I can do.

Proposed Timeline:
I can start working as soon as my end-semester exams finish, i.e. 9th
May 2024, and continue to work for however long it requires me to
complete the project.
Week 1-2 -> Knowing the existing code and understanding how it works.
Week 3-8 -> Working on the implementation of whichever project we
decide to move forward with
Week 9-12 -> Testing and creating understandable documentation for the same.

This is a very rough timeline, and I will refine it further as we
discuss the project idea. This email is more of a call for guidance
than an application, and I would appreciate any feedback you give me.

 Best Regards,
Abhinav Gupta,
ph - +917289953000

Re: About gsoc

2024-03-05 Thread Jonathan Wakely via Gcc

On Tue, 5 Mar 2024 at 09:31, Jonathan Wakely  wrote:
>
> On Tue, 5 Mar 2024 at 01:59, Dave Blanchard  wrote:
> >
> > On Mon, 4 Mar 2024 10:06:34 +
> > Jonathan Wakely via Gcc  wrote:
> >
> > > On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc  
> > > wrote:
> > > >
> > > > Hello sir/mam
> > > > I am mokshagna reddy from Mahindra university and i am currently in my 
> > > > second year of under graduation in Btech artificial intelligence i had 
> > > > intrest in your organization and i know programming languages like c, 
> > > > c++,python   how can i contribute from now and can u send details about 
> > > > the project . Thank you hope i will get reply as soon as possible.
> > >
> > > If you want to apply for GSoC and convince people you're a suitable
> > > candidate and would invest the necessary time and effort, maybe you
> > > should find details of the project for yourself instead of asking
> > > others to provide them.
> > >
> > > A simple web search would have found https://gcc.gnu.org/wiki/SummerOfCode
> >
> > Wow, what a fucking prick this guy is.
> >
> > My apologies to our friend Mr. Mokshagna Reddy for this extreme rudeness.
> >
> > Maybe he did you a favor with such a response. Why should anyone waste 
> > their time and energy donating free work to a dumpster fire project like 
> > GCC, when this is the thanks you get? I recommend contributing your 
> > valuable time to LLVM/clang or some other non-GNU project instead, where it 
> > will likely be more appreciated.
>
> GSoC isn't free work, it's paid. Get a clue, or go away.

That's directed at Dave, in case it wasn't obvious. He contributes
nothing here except bile.

Re: About gsoc

2024-03-05 Thread Jonathan Wakely via Gcc

On Tue, 5 Mar 2024 at 01:59, Dave Blanchard  wrote:
>
> On Mon, 4 Mar 2024 10:06:34 +
> Jonathan Wakely via Gcc  wrote:
>
> > On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc  
> > wrote:
> > >
> > > Hello sir/mam
> > > I am mokshagna reddy from Mahindra university and i am currently in my 
> > > second year of under graduation in Btech artificial intelligence i had 
> > > intrest in your organization and i know programming languages like c, 
> > > c++,python   how can i contribute from now and can u send details about 
> > > the project . Thank you hope i will get reply as soon as possible.
> >
> > If you want to apply for GSoC and convince people you're a suitable
> > candidate and would invest the necessary time and effort, maybe you
> > should find details of the project for yourself instead of asking
> > others to provide them.
> >
> > A simple web search would have found https://gcc.gnu.org/wiki/SummerOfCode
>
> Wow, what a fucking prick this guy is.
>
> My apologies to our friend Mr. Mokshagna Reddy for this extreme rudeness.
>
> Maybe he did you a favor with such a response. Why should anyone waste their 
> time and energy donating free work to a dumpster fire project like GCC, when 
> this is the thanks you get? I recommend contributing your valuable time to 
> LLVM/clang or some other non-GNU project instead, where it will likely be 
> more appreciated.

GSoC isn't free work, it's paid. Get a clue, or go away.

Re: About gsoc

2024-03-04 Thread Dave Blanchard

On Mon, 4 Mar 2024 10:06:34 +
Jonathan Wakely via Gcc  wrote:

> On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc  
> wrote:
> >
> > Hello sir/mam
> > I am mokshagna reddy from Mahindra university and i am currently in my 
> > second year of under graduation in Btech artificial intelligence i had 
> > intrest in your organization and i know programming languages like c, 
> > c++,python   how can i contribute from now and can u send details about the 
> > project . Thank you hope i will get reply as soon as possible.
> 
> If you want to apply for GSoC and convince people you're a suitable
> candidate and would invest the necessary time and effort, maybe you
> should find details of the project for yourself instead of asking
> others to provide them.
> 
> A simple web search would have found https://gcc.gnu.org/wiki/SummerOfCode

Wow, what a fucking prick this guy is.

My apologies to our friend Mr. Mokshagna Reddy for this extreme rudeness. 

Maybe he did you a favor with such a response. Why should anyone waste their 
time and energy donating free work to a dumpster fire project like GCC, when 
this is the thanks you get? I recommend contributing your valuable time to 
LLVM/clang or some other non-GNU project instead, where it will likely be more 
appreciated.

Dave

Re: [GSoC][Improve nothrow detection]: Suggestions to get started

2024-03-04 Thread Ken Matsui via Gcc

Ping for [GSoC][Improve nothrow detection]: Suggestions to get started.

Could you please take a look when you get a chance?

Sincerely,
Ken Matsui

On Wed, Feb 28, 2024 at 8:00 AM Ken Matsui  wrote:
>
> Hi Jan,
>
> My name is Ken Matsui.  I am highly interested in contributing to your
> GSoC 2024 project idea, "Improve nothrow detection in GCC."  To get
> started with understanding your project (and, if possible, making
> small patches), could you please give me some suggestions on what
> files to read (and edit) and what to do first?
>
> Thank you for your help!
>
> Sincerely,
> Ken Matsui

Re: About gsoc

2024-03-04 Thread Jonathan Wakely via Gcc

On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc  wrote:
>
> Hello sir/mam
> I am mokshagna reddy from Mahindra university and i am currently in my second 
> year of under graduation in Btech artificial intelligence i had intrest in 
> your organization and i know programming languages like c, c++,python   how 
> can i contribute from now and can u send details about the project . Thank 
> you hope i will get reply as soon as possible.

If you want to apply for GSoC and convince people you're a suitable
candidate and would invest the necessary time and effort, maybe you
should find details of the project for yourself instead of asking
others to provide them.

A simple web search would have found https://gcc.gnu.org/wiki/SummerOfCode

About gsoc

2024-03-03 Thread mokshagnareddyc--- via Gcc

Hello sir/mam
I am mokshagna reddy from Mahindra university and i am currently in my second 
year of under graduation in Btech artificial intelligence i had intrest in your 
organization and i know programming languages like c, c++,python   how can i 
contribute from now and can u send details about the project . Thank you hope i 
will get reply as soon as possible.
Sent from my iPhone

Re: GSoC 2024 Expression of interes

Hello,

On Wed, Feb 28 2024, Aditya Ballaki via Gcc wrote:
> Hi Team,
>
> I'm an incoming graduate student in Computer Engineering at Cornell
> University, and I'm keen on participating in GSOC by contributing to
> open-source projects before starting my graduate program.

Wonderful, welcome!

> Specifically, I'm interested in working on the Rust GCC compiler.

Please note that Rust-GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the gcc-rust team:

https://gcc-rust.zulipchat.com/

So you may want to reach out to gcc-rust developers there there as well.

> While I haven't made direct open-source contributions before, I'm
> quite familiar with Rust. I've also gained experience with C/C++
> through various projects involving low-level hardware programming and
> video game development. Moreover, I've worked with several other tech
> stacks and production-level code during my internships and research
> endeavours.
>
> Please let me know if it's appropriate for me to reach out to any of
> the listed mentors (Pierre-Emmanuel Patry, Philip Herron, Arthur
> Cohen) to discuss the project further.

It is, but I'd primarily suggest the zulip link given above.

Good luck!

Martin

Re: GSOC

Hello,

On Tue, Feb 27 2024, Pratush Rai via Gcc wrote:
> I want to work on the Rust Front End project as per the idea list. I am a
> rust compiler contributor and want to start contributing to gcc.
> I need some guidance on how to start.

Please note that Rust-GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the gcc-rust team:

https://gcc-rust.zulipchat.com/

So you may want to reach out to gcc-rust developers there there as well.

Apart from this, I can only point you to
https://gcc.gnu.org/wiki/SummerOfCode and specifically to
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply which explains
some of the steps you can take to familiarize yourself with our code
base.

Good luck!

Martin Jambor

Re: Participation In GSoC 2024

Hello,

On Fri, Feb 23 2024, Mohd Kashif via Gcc wrote:
> Hey Sir/Madam,
> I want to participate in gsoc 2024 but I don't have any experience in it.
> Please be my mentor in this and help me to deliver the best project from my
> side .

We are delighted you found contributing to GCC interesting.  Please have
a look at https://gcc.gnu.org/wiki/SummerOfCode and specifically at
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply which explains
some of the steps you can take to familiarize yourself with our code
base and other initial steps to take.

Good luck,

Martin Jambor

Re: Contributor to the GSoC of 2024

Hello,

On Thu, Feb 22 2024, Suraj Kadapa via Gcc wrote:
> Hello,
>
> I am an undergraduate student with an extensive experience in computers
> from an early age, but most of my work has been limited to arduinos, and
> raspberry pi's. I have been intrigued with compilers, architecture and low
> level programming in the past few years. I have experience with ARM
> assembly and a little bit of x86 too. I have worked towards building
> bootloaders and teaching it to my fellow peers too. I've constructed a
> process virtual machine modeled after the LC-3 architecture and am
> presently focused on developing a basic emulator for RISC-V. Both of the
> previously mentioned projects are being done in C, and I have extensive
> experience in C. I really want to know how the GNU Compiler collection
> works under the hood and this is a really good opportunity for me to
> explore and learn.

We are delighted you found contributing to GCC interesting.  The above
is impressive but you may want to also look into some rudimentary
theoretical background in the area of compilers and compiler
optimizations, at least you need to understand the term "intermediate
representation" (IR) - sometimes also called "intermediate language"
(IL).  Most of GCC is written in C++, but that should not be an obstacle
for an experienced C programmer.

>
> Please reach out to me on what needs to be done to be accepted as a
> contributor to the GSoC program under the GNU organization,

The first steps are described in the "Before you apply" section of the
GSoC wiki page: https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply

> I would love to
> work on any of the projects mentioned in the wiki(would prefer some easy
> ones though, since I am not that deep yet).

Well, you will have to be the one to pick one.  Given your interests,
I'd recommend looking at "Offloading to a separate process on the same
host" and (recently added) "Implement structured dumping of GENERIC."
But don't let me discourage you looking at Fortran or any of the others
if you think that could be your thing.

>
> My github will be linked below, and I hope to hear from you soon!
> https://github.com/surajkadapa
>
> This is my first time writing for the GSoC program, so I am not really sure
> if this is how you reach out to organizations in this capacity. Please
> excuse any potential oversights as I navigate this process.
>

So far you have done the right thing.  Build GCC from source, try to
make some sense out of the source on the high level, pick a projet and
start thinking what parts would need changing and roughly how to
implement. If you have specific questions with the above, feel free to
ask on this mailing list or on IRC.

Good luck!

Martin

Re: getting start with GSoC

Hello,

On Fri, Feb 16 2024, Nada Elsayed via Gcc wrote:
> Hello All,
> I am Nada Elsayed, A fresh graduate from computer engineering at Cairo
> University.

welcome, we are delighted you found contributing to GCC interesting.

> I have good knowledge in C/C++, and a basic knowledge in compilers. als I
> am interested in contributing to the GCC this year; I am interested in 
> "*Extend
> the static analysis pass" *projects

Any particular one?

> or "*Improve nothrow detection in GCC" project*.*
>
> Till now I have built the code and I am trying to understand it more.

Good, this is the all-important first step.

> So what should I do now?

"Trying to understand it more" is exactly the correct thing to.  You
also need to locate which of the bits within GCC are relevant to the
project(s) you are interested in and start thinking what and where needs
to be changed in order to implement it.

If you have specific questions as you go about it, feel free to ask on
this mailing list or on IRC.

> Also, are bugs in https://gcc.gnu.org/wiki/EasyHacks good
> beginning or not?

The page itself is unfortunately very outdated.  However, the link to
the bugzilla search near its top might still be useful.

While it definitely helps, we do not strictly require applicants to do
any "easy hacks" or patch submissions prior to application.  The main
reason is that there are not as many opportunities for truly easy fixes
and improvements as other projects might have.  Still, feel free to
pursue one, it can only help!

Good luck!

Martin

[GSoC][Improve nothrow detection]: Suggestions to get started

2024-02-28 Thread Ken Matsui via Gcc

Hi Jan,

My name is Ken Matsui.  I am highly interested in contributing to your
GSoC 2024 project idea, "Improve nothrow detection in GCC."  To get
started with understanding your project (and, if possible, making
small patches), could you please give me some suggestions on what
files to read (and edit) and what to do first?

Thank you for your help!

Sincerely,
Ken Matsui

GSoC 2024 Expression of interes

2024-02-27 Thread Aditya Ballaki via Gcc

Hi Team,

I'm an incoming graduate student in Computer Engineering at Cornell
University, and I'm keen on participating in GSOC by contributing to
open-source projects before starting my graduate program.
Specifically, I'm interested in working on the Rust GCC compiler.
While I haven't made direct open-source contributions before, I'm
quite familiar with Rust. I've also gained experience with C/C++
through various projects involving low-level hardware programming and
video game development. Moreover, I've worked with several other tech
stacks and production-level code during my internships and research
endeavours.

Please let me know if it's appropriate for me to reach out to any of
the listed mentors (Pierre-Emmanuel Patry, Philip Herron, Arthur
Cohen) to discuss the project further.

Thank you!

Regards,
Aditya

P.S: Re-sent email with the correct string 'GSoC' in the subject line

GSOC 2024 Expression of interest

2024-02-27 Thread Aditya Ballaki via Gcc


Hi Team,
I'm an incoming graduate student in Computer Engineering at Cornell University, 
and I'm keen on participating in GSOC by contributing to open-source projects 
before starting my graduate program. Specifically, I'm interested in working on 
the Rust GCC compiler. While I haven't made direct open-source contributions 
before, I'm quite familiar with Rust. I've also gained experience with C/C++ 
through various projects involving low-level hardware programming and video 
game development. Moreover, I've worked with several other tech stacks and 
production-level code during my internships and research endeavours.

Please let me know if it's appropriate for me to reach out to any of the listed 
mentors (Pierre-Emmanuel Patry, Philip Herron, Arthur Cohen) to discuss the 
project further.

Thank you!

Regards,
Aditya 

smime.p7s
Description: S/MIME cryptographic signature

GSOC

2024-02-26 Thread Pratush Rai via Gcc

I want to work on the Rust Front End project as per the idea list. I am a
rust compiler contributor and want to start contributing to gcc.
I need some guidance on how to start.
Thank you,
Pratush

Interest in Participating in GSOC 2024 with GCC Organization

2024-02-26 Thread Pranith via Gcc

Dear Sir,

I hope this email finds you well. My name is Pranith, and I am writing to
express my keen interest in participating in the Google Summer of Code
(GSOC24) program with the GCC organization. As a newcomer to the field, I
am eager to learn and contribute to meaningful projects within the GCC
community related to compilers.

While I am relatively new to the world of open-source development, I am
enthusiastic about expanding my knowledge and honing my skills,
particularly in C++.

I am reaching out to inquire about potential projects that would be
suitable for someone with my level of experience and expertise. Could you
please provide guidance on which projects would be best suited for a
newcomer like myself? Additionally, I would greatly appreciate any advice
on how to proceed with selecting and contributing to a project within the
GCC organization.

I am committed to dedicating the time and effort necessary to succeed in
this program, and I am eager to make valuable contributions to the GCC
community. I am confident that my passion for learning and my determination
to excel will enable me to thrive in this opportunity.

Thank you for considering my application. I look forward to your guidance
and the possibility of working together to achieve our mutual goals.

Warm regards,

Beeram Pranith Reddy

Participation In GSoC 2024

2024-02-23 Thread Mohd Kashif via Gcc

Hey Sir/Madam,
I want to participate in gsoc 2024 but I don't have any experience in it.
Please be my mentor in this and help me to deliver the best project from my
side .
Thank You
(MOHD KASHIF)

GCC has been accepted as GSoC 2024 mentoring organization

2024-02-22 Thread Martin Jambor

Hello everyone,

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

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.

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

Martin



On Mon, Jan 15 2024, Martin Jambor wrote:
> Hello,
>
> another year has passed, Google has announced there will be again Google
> Summer of Code (GsoC) in 2024 and the deadline for organizations to
> apply is already approaching (February 6th).  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 David Edelsohn and Thomas Schwinge 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.  I'm 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 the 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) skills required/preferred,
>   e) project size - whether it is expected to take approximately 350,
>  175 or just 90 hours (the last option in new in 2024, see below),
>   f) difficulty (easy, hard or medium, but we don't really have easy
>  projects), and
>   g) expected mentors.
>
> 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.
>
> As far as I know, GSoC 2024 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 is new this year but because our projects
> usually have a lengthy learning period, I think we will usually 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 2024:
> 
> https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html
>
>   - GSoC rules:
> https://summerofcode.withgoogle.com/rules
>
>   - The detailed GSoC 2024 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

Contributor to the GSoC of 2024

2024-02-21 Thread Suraj Kadapa via Gcc

Hello,

I am an undergraduate student with an extensive experience in computers
from an early age, but most of my work has been limited to arduinos, and
raspberry pi's. I have been intrigued with compilers, architecture and low
level programming in the past few years. I have experience with ARM
assembly and a little bit of x86 too. I have worked towards building
bootloaders and teaching it to my fellow peers too. I've constructed a
process virtual machine modeled after the LC-3 architecture and am
presently focused on developing a basic emulator for RISC-V. Both of the
previously mentioned projects are being done in C, and I have extensive
experience in C. I really want to know how the GNU Compiler collection
works under the hood and this is a really good opportunity for me to
explore and learn.

Please reach out to me on what needs to be done to be accepted as a
contributor to the GSoC program under the GNU organization, I would love to
work on any of the projects mentioned in the wiki(would prefer some easy
ones though, since I am not that deep yet).

My github will be linked below, and I hope to hear from you soon!
https://github.com/surajkadapa

This is my first time writing for the GSoC program, so I am not really sure
if this is how you reach out to organizations in this capacity. Please
excuse any potential oversights as I navigate this process.

Regards,
Suraj

getting start with GSoC

2024-02-16 Thread Nada Elsayed via Gcc

Hello All,
I am Nada Elsayed, A fresh graduate from computer engineering at Cairo
University.
I have good knowledge in C/C++, and a basic knowledge in compilers. als I
am interested in contributing to the GCC this year; I am interested in "*Extend
the static analysis pass" *projects or "*Improve nothrow detection in GCC" *
project*.*

Till now I have built the code and I am trying to understand it more. So
what should I do now? Also, are bugs in https://gcc.gnu.org/wiki/EasyHacks good
beginning or not?

Regards,
Nada Elsayed

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

2024-02-02 Thread Martin Jambor

Hello,

this is just a reminder that the organization application period of GSoC
2024 closes on Tuesday February 6th (6pm UTC).  We have already applied
but that is when we are expected to have our project idea list basically
ready.  So please review old ideas and if you have a new one and/or
would like to be a mentor, please speak up.

Thanks,

Martin


On Mon, Jan 15 2024, Martin Jambor wrote:
[...]
>  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.  I'm 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 the 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) skills required/preferred,
>   e) project size - whether it is expected to take approximately 350,
>  175 or just 90 hours (the last option in new in 2024, see below),
>   f) difficulty (easy, hard or medium, but we don't really have easy
>  projects), and
>   g) expected mentors.
>
> 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.
>
> As far as I know, GSoC 2024 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 is new this year but because our projects
> usually have a lengthy learning period, I think we will usually 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 2024:
> 
> https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html
>
>   - GSoC rules:
> https://summerofcode.withgoogle.com/rules
>
>   - The detailed GSoC 2024 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: GSoC 2024 Application: Rupali Paliwal

2024-01-24 Thread Martin Jambor

Hello,

We are delighted you found contributing to GCC interesting.  GCC has
applied to be part of GSoC 2024 but of course selected organizations
have not been announced yet this year. More comments inline.

On Mon, Jan 22 2024, Rupali P via Gcc wrote:
> Respected GSoC Review Team,
>
>
> I am writing to express my enthusiastic interest in participating in Google
> Summer of Code 2024 with Tobias Burnus. Below, I've outlined my project
> idea, shared insights into my background and passion for open source, and
> demonstrated my commitment to contributing to Tobias Burnus.
>
>
> *Project Proposal:*
>
> *Title*:
>
> *Fortran – improved argument compile-time checking* – The compiler does
> check for the arguments in the *same* file – but it could do better in some
> cases, i.e. checking better the interface data or updating the expected
> input better from the user. This project would be mentored by Tobias
> Burnus. Required skills include C/C++; some knowledge of Fortran helps, but
> is not needed.
>
>
> *1. Idea Description:*
>
> *Project Title: *Fortran – Improved Argument Compile-Time Checking.
>
> *Idea Description:.*
>
> The goal of this project is to enhance the compile-time checking
> capabilities of the Fortran compiler, specifically focusing on improving
> the analysis of arguments within the same file. While the current compiler
> performs basic argument checks, there is room for improvement, particularly
> in checking interface data and updating expected input information derived
> from the usage context.
>
>
> *Key Components:.*
>
> 1. .Interface Data Analysis:.
>
> - Implement an advanced analysis mechanism to better check interface data
> related to function and subroutine arguments.

I am afraid this needs more detail, especially at least roughly how you
plan to achieve that.  Please read through
https://gcc.gnu.org/wiki/SummerOfCode#Application

>
> - Explore ways to detect and address discrepancies in argument
> specifications within the Fortran code.

I'm afraid I don't understand what you mean.  Anything beyond giving an
error or warning?

>
> 2. .Optimizing Expected Input:.
>
> - Develop strategies to improve the compiler's ability to update expected
> input information based on the usage of arguments in the code.

What do you mean by "update input"?

>
> - Enhance the accuracy of expected input to provide more meaningful
> feedback to developers during the compilation process.
>

This is a way too general statement as well.

>
> Mentor:
>
> Tobias Burnus will serve as the mentor for this project, offering guidance
> and expertise in compiler development.
>
>
> *2. Enthusiasm and Devotion:*
>
> Thrilled about the Fortran – Improved Argument Compile-Time Checking
> project in GSoC 2024 under Tobias Burnus' mentorship. My passion for
> compiler development, Linux OS internals, and open-source fuels my
> eagerness to enhance Fortran's compile-time checking, ensuring code
> reliability and contributing meaningfully to the community.

Enthusiasm is a wonderful thing but you also need to demonstrate
competence.  Please look again at the "Before you apply" section of the
idea page https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and
make sure you are able to build, install and test GCC and then have it
generate dumps and step through some function during compilation.

Try to identify places in the compiler which would need changing to
achieve the project goal.  Feel free to ask specific technical questions
on this list and IRC as you do so.

[...]

>
>
> *4. .Targeted Application:.*
>
> - Emphasize the importance of tailoring each application to the specific
> mentoring organization and project.

???

>
> - Mention unique aspects of the project and organization that align with
> your skills and interests.
>

???

But you don't really need to do either if you can convince us you have
not just the determination but also the skills to successfully finish
the project.  So look at our code, try it out an tell us what you'd
change there to accomplish the project goals.

Good luck,

Martin

Re: GSoC: Application for Rust Front-End Project at GCC

2024-01-24 Thread Martin Jambor

Hello Arpit,

We are very happy that you found contributing to GCC-rust interesting.
GCC has applied to be part of GSoC 2024 but of course selected
organizations have not been announced yet this year.


On Sat, Dec 30 2023, CS21B062 ARPIT GUPTA wrote:
> Dear GCC Community,
>
> I hope this email finds you well. My name is Arpit and I am writing to
> express my interest in participating in GSoC, specifically for the
> Rust Front-End project at GCC. Having completed an internship in
> Compiler Design at IIT Hyderabad in my IInd Year , where I gained
> hands-on experience in code compliance, optimization analysis, and
> cross-compilation, I am eager to contribute to the development of the
> Rust compiler front-end.

Please note that Rust-GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the gcc-rust team:

https://gcc-rust.zulipchat.com/

So I suggest you also reach out to them there as well.  You can refer to
your email in the archives
(https://gcc.gnu.org/pipermail/gcc/2023-December/243089.html) so that
you don't have to repeat everything.

Good luck!

Martin



>
> After carefully reviewing the available projects, I am particularly
> interested in the following project:
>
> Project Choice:
> Rust Front-End,  all the subdomains
>
> Project Description:
> Rust supports several metadata outputs crucial for importing crates.
> The goal of this project is to extend the support for metadata exports
> in the Rust Front-End being developed by GCC. I am confident in my
> understanding of compilation and linking processes, which will be
> essential for this project. I am excited about the opportunity to work
> on this challenging task and contribute to the completion of metadata
> exports.
>
> Why This Project:
> I believe that improving metadata exports is a crucial step towards
> enhancing the interoperability of the Rust compiler with other tools
> and platforms. This effort aligns with my passion for compiler design
> and would significantly contribute to the overall functionality of the
> Rust Front-End. Moreover, as an intern I have already developed some
> compliance checkers using clang for C language in accordance with
> AUTOSAR.
>
> Proposed Timeline:
>
> Weeks 1-2: In-depth analysis of the existing metadata export framework
> in GCC and understanding the requirements for Rust.
> Weeks 3-5: Implementation of basic metadata export functionality for
> the Rust Front-End.
> Weeks 6-8: Testing and debugging of the implemented features,
> addressing any issues that may arise during the integration.
> Weeks 9-12: Fine-tuning, optimization, and documentation of the
> metadata export process, ensuring it meets the project's goals.
>
> I am committed to engaging with the community throughout the
> development process, seeking feedback, and incorporating suggestions
> to ensure the success of the project. I have subscribed to the
> gcc@gcc.gnu.org mailing list and will actively participate in
> discussions regarding the Rust Front-End project.
>
> I would appreciate any feedback or guidance on my proposed project and
> timeline. I am eager to contribute to the GCC community and make a
> meaningful impact on the Rust Front-End project.
>
> Thank you for considering my application. I look forward to the
> opportunity to contribute to the GCC community during GSoC 2023.
>
> Best regards,
> Arpit Gupta,
> Code Club Head
> ph: 8299480636

Re: GSoc Topics

2024-01-23 Thread Gaurang Aswal via Gcc

Thanks, I'll check them out.

On Wed, 24 Jan, 2024, 03:52 Martin Jambor,  wrote:

> Hello,
>
> We are delighted you found contributing to GCC interesting.  GCC has
> applied to be part of GSoC 2024 but of course selected organizations
> have not been announced yet.
>
> On Fri, Jan 12 2024, Gaurang Aswal via Gcc wrote:
> > Hey I am Gaurang Aswal a 4th year B.E. Computer Science student from BITS
> > Goa, India and wanted some info and insights on the Fortran projects and
> I
> > am interested in working on them.
>
> While the list of suggested projects at
> https://gcc.gnu.org/wiki/SummerOfCode is undergoing review for 2024, I
> think the Fortran ones will not change much.  Please look over them, try
> to figure out what they would entail and which you'd like best.  In this
> reply I have also CCed the Fortran mailing list, people there might help
> you decide which Fortan project would be the best for you.
>
>
> > I have basic knowledge of C/C++ and I
> > have completed my basic computer science courses in the same language,
> > which included Object Oriented Programming, Data Structures and
> Algorithms,
> > Computer Architecture and Operating Systems. I would like to keep in
> touch
> > and want to know how to proceed working on the topics.
>
> Contributing to the compiler also requires some rudimentary theoretical
> background in compilers, at the very least understanding of the concept
> of Intermediate Representation (IR), often also called Intermediate
> Language (IL).  Googling either of the two terms should help you to find
> a lot of material to familiarize yourself with it.
>
> Please also look again at the "Before you apply" section of the idea
> page https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make
> sure you are able to build, install and test GCC and then have it
> generate dumps and step through some function during compilation.
>
> Also, feel free to ask for help here with any specific GCC development
> issues you may encounter.
>
> Good luck,
>
> Martin
>

Re: GSoc Topics

2024-01-23 Thread Martin Jambor

Hello,

We are delighted you found contributing to GCC interesting.  GCC has
applied to be part of GSoC 2024 but of course selected organizations
have not been announced yet.

On Fri, Jan 12 2024, Gaurang Aswal via Gcc wrote:
> Hey I am Gaurang Aswal a 4th year B.E. Computer Science student from BITS
> Goa, India and wanted some info and insights on the Fortran projects and I
> am interested in working on them.

While the list of suggested projects at
https://gcc.gnu.org/wiki/SummerOfCode is undergoing review for 2024, I
think the Fortran ones will not change much.  Please look over them, try
to figure out what they would entail and which you'd like best.  In this
reply I have also CCed the Fortran mailing list, people there might help
you decide which Fortan project would be the best for you.

> I have basic knowledge of C/C++ and I
> have completed my basic computer science courses in the same language,
> which included Object Oriented Programming, Data Structures and Algorithms,
> Computer Architecture and Operating Systems. I would like to keep in touch
> and want to know how to proceed working on the topics.

Contributing to the compiler also requires some rudimentary theoretical
background in compilers, at the very least understanding of the concept
of Intermediate Representation (IR), often also called Intermediate
Language (IL).  Googling either of the two terms should help you to find
a lot of material to familiarize yourself with it.

Please also look again at the "Before you apply" section of the idea
page https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make
sure you are able to build, install and test GCC and then have it
generate dumps and step through some function during compilation.

Also, feel free to ask for help here with any specific GCC development
issues you may encounter.

Good luck,

Martin

GSoC 2024 Application: Rupali Paliwal

2024-01-22 Thread Rupali P via Gcc

Respected GSoC Review Team,


I am writing to express my enthusiastic interest in participating in Google
Summer of Code 2024 with Tobias Burnus. Below, I've outlined my project
idea, shared insights into my background and passion for open source, and
demonstrated my commitment to contributing to Tobias Burnus.


*Project Proposal:*

*Title*:

*Fortran – improved argument compile-time checking* – The compiler does
check for the arguments in the *same* file – but it could do better in some
cases, i.e. checking better the interface data or updating the expected
input better from the user. This project would be mentored by Tobias
Burnus. Required skills include C/C++; some knowledge of Fortran helps, but
is not needed.


*1. Idea Description:*

*Project Title: *Fortran – Improved Argument Compile-Time Checking.

*Idea Description:.*

The goal of this project is to enhance the compile-time checking
capabilities of the Fortran compiler, specifically focusing on improving
the analysis of arguments within the same file. While the current compiler
performs basic argument checks, there is room for improvement, particularly
in checking interface data and updating expected input information derived
from the usage context.


*Key Components:.*

1. .Interface Data Analysis:.

- Implement an advanced analysis mechanism to better check interface data
related to function and subroutine arguments.

- Explore ways to detect and address discrepancies in argument
specifications within the Fortran code.

2. .Optimizing Expected Input:.

- Develop strategies to improve the compiler's ability to update expected
input information based on the usage of arguments in the code.

- Enhance the accuracy of expected input to provide more meaningful
feedback to developers during the compilation process.


Mentor:

Tobias Burnus will serve as the mentor for this project, offering guidance
and expertise in compiler development.


*2. Enthusiasm and Devotion:*

Thrilled about the Fortran – Improved Argument Compile-Time Checking
project in GSoC 2024 under Tobias Burnus' mentorship. My passion for
compiler development, Linux OS internals, and open-source fuels my
eagerness to enhance Fortran's compile-time checking, ensuring code
reliability and contributing meaningfully to the community.


*3. .Standout Qualities:.*

*- Technical Proficiency:*

- Strong command of C and Python languages.

- Applied skills in various projects encompassing Machine Learning, Data
Science, and Artificial Intelligence.


*- Linux OS Expertise:*

- Extensive involvement in Linux OS projects.

- Specialized in Virtual Memory Operations, Tracing System Calls, Kernel
module programming, and Device Driver development.


*- Diverse Project Experience:*

- Worked on projects spanning Machine Learning, Data Science, and
Artificial Intelligence.

- Contributed significantly to Linux OS projects, showcasing a breadth of
expertise in systems programming.


*- GitHub Proficiency:*

- Demonstrated proficiency in version control using GitHub.

*- Passion for Innovation:*

- Unique perspective and commitment to pushing boundaries in software
development.

- Continuous learning and a drive to craft innovative solutions to complex
challenges.


*4. .Targeted Application:.*

- Emphasize the importance of tailoring each application to the specific
mentoring organization and project.

- Mention unique aspects of the project and organization that align with
your skills and interests.


I am excited about the opportunity to contribute to GCC success during GSoC
2024. I am committed to actively engaging with the community, seeking
feedback, and ensuring the success of my project.

___


Thank you for considering my application.


Best regards,

Rupali Paliwal

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

2024-01-19 Thread Arthur Cohen

Hi Martin,

On 1/15/24 18:48, Martin Jambor wrote:

Hello,

another year has passed, Google has announced there will be again Google
Summer of Code (GsoC) in 2024 and the deadline for organizations to
apply is already approaching (February 6th). 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 David Edelsohn and Thomas Schwinge to back me up and help me with
some decision making along the way as my co-org-admins.

I think that'd be good :) we've really appreciated all the work you've
done for the past editions.

We'll be discussing project ideas with the rest of the gccrs team and
will update the page shortly. We'd love to mentor again this year.

Thanks for getting in touch,

Best,

Arthur

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. I'm 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 the 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) skills required/preferred,
e) project size - whether it is expected to take approximately 350,
175 or just 90 hours (the last option in new in 2024, see below),
f) difficulty (easy, hard or medium, but we don't really have easy
projects), and
g) expected mentors.

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.

As far as I know, GSoC 2024 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 is new this year but because our projects
usually have a lengthy learning period, I think we will usually 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 2024:

https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html

- GSoC rules:
https://summerofcode.withgoogle.com/rules

- The detailed GSoC 2024 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

--
Arthur Cohen

Toolchain Engineer

Embecosm GmbH

Geschäftsführer: Jeremy Bennett
Niederlassung: Nürnberg
Handelsregister: HR-B 36368
www.embecosm.de

Fürther Str. 27
90429 Nürnberg

Tel.: 091 - 128 707 040
Fax: 091 - 128 707 077

OpenPGP_0x1B3465B044AD9C65.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature

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

2024-01-17 Thread David Malcolm via Gcc

On Mon, 2024-01-15 at 18:48 +0100, Martin Jambor wrote:
> Hello,
> 
> another year has passed, Google has announced there will be again
> Google
> Summer of Code (GsoC) in 2024 and the deadline for organizations to
> apply is already approaching (February 6th).  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 David Edelsohn and Thomas Schwinge to back me up and help me with
> some decision making along the way as my co-org-admins.

Hi Martin, thanks for stepping up, and thanks to you, David and Thomas
for your work on this in past years.

> 
>  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.  I'm 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.

I hope to mentor again this year; I've refreshed the analyzer ideas on
that page.


[...snip...]

Dave

GCC GSoC 2024: Call for project ideas and mentors

2024-01-15 Thread Martin Jambor

Hello,

The most important bit:

Additionally, if you have added an idea to the list in the 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:

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.

As far as I know, GSoC 2024 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."

For further details you can see:

- The announcement of GSoC 2024:

https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html

- GSoC rules:
https://summerofcode.withgoogle.com/rules

- The detailed GSoC 2024 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

GSoc Topics

2024-01-12 Thread Gaurang Aswal via Gcc

Hey I am Gaurang Aswal a 4th year B.E. Computer Science student from BITS
Goa, India and wanted some info and insights on the Fortran projects and I
am interested in working on them. I have basic knowledge of C/C++ and I
have completed my basic computer science courses in the same language,
which included Object Oriented Programming, Data Structures and Algorithms,
Computer Architecture and Operating Systems. I would like to keep in touch
and want to know how to proceed working on the topics.

Re: GSoC: Application for Rust Front-End Project at GCC

2024-01-10 Thread Thomas Schwinge

Hi Arpit!

First, welcome to GCC, and I appreciate your enthousiasm!

On 2023-12-30T22:30:37+0530, CS21B062 ARPIT GUPTA  wrote:
> Dear GCC Community,
>
> I hope this email finds you well. My name is Arpit and I am writing to
> express my interest in participating in GSoC, specifically for the
> Rust Front-End project at GCC.

You're, however, too late for GSoC 2023 (..., which you'd referenced at
the end of your email), but also still too early for GSoC 2024; see
<https://developers.google.com/open-source/gsoc/timeline>.

Building the compiler and beginning to experiment as well as reaching out
to the community is always a good start, so if you're interested in
GCC/Rust specifically, please have a look at
<https://rust-gcc.github.io/>.


Grüße
 Thomas


> Having completed an internship in
> Compiler Design at IIT Hyderabad in my IInd Year , where I gained
> hands-on experience in code compliance, optimization analysis, and
> cross-compilation, I am eager to contribute to the development of the
> Rust compiler front-end.
>
> After carefully reviewing the available projects, I am particularly
> interested in the following project:
>
> Project Choice:
> Rust Front-End,  all the subdomains
>
> Project Description:
> Rust supports several metadata outputs crucial for importing crates.
> The goal of this project is to extend the support for metadata exports
> in the Rust Front-End being developed by GCC. I am confident in my
> understanding of compilation and linking processes, which will be
> essential for this project. I am excited about the opportunity to work
> on this challenging task and contribute to the completion of metadata
> exports.
>
> Why This Project:
> I believe that improving metadata exports is a crucial step towards
> enhancing the interoperability of the Rust compiler with other tools
> and platforms. This effort aligns with my passion for compiler design
> and would significantly contribute to the overall functionality of the
> Rust Front-End. Moreover, as an intern I have already developed some
> compliance checkers using clang for C language in accordance with
> AUTOSAR.
>
> Proposed Timeline:
>
> Weeks 1-2: In-depth analysis of the existing metadata export framework
> in GCC and understanding the requirements for Rust.
> Weeks 3-5: Implementation of basic metadata export functionality for
> the Rust Front-End.
> Weeks 6-8: Testing and debugging of the implemented features,
> addressing any issues that may arise during the integration.
> Weeks 9-12: Fine-tuning, optimization, and documentation of the
> metadata export process, ensuring it meets the project's goals.
>
> I am committed to engaging with the community throughout the
> development process, seeking feedback, and incorporating suggestions
> to ensure the success of the project. I have subscribed to the
> gcc@gcc.gnu.org mailing list and will actively participate in
> discussions regarding the Rust Front-End project.
>
> I would appreciate any feedback or guidance on my proposed project and
> timeline. I am eager to contribute to the GCC community and make a
> meaningful impact on the Rust Front-End project.
>
> Thank you for considering my application. I look forward to the
> opportunity to contribute to the GCC community during GSoC 2023.
>
> Best regards,
> Arpit Gupta,
> Code Club Head
> ph: 8299480636

GSoC: Application for Rust Front-End Project at GCC

2023-12-30 Thread CS21B062 ARPIT GUPTA

Dear GCC Community,

I hope this email finds you well. My name is Arpit and I am writing to
express my interest in participating in GSoC, specifically for the
Rust Front-End project at GCC. Having completed an internship in
Compiler Design at IIT Hyderabad in my IInd Year , where I gained
hands-on experience in code compliance, optimization analysis, and
cross-compilation, I am eager to contribute to the development of the
Rust compiler front-end.

After carefully reviewing the available projects, I am particularly
interested in the following project:

Project Choice:
Rust Front-End,  all the subdomains

Project Description:
Rust supports several metadata outputs crucial for importing crates.
The goal of this project is to extend the support for metadata exports
in the Rust Front-End being developed by GCC. I am confident in my
understanding of compilation and linking processes, which will be
essential for this project. I am excited about the opportunity to work
on this challenging task and contribute to the completion of metadata
exports.

Why This Project:
I believe that improving metadata exports is a crucial step towards
enhancing the interoperability of the Rust compiler with other tools
and platforms. This effort aligns with my passion for compiler design
and would significantly contribute to the overall functionality of the
Rust Front-End. Moreover, as an intern I have already developed some
compliance checkers using clang for C language in accordance with
AUTOSAR.

Proposed Timeline:

Weeks 1-2: In-depth analysis of the existing metadata export framework
in GCC and understanding the requirements for Rust.
Weeks 3-5: Implementation of basic metadata export functionality for
the Rust Front-End.
Weeks 6-8: Testing and debugging of the implemented features,
addressing any issues that may arise during the integration.
Weeks 9-12: Fine-tuning, optimization, and documentation of the
metadata export process, ensuring it meets the project's goals.

I am committed to engaging with the community throughout the
development process, seeking feedback, and incorporating suggestions
to ensure the success of the project. I have subscribed to the
gcc@gcc.gnu.org mailing list and will actively participate in
discussions regarding the Rust Front-End project.

I would appreciate any feedback or guidance on my proposed project and
timeline. I am eager to contribute to the GCC community and make a
meaningful impact on the Rust Front-End project.

Thank you for considering my application. I look forward to the
opportunity to contribute to the GCC community during GSoC 2023.

Best regards,
Arpit Gupta,
Code Club Head
ph: 8299480636

Re: Query status of GSoC project: CPyChecker

2023-06-29 Thread Steven Sun via Gcc

Hi Eric,

> Thanks for reaching out. The project is still in very early stages. So
> far we have taught the analyzer the basic behavior for
> PyLong_FromLong, PyList_New, and Py_DECREF via known function
> subclassing. Additionally, Py_INCREF is supported out of the box.
> Reference count checking functionality remains the priority, but it is
> not yet fully implemented.

Great!

> Regarding CPython versions, the goal is to just get things working on
> one version first. I arbitrarily picked 3.9, but happy to consider
> another version as an initial goal if it’s more helpful to the CPython
> community.

I am not sure about this.

cpychecker is more beneficial to CPython extension devs than to
CPython devs, since it is almost impossible to let the cpychecker learn
the most updated internal function definitions without handwritten
attributes or seeing the whole function definitions.

So it depends on the extension maintainer. I am observing this pattern
that popular libraries are gradually upgrading. 3.9 and 3.10 is definitely
the current mainstream.

Saying so, I think 3.9 is fine for now, but it will be outdated after 2 to 3
years.


Best,
Steven

Re: Query status of GSoC project: CPyChecker

2023-06-28 Thread Eric Feng via Gcc

Hi Steven,

Thanks for reaching out. The project is still in very early stages. So
far we have taught the analyzer the basic behavior for
PyLong_FromLong, PyList_New, and Py_DECREF via known function
subclassing. Additionally, Py_INCREF is supported out of the box.
Reference count checking functionality remains the priority, but it is
not yet fully implemented.

Regarding CPython versions, the goal is to just get things working on
one version first. I arbitrarily picked 3.9, but happy to consider
another version as an initial goal if it’s more helpful to the CPython
community.

Feel free to check out the repo at
https://github.com/efric/gcc-cpython-analyzer for details on the
project and to follow along and help out where you are interested.

Best,
Eric

On Tue, Jun 27, 2023 at 6:03 AM Steven Sun  wrote:
>
> Hi Eric, I am Steven (now) from the CPython team.
>
> How is the project going? Do you have any prototypes
> or ideas that can be discussed? Which part will you start at?
>
>
> I recently debugged dozens of Python bugs, some involving
> C APIs. I can provide some test cases for you.
>
>
> For the ref count part:
>
> A major change (immortal objects) is introduced in Python 3.12.
> Basically, immortal objects will have the ref count fixed at
> a very large number (depending on `sizeof(void*)` ). But I
> don't think it is necessary to implement this in the early
> stages.
>
> Some stable API steals reference conditionally (on success),
> thus its behavior cannot be simply described by one attribute.
>
>
> For CPython versions:
>
> Some stable CPython API behavior varied across the minor
> release. (eg. 3.10 -> 3.11) For instance, some API accepted
> NULL as args for <3.8, but not >=3.8.
>
> Considering both "GCC" and "CPython" are hard for users to
> upgrade, we might want to consider how to live with these
> behavioral differences in the first place.
>
> Versions older than 3 minor releases cannot be touched. (3.13
> now in active development, 3.12, 3.11 for bug fixes, 3.10, 3.9
> security fixes only) So, versions <= 3.10 can be treated as frozen.

Query status of GSoC project: CPyChecker

2023-06-27 Thread Steven Sun via Gcc

Hi Eric, I am Steven (now) from the CPython team.

How is the project going? Do you have any prototypes
or ideas that can be discussed? Which part will you start at?


I recently debugged dozens of Python bugs, some involving
C APIs. I can provide some test cases for you.


For the ref count part:

A major change (immortal objects) is introduced in Python 3.12.
Basically, immortal objects will have the ref count fixed at
a very large number (depending on `sizeof(void*)` ). But I
don't think it is necessary to implement this in the early
stages.

Some stable API steals reference conditionally (on success),
thus its behavior cannot be simply described by one attribute.


For CPython versions:

Some stable CPython API behavior varied across the minor
release. (eg. 3.10 -> 3.11) For instance, some API accepted
NULL as args for <3.8, but not >=3.8.

Considering both "GCC" and "CPython" are hard for users to
upgrade, we might want to consider how to live with these
behavioral differences in the first place.

Versions older than 3 minor releases cannot be touched. (3.13
now in active development, 3.12, 3.11 for bug fixes, 3.10, 3.9
security fixes only) So, versions <= 3.10 can be treated as frozen.

GSoC: Porting cpychecker to a -fanalyzer plugin

2023-05-08 Thread Steven Sun via Gcc

Hi, Eric and Dave,

I did not make it to the GSoC program. I am not surprised.

In this email, I would like to share some thoughts on this project with Eric
and pose some questions to Dave.

In the past month, I have been active in the CPython community. Now I am
nominated as a triage member. https://github.com/python/core-workflow/issues/503

I took a look at how the GCC extension and how the analyzer works. I have the
basic idea of how this project should work.


Questions:

1. Where should this project (cpychecker) resides?

Since it's an extension, it may live outside of the GCC project. But it
currently also relies on some internal headers of the analyzer. If it lives
outside, making the analyzer's internal header stable for public use would
be the best choice here.

2. Where do people in GCC discuss development plans or new ideas?

In other large projects, I observed people discussing such things in a forum.

I emailed one of the contributors. He replied that this email list would be such
a place, as well as the IRC channel. But this mailing list is less active than
the project itself. I guess the most discussions are through the `gcc-patch`
mailing list.

Thoughts/Experiences/Advice: (to Eric)

1. Plugins

GCC has plugin mechanisms: https://gcc.gnu.org/wiki/plugins

If you provide a shared library, the compiler loads your library and calls your
function.

It initiates your plugin. Your plugin registers some callbacks. The compiler
invokes the callbacks later.

Specific to the analyzer, you can see this initialization happen at
`gcc/analyzer/engine.cc`.

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/analyzer/engine.cc;h=a5965c2b8ff048e47d9c1687d5298a11020a5bee;hb=HEAD#l6102

You can try writing a basic "nop" plugin first. You need to include those 
headers
defining the virtual function interfaces.

1. State Machine and Known Functions

As you can see from the interface: the class `plugin_analyzer_init_iface`

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/analyzer/analyzer.h;h=a1619525afaf9322f1ef6d6ec387d6eea70f7c0f;hb=HEAD#l275

You can register two things: state machine and known functions.

The state machine is defined in `sm.h`. These provide core functionality. You
can check all those `sm-*.cc` files. For instance, we have several states on a
pointer, malloced or freed. You can read the logic in `sm-malloc.cc`

Known function is defined in `analyzer.h`. It provides you the ability to do
checks on function calls. You can check `kf.cc` for reference implementations.

When completed, this plugin would consist of several `state_machine`s and
`known_function`s.

3. Go through the code logic with GDB

I don't know to what extent you have interacted with GCC or if you have coded in
C++. I strongly recommend using gdb.

I found it very helpful to debug with gdb. You can go through the code with gdb
and do breakpoints anywhere. You don't need to add some debug lines, then
recompile. (Once you have tried compiling GCC, you will understand what I am
saying.) You can also see the full backtrace, knowing the callee of each 
function
(even where function pointers are used).

You can breakpoint all `ana::*` functions using a wildcard character `*.` Then
gcc will break at any function related to the analyzer. You can then use `c` to
continue.

4. Start with easy issues.

You can read David's guide here.
https://gcc-newbies-guide.readthedocs.io/en/latest/index.html

My personal experience is that if you don't know what to do. Try solving
relevant issues. You can merely find out what caused the bug. Solving them would
be a plus.

I did this in issues #109190 and #109027 and understood how the analyzer works.

---


I will act more like a reviewer and adviser for this project. (To Eric:) I can
review your code and give you advice. I will help you more when you are stuck
with some implementation bugs.

CC me the relevant changes. I will review them when I am available.

Best,
Steven

Welcome GCC GSoC 2023 participants

2023-05-05 Thread Martin Jambor

Hello,

I am pleased to announce that again we will have six contributors
working on GCC as part of their Google Summer of Code (GSoC) projects
in 2023!  In no particular order:

- Benjamin Priour will be "Extending gcc -fanalyzer C++ support for
  self-analysis."  and the project will be mentored by David Malcolm.

- Eric Feng will be working on "Porting cpychecker to a -fanalyzer
  plugin" and his mentor will also be David Malcolm.

- Ken Matsui will look into C++ and in particular will "Implement
  compiler built-in traits for the standard library traits."  This
  project will be mentored by Patrick Palka.

- Muhammad Mahad will be "Improving user errors" in our new Rust
  front-end and will be mentored by Arthur Cohen and Philip Herron.

- Raiki Tamura has succeeded with a project to "Support Unicode in GCC
  Rust front-end" and the project will also be mentored by Arthur
  Cohen and Philip Herron.

- Rishi Raj will be workin on a project to "Bypass assembler when
  generating LTO object files" in that effort will be mentored by Jan
  Hubička and myself.

I'd like to congratulate all of them for putting together really solid
proposals and wish them best of luck with their projects.

The GSoC program has now entered its "community bonding period" which
lasts until May 28th.  During this time, contributors should get in
touch with their mentors unless you have already done so and probably
start looking quite a bit more at GCC in general.

In the initial discussion with your mentors, please take a while to
talk about the time-frame of your project.  If you are happy with the
standard 12 week duration (mid-term evaluation deadline on July 14th,
final deadline on August 28th) you do not need to do anything.  The
program can however also accommodate non-standard schedules, see the
options at:
https://developers.google.com/open-source/gsoc/help/project-dates

If you want to change the duration of your project, first please reach
an agreement with your mentor and then email me and/or other GSoC
Org-admins.  The change can be done at any point in the program but note
that it will not affect any evaluation which has already started.  (In
the case of the standard schedule this means that an Org-admin has to
enter the change before July 10 to affect the mid-term evaluation and
before August 21st to affect the final evaluation).

Because GCC targets many computer platforms, you may also find it very
useful to get an account on the compile farm so that you can test your
code on a variety of architectures.  For more details, see
https://gcc.gnu.org/wiki/CompileFarm

I'd also like to ask all six accepted contributors to take a few
minutes to familiarize themselves with the legal pre-requisites that
we have for contributing.  There are two options.  The much simpler
one is that copyright remains with you but you provide a "Developer
Certificate of Origin" for your contributions.  You can do that by
adding a "Signed-off-by:" tag to all your patches.  The second option
is to assign your copyright to the Free Software Foundation (if anyone
wants to do this, please let me know and I will help).  More
information about both is at:
https://gcc.gnu.org/contribute.html#legal

Last but not least, feel free to raise any question you may have on an
appropriate mailing list (https://gcc.gnu.org/lists.html) or say hi to
us on the gcc development IRC channel
(https://gcc.gnu.org/wiki/GCConIRC).

If you have any concerns or questions regarding the organizational part
of GSoC 2023 or just don't know who else to reach out to, feel free to
contact me throughout the duration of the program.

Once more, congratulations and good luck!

Martin

[GSoC] gcc-rs - Unicode Support or Metadata

2023-04-05 Thread Charlie Hernandez via Gcc

Dear GCC members,

I understand that I am late in submitting this proposal. However, I found
out about gcc-rust and Google of Code three hours ago, and instead of doing
nothing, I decided that it is in my best interest to apply nonetheless. I'm
interested in Rust and the GCC frontend for many reasons, and I would like
to be considered for this involvement. I can be fully committed to the
project if any of my proposals are accepted.


# General Information
Name: Carlos "Charlie Cruz" Hernandez
Email: cj...@rice.edu
University: Rice University '2026
Major/Focus: Mathematics and Linguistics
Country/Timezone: United States / Eastern Standard Time
What is your Open Source Experience so far?

Online I go by "SeniorMars," (https://github.com/SeniorMars), and I have
contributed to the following significant projects: Rust-analyzer, Neovim,
Coc-rust-analyzer, and the Rust compiler for documentation. I'm highly
active in the Neovim, Latex community and working on several Neovim plugins
for the Typst markup language. Additionally, at Rice, I taught.
https://lazy.rice.edu/ (website is outdated due to University policies --
for now) that aims to teach open source concepts to students. Finally, I
have a youtube channel dedicated to open-source concepts:
https://www.youtube.com/@SeniorMarsTries. For the sake of this project, I
have taken my University's programming class as a Freshman. Also, notably,
I'm working on a tree-sitter parser for the Typst markup language that
deals with Unicode. In Neovim, I'm also trying to tackle "concealed text"
with virtual text. Although I have yet to work with gcc-rs, I'm confident I
can help.

# Project Information

I wish to tackle one of the three projects suggested in the gcc-rust
section: Unicode support, Metadata, or Improving user errors.

## Unicode support

While working on the Typst tree-sitter project, I've learned how extensive
Unicode is and the difficulty of correctly parsing such a language. In
particular, I learned how to work with all the weird cases of Unicode,
i.e., emojis, different types of Whitespace, and identifiers.

My main goal is to apply all the concepts I've learned with Typst to gcc-rs.

Thus, the main difficulties will be dealing with modifying the lexer to
handle \p{Whitespace}, \p{XID_Start}, and \p{XID_Continue} properly without
introducing complications in parsing in other areas of the project. Reusing
code from libcpp/ucnid.h from the CPP frontend may help with this part.
Finally, we must introduce a new Rust::String class that represents rust
identifiers, strings, and `create_name` instead of the old implementation.
Of course, I also need to define the v0 mangling scheme that Rust uses to
parse Unicode correctly. I can take a lot of inspiration from Tree-sitter.

The timeline is very close to the two proposals before me. However, I would
first start implementing punycode earlier as it would give me a checklist
on everything I must test to make the lexer fully support Unicode. As the
rest is then shifted, it makes it easier to implement tests for cases I
know will be difficult to deal with.


# Metadata
While working on the typst.nvim, I decided to use Rust to communicate to
Neovim's API  and Lua by linking binary to something neovim can use. This
piqued my interest, and from the looks of it, the work I would be doing in
this project would porting all the requirements of
`rustc_metadata::rmeta::CrateRoot` to `rust-export-metadata.cc`, whose spec
is detailed in `src/rustc_metadata/rmeta/encoder.rs`. In particular, I
would ensure that we support Strict Version Hash (SVH), Stable Crate Id,
and encoded MIR.

My timeline then is based on modifying and implementing the fields in
`CrateRoot.`

However generally:

Week 1-2:
- Modify rust-export-metadata.cc to include the "basic" fields in
CrateRoot, such as edition, panic_in_drop_strategy
- MetaItem

Week 3:
- Implement a testing method to load only specific metadata in case of
identical hashes correctly.
- Document all the functions I created

Week 4-5:
- Implement CrateDep
- Implement Strict Version Hash, which also needs:
- proper StableCrateId, which needs
- proper basic metadata support
Week 5-7:
- Implment `SourceFile`, `ForeignModule`, `NativeLib`, and the rest.
Week 8:
- Testing and documentation plus start a write-up.
Week 9-10:
- Pipelining and Crate loading
Week 11-12:
- Modify our rlib and add dylib support with compression

I would appreciate any mentor. I understand  I am still late, and this
email could be more robust; however, I would love to work on gcc-rs this
summer.

Thank you,
Charlie


-- 
Charlie Cruz -- Going through a name change!
Math & Linguistics @ Rice University '26

Re: Re: GSoC: want to take part in `Extend the static analysis pass for CPython Extension`

2023-04-04 Thread Eric Feng via Gcc

Thanks Martin! Sounds good; I submitted my proposal unchanged for now
(i.e assuming an independent project), but as Dave mentioned in
another thread, it may be divided into several logical components,
perhaps with certain features extended, to be suited for
collaboration.

Best,
Eric





On Mon, Apr 3, 2023 at 11:29 AM Martin Jambor  wrote:
>
> Hello,
>
> On Mon, Apr 03 2023, Eric Feng via Gcc wrote:
> > Hi Steven,
> >
> > I’m happy to collaborate on this project together — it would be great
> > to have your experience with CPython internals on the team.
> >
>
> While I normally welcome collaboration, please note that GSoC rules and
> reasonable caution dictate that the two project must not be dependent on
> one another.  I.e. if one of you, for any reason, could not finish your
> bits in time, it must not have severe adverse effects on the other.
>
> If mostly independent collaboration is possible (and David agrees),
> then sure, go ahead.
>
> Thanks for understanding,
>
> Martin

Re: [GSOC] few question about Bypass assembler when generating LTO object files

2023-04-04 Thread Jan Hubicka via Gcc

> Thanks to Martin, Honza, and Théo for your feedback. I have incorporated
> almost all of it, updated my proposal accordingly, and submitted it.
> Regarding grammar errors, I have fixed many, but there may still be some
> left (I could be better at grammar, to be honest :( ).

I could be better too, I think grammar is not critical here.
Thanks a lot for making and submitting the proposal.

Honza
> 
> On Tue, 4 Apr 2023 at 15:55, Jan Hubicka  wrote:
> 
> > Hello,
> > > Thanks, Jan for the Reply! I have completed a draft proposal for this
> > > project. I will appreciate your's, Martin's, or anybody else feedback on
> > > the same.
> > > Here is the link to my proposal
> > >
> > https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing
> >
> > Here are few comments on the proposal:
> >
> > > The current Implementation of GCC first write the IL representation
> > along with other section in an assembly file and then the assembler is used
> > to convert it into LTO object files. Sections containing different IL
> > representation is created and data is appended in lto-streamer-out.cc.I
> >
> > The .o generated withh -flto file contains the IL (in different
> > sections), debug info, symbol table, etc.
> > "along with other section" sounds odd to me. Perhaps sections.
> >
> > Second sentence seems bit odd too. Perhaps "Streaming of individual
> > sections is implemented in lto-streamer-out.cc which can either be used
> > to produce assembly code containing the section data (dumped
> > hexadecimally) or simple-object API provided by libiberty to produce
> > object files directly"
> >
> > > In the slim object file (Default when using -flto, fat lto can be
> > obtained using -ffat-lto-object) some section contains the IL and other
> > contains the info related to architecture, command line options, symbol
> > table, etc.
> >
> > Technically the architecture is part of ELF header and not section
> > itself (I think).
> >
> > There are some other grammar errors, but I am not too good on fixing
> > these, so perhaps Martin can help.
> >
> > The timeline looks reasonable.  It certianly makes sense to look into
> > non-ELF object files to understand what API we need, but implementation
> > wise I would suggest implementing ELF path first to get a working
> > implementation. Adding support for other object formats can be done
> > incrementally.
> >
> > Honza
> > >
> > > On Tue, 4 Apr 2023 at 04:35, Jan Hubicka  wrote:
> > >
> > > > Hello,
> > > > > While going through the patch and simple-object.c I understood that
> > the
> > > > > file simple-object.c is used to handle the object file format.
> > However,
> > > > > this file does not contain all the architecture information required
> > for
> > > > > LTO object files, so the workaround used in the patch is to read the
> > > > > crtbegin.o file and merge the missing attributes. While this
> > workaround
> > > > is
> > > > > functional, it is not optimal, and the ideal solution would be to
> > extend
> > > > > simple-object.c to include the missing information.
> > > >
> > > > Yes, simple-object.c simply uses architecture settings it read earlier
> > > > which is problem since at compile time we do not read any object files,
> > > > just parse sources). In my original patch the architecture flags were
> > > > simply left blank.  I am not sure if there is a version reading
> > > > crtbeing.o which would probably not a be that bad workaround, at least
> > > > for the start.  Having a way to specify this from the machine
> > descriptions
> > > > would be better.
> > > >
> > >
> > >
> > > >
> > > > Besides the architecture bits, for simple-object files to work we need
> > > > to add the symbol table. For practically useful information we also
> > need
> > > > to stream the debug info.
> > > >
> > > >
> > > > > Regarding the phrase "Support in the driver to properly execute *1
> > > > binary",
> > > > > it is not entirely clear what it refers to. My interpretation is
> > that the
> > > > > compiler driver (the program that coordinates the compilation
> > process)
> > > > > needs to be modified to correctly output LTO object files instead of
> > > > > assembler files (the current approach involves passing the -S and -o
> > > > > .o options) and also skip the assembler option while
> > using
> > > > > -fbypass-asm option but I am not sure. Can Jan or Martin please shed
> > some
> > > > > light on this?
> > > > Yes, compiler drivers decides what to do and it needs to know that with
> > > > -flto it does not need to produce assembly file and then invoke gas.
> > If
> > > > we go the way of reading in crtbegin.o it will also need to pass
> > correct
> > > > crtbegin to *1 binary.  This is generally not that hard to do, just
> > > > needs to be done :)
> > > >
> > > Honza
> > > > >
> > > > > Thanks & Regards
> > > > >
> > > > > Rishi Raj
> > > > >
> > > > > On Sun, 2 Apr 2023 at 03:05, Rishi Raj 
> > wrote:
> > > > >
> > > > > > Hii Everyone

Re: [GSOC] few question about Bypass assembler when generating LTO object files

2023-04-04 Thread Rishi Raj via Gcc

Thanks to Martin, Honza, and Théo for your feedback. I have incorporated
almost all of it, updated my proposal accordingly, and submitted it.
Regarding grammar errors, I have fixed many, but there may still be some
left (I could be better at grammar, to be honest :( ).

On Tue, 4 Apr 2023 at 15:55, Jan Hubicka  wrote:

> Hello,
> > Thanks, Jan for the Reply! I have completed a draft proposal for this
> > project. I will appreciate your's, Martin's, or anybody else feedback on
> > the same.
> > Here is the link to my proposal
> >
> https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing
>
> Here are few comments on the proposal:
>
> > The current Implementation of GCC first write the IL representation
> along with other section in an assembly file and then the assembler is used
> to convert it into LTO object files. Sections containing different IL
> representation is created and data is appended in lto-streamer-out.cc.I
>
> The .o generated withh -flto file contains the IL (in different
> sections), debug info, symbol table, etc.
> "along with other section" sounds odd to me. Perhaps sections.
>
> Second sentence seems bit odd too. Perhaps "Streaming of individual
> sections is implemented in lto-streamer-out.cc which can either be used
> to produce assembly code containing the section data (dumped
> hexadecimally) or simple-object API provided by libiberty to produce
> object files directly"
>
> > In the slim object file (Default when using -flto, fat lto can be
> obtained using -ffat-lto-object) some section contains the IL and other
> contains the info related to architecture, command line options, symbol
> table, etc.
>
> Technically the architecture is part of ELF header and not section
> itself (I think).
>
> There are some other grammar errors, but I am not too good on fixing
> these, so perhaps Martin can help.
>
> The timeline looks reasonable.  It certianly makes sense to look into
> non-ELF object files to understand what API we need, but implementation
> wise I would suggest implementing ELF path first to get a working
> implementation. Adding support for other object formats can be done
> incrementally.
>
> Honza
> >
> > On Tue, 4 Apr 2023 at 04:35, Jan Hubicka  wrote:
> >
> > > Hello,
> > > > While going through the patch and simple-object.c I understood that
> the
> > > > file simple-object.c is used to handle the object file format.
> However,
> > > > this file does not contain all the architecture information required
> for
> > > > LTO object files, so the workaround used in the patch is to read the
> > > > crtbegin.o file and merge the missing attributes. While this
> workaround
> > > is
> > > > functional, it is not optimal, and the ideal solution would be to
> extend
> > > > simple-object.c to include the missing information.
> > >
> > > Yes, simple-object.c simply uses architecture settings it read earlier
> > > which is problem since at compile time we do not read any object files,
> > > just parse sources). In my original patch the architecture flags were
> > > simply left blank.  I am not sure if there is a version reading
> > > crtbeing.o which would probably not a be that bad workaround, at least
> > > for the start.  Having a way to specify this from the machine
> descriptions
> > > would be better.
> > >
> >
> >
> > >
> > > Besides the architecture bits, for simple-object files to work we need
> > > to add the symbol table. For practically useful information we also
> need
> > > to stream the debug info.
> > >
> > >
> > > > Regarding the phrase "Support in the driver to properly execute *1
> > > binary",
> > > > it is not entirely clear what it refers to. My interpretation is
> that the
> > > > compiler driver (the program that coordinates the compilation
> process)
> > > > needs to be modified to correctly output LTO object files instead of
> > > > assembler files (the current approach involves passing the -S and -o
> > > > .o options) and also skip the assembler option while
> using
> > > > -fbypass-asm option but I am not sure. Can Jan or Martin please shed
> some
> > > > light on this?
> > > Yes, compiler drivers decides what to do and it needs to know that with
> > > -flto it does not need to produce assembly file and then invoke gas.
> If
> > > we go the way of reading in crtbegin.o it will also need to pass
> correct
> > > crtbegin to *1 binary.  This is generally not that hard to do, just
> > > needs to be done :)
> > >
> > Honza
> > > >
> > > > Thanks & Regards
> > > >
> > > > Rishi Raj
> > > >
> > > > On Sun, 2 Apr 2023 at 03:05, Rishi Raj 
> wrote:
> > > >
> > > > > Hii Everyone,
> > > > > I had already expressed my interest in the " Bypass assembler when
> > > > > generating LTO object files" project and making a proposal for the
> > > same. I
> > > > > know I should have done it earlier but I was admitted to the
> hospital
> > > for
> > > > > past few days :(.
> > > > > I have a few doubts.
> > > > > 1)
> > > > >
> > > > > "O

Re: [GSOC] few question about Bypass assembler when generating LTO object files

2023-04-04 Thread Jan Hubicka via Gcc

Hello,
> Thanks, Jan for the Reply! I have completed a draft proposal for this
> project. I will appreciate your's, Martin's, or anybody else feedback on
> the same.
> Here is the link to my proposal
> https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing

Here are few comments on the proposal:

> The current Implementation of GCC first write the IL representation along 
> with other section in an assembly file and then the assembler is used to 
> convert it into LTO object files. Sections containing different IL 
> representation is created and data is appended in lto-streamer-out.cc.I

The .o generated withh -flto file contains the IL (in different
sections), debug info, symbol table, etc.
"along with other section" sounds odd to me. Perhaps sections.

Second sentence seems bit odd too. Perhaps "Streaming of individual
sections is implemented in lto-streamer-out.cc which can either be used
to produce assembly code containing the section data (dumped
hexadecimally) or simple-object API provided by libiberty to produce
object files directly"

> In the slim object file (Default when using -flto, fat lto can be obtained 
> using -ffat-lto-object) some section contains the IL and other contains the 
> info related to architecture, command line options, symbol table, etc. 

Technically the architecture is part of ELF header and not section
itself (I think).

There are some other grammar errors, but I am not too good on fixing
these, so perhaps Martin can help.

The timeline looks reasonable.  It certianly makes sense to look into
non-ELF object files to understand what API we need, but implementation
wise I would suggest implementing ELF path first to get a working
implementation. Adding support for other object formats can be done
incrementally.

Honza
> 
> On Tue, 4 Apr 2023 at 04:35, Jan Hubicka  wrote:
> 
> > Hello,
> > > While going through the patch and simple-object.c I understood that the
> > > file simple-object.c is used to handle the object file format. However,
> > > this file does not contain all the architecture information required for
> > > LTO object files, so the workaround used in the patch is to read the
> > > crtbegin.o file and merge the missing attributes. While this workaround
> > is
> > > functional, it is not optimal, and the ideal solution would be to extend
> > > simple-object.c to include the missing information.
> >
> > Yes, simple-object.c simply uses architecture settings it read earlier
> > which is problem since at compile time we do not read any object files,
> > just parse sources). In my original patch the architecture flags were
> > simply left blank.  I am not sure if there is a version reading
> > crtbeing.o which would probably not a be that bad workaround, at least
> > for the start.  Having a way to specify this from the machine descriptions
> > would be better.
> >
> 
> 
> >
> > Besides the architecture bits, for simple-object files to work we need
> > to add the symbol table. For practically useful information we also need
> > to stream the debug info.
> >
> >
> > > Regarding the phrase "Support in the driver to properly execute *1
> > binary",
> > > it is not entirely clear what it refers to. My interpretation is that the
> > > compiler driver (the program that coordinates the compilation process)
> > > needs to be modified to correctly output LTO object files instead of
> > > assembler files (the current approach involves passing the -S and -o
> > > .o options) and also skip the assembler option while using
> > > -fbypass-asm option but I am not sure. Can Jan or Martin please shed some
> > > light on this?
> > Yes, compiler drivers decides what to do and it needs to know that with
> > -flto it does not need to produce assembly file and then invoke gas.  If
> > we go the way of reading in crtbegin.o it will also need to pass correct
> > crtbegin to *1 binary.  This is generally not that hard to do, just
> > needs to be done :)
> >
> Honza
> > >
> > > Thanks & Regards
> > >
> > > Rishi Raj
> > >
> > > On Sun, 2 Apr 2023 at 03:05, Rishi Raj  wrote:
> > >
> > > > Hii Everyone,
> > > > I had already expressed my interest in the " Bypass assembler when
> > > > generating LTO object files" project and making a proposal for the
> > same. I
> > > > know I should have done it earlier but I was admitted to the hospital
> > for
> > > > past few days :(.
> > > > I have a few doubts.
> > > > 1)
> > > >
> > > > "One problem is that the object files produced by
> > libiberty/simple-object.c
> > > > (which is the low-level API used by the LTO code)
> > > > are missing some information (such as the architecture info and symbol
> > > > table) and API of the simple object will need to be extended to handle
> > > > that" I found this in the previous mailing list discussion. So who
> > output this information currently in the object file, is it assembler?
> > > >
> > > > Also in the current patch for this project by Jan Hubica, from where
> >

Re: [GSOC] few question about Bypass assembler when generating LTO object files

2023-04-04 Thread Martin Jambor

Hi,

On Tue, Apr 04 2023, Rishi Raj wrote:
> Thanks, Jan for the Reply! I have completed a draft proposal for this
> project. I will appreciate your's, Martin's, or anybody else feedback on
> the same.
> Here is the link to my proposal
> https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing
>

in my opinion, the proposal looks rather good.  I don't know how to
significantly improve it, not in the remaining nine hours before the
deadline (just maybe fix the spelling of Honza's surname, it is Hubicka
:-). So please go ahead and submit it. (How the selection goes will then
depend on how many slots we get from Google).

Thanks for putting in the effort,

Martin


> On Tue, 4 Apr 2023 at 04:35, Jan Hubicka  wrote:
>
>> Hello,
>> > While going through the patch and simple-object.c I understood that the
>> > file simple-object.c is used to handle the object file format. However,
>> > this file does not contain all the architecture information required for
>> > LTO object files, so the workaround used in the patch is to read the
>> > crtbegin.o file and merge the missing attributes. While this workaround
>> is
>> > functional, it is not optimal, and the ideal solution would be to extend
>> > simple-object.c to include the missing information.
>>
>> Yes, simple-object.c simply uses architecture settings it read earlier
>> which is problem since at compile time we do not read any object files,
>> just parse sources). In my original patch the architecture flags were
>> simply left blank.  I am not sure if there is a version reading
>> crtbeing.o which would probably not a be that bad workaround, at least
>> for the start.  Having a way to specify this from the machine descriptions
>> would be better.
>>
>
>
>>
>> Besides the architecture bits, for simple-object files to work we need
>> to add the symbol table. For practically useful information we also need
>> to stream the debug info.
>>
>>
>> > Regarding the phrase "Support in the driver to properly execute *1
>> binary",
>> > it is not entirely clear what it refers to. My interpretation is that the
>> > compiler driver (the program that coordinates the compilation process)
>> > needs to be modified to correctly output LTO object files instead of
>> > assembler files (the current approach involves passing the -S and -o
>> > .o options) and also skip the assembler option while using
>> > -fbypass-asm option but I am not sure. Can Jan or Martin please shed some
>> > light on this?
>> Yes, compiler drivers decides what to do and it needs to know that with
>> -flto it does not need to produce assembly file and then invoke gas.  If
>> we go the way of reading in crtbegin.o it will also need to pass correct
>> crtbegin to *1 binary.  This is generally not that hard to do, just
>> needs to be done :)
>>
> Honza
>> >
>> > Thanks & Regards
>> >
>> > Rishi Raj
>> >
>> > On Sun, 2 Apr 2023 at 03:05, Rishi Raj  wrote:
>> >
>> > > Hii Everyone,
>> > > I had already expressed my interest in the " Bypass assembler when
>> > > generating LTO object files" project and making a proposal for the
>> same. I
>> > > know I should have done it earlier but I was admitted to the hospital
>> for
>> > > past few days :(.
>> > > I have a few doubts.
>> > > 1)
>> > >
>> > > "One problem is that the object files produced by
>> libiberty/simple-object.c
>> > > (which is the low-level API used by the LTO code)
>> > > are missing some information (such as the architecture info and symbol
>> > > table) and API of the simple object will need to be extended to handle
>> > > that" I found this in the previous mailing list discussion. So who
>> output this information currently in the object file, is it assembler?
>> > >
>> > > Also in the current patch for this project by Jan Hubica, from where
>> are we getting these information from? Is it from crtbegin.o?
>> > >
>> > > 2)
>> > > "Support in driver to properly execute *1 binary." I found this on Jan
>> original patch's email. what does it mean
>> > >
>> > > exactly?
>> > >
>> > > Regards
>> > >
>> > > Rishi Raj
>> > >
>> > >
>> > >
>> > >
>>

Re: [GSoC][analyzer-c++] Submission of a draft proposal

2023-04-03 Thread David Malcolm via Gcc

On Mon, 2023-04-03 at 18:46 +0200, Benjamin Priour wrote:
> Following last mail, a classic I forgot to link my draft !
> https://docs.google.com/document/d/1MaLDo-Rt8yrJIvC1MO8SmFc6fp4eRQM_JeSdv-1kbsc/edit?usp=sharing

Some notes:
  * The document still has some notes in italics marked "[RFC]" which
you'll want to fix before formally submitting it.
  * "Project Goals": item 4: you give a reproducer; perhaps add a link
to godbolt.org (Compiler Explorer) demonstrating the overlong
diagnostic path?
  *  Part 1: as part of moving the test cases to c-c++-common you'll
probably have to debug/write a little .exp code (in Tcl) so that it
actually runs the tests, probably in analyzer.exp.  So you might want
to allow some time to read up on Tcl, which is the language our
testsuite is written in (I wish it was in Python, but fixing that would
be a different project, alas)
  * Part 2: your grep for unique_ptr found 2903 uses, but I guess many
of these are in libstdc++-v3.  As i understand it, this is compiled for
the target (as a library for use by the compiler user), whereas I'm
much more interested in the code below "gcc", which is compiled for the
host into the compiler itself.  You might want so split out these
numbers.

One task is to try adding -fanalyzer to the build flags for the
compiler itself, and see what happens: is it usable?  is it unusably
slow on some of our source files? does it find true problems?  does it
report false positives?  The current document suggests doing this in
part 3 as the last 20% of the project; I think it makes more sense to
do the initial attempt at this much earlier, to get an earlier idea of
what the problems might be.

"Motivation and Skill set": the first paragraph is poorly worded; for
example the 2nd sentence seems to just stop halfway through.

"Mentor": yes, I would be the mentor

Other than that, looks good.

The deadline for formally submitting this to the GSoC website is April
4th at 18:00 UTC (less than 24 hours from now), and Google are strict
about this deadline.

Good luck!
Dave

> 
> Best,
> Benjamin.
> 
> On Mon, Apr 3, 2023 at 6:44 PM Benjamin Priour 
> wrote:
> 
> > Hi David,
> > 
> > On Mon, Apr 3, 2023 at 12:38 AM David Malcolm 
> > wrote:
> > 
> > > 
> > > To be fair, C ones can be as well; the analyzer's exploded graphs
> > > tend
> > > to get very big on anything but the most trivial examples.
> > > 
> > > 
> > > 
> > [...snip...]
> > 
> > 
> > > 
> > > Indeed - you'll have to do a lot of looking at gimple IR dumps,
> > > what
> > > the supergraph looks like, etc, for all of this.
> > > 
> > > 
> > Yep. I have already tried my hands on them, but to be fair I'm
> > still often
> > troubled by them. Still,
> > doing so have already provided essential insight on the analyzer.
> > 
> > [...snip...]
> > 
> > 
> > > > 4. Extension of out-of-bounds
> > > >  ( - Extending -Wout-of-bounds to the many vec<...> might be a
> > > > requirement.
> > > > However I have to look into more details for that one, I don't
> > > > see
> > > > yet how
> > > > it could be done without a similar reuse of the assertions as
> > > > for the
> > > > libstdc++.)
> > > > 
> > > > From what I saw, despite the bugs not being FIXED, vfuncs seem
> > > > to be
> > > > working nicely enough after the fix from GSoC 2021.
> > > 
> > > IIRC I was keeping those bugs open because there's still a little
> > > room
> > > for making the analyzer smarter about the C++ type system e.g. if
> > > we
> > > "know" that a foo * is pointing at a particular subclass, maybe
> > > we know
> > > things about what vfunc implementations could be called.
> > > 
> > > We could even try an analysis mode where we split the analysis
> > > path at
> > > a vfunc call, where we could create an out-edge in the egraph for
> > > each
> > > known concrete subclass for foo *, so that we can consider all
> > > the
> > > possible subclasses and the code that would be called.  (I'm not
> > > sure
> > > if this is a *good* idea, but it intrigues me)
> > > 
> > 
> > Like adding a flag to run in a non-standard mode, to debug when an
> > unexpected vfunc analysis occurs ? TBH I didn't look that much into
> > vfuncs
> > support, as my dummy tests behave OK and I assumed it was fixed
> > after last
> > GSoC

[GSOC] Submission of draft proposal for Bypass assembler when generating LTO object files

Sorry, I messed subject in my previous two emails :( so I am sending it
again.
I have completed a draft proposal for this project. I will appreciate Jan,
Martin, or anybody else feedback on the same.
Here is the link to my proposal
https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing

Fwd: [GSOC] few question about Bypass assembler when generating LTO object files

-- Forwarded message -
From: Rishi Raj 
Date: Tue, 4 Apr 2023 at 05:57
Subject: Re: [GSOC] Submission of draft proposal.
To: Jan Hubicka 
Cc: , 
oops, I forgot to change the subject in previous email :(

Thanks, Jan for the Reply! I have completed a draft proposal for this
project. I will appreciate your's, Martin's, or anybody else feedback on
the same.
Here is the link to my proposal
https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing

On Tue, 4 Apr 2023 at 04:35, Jan Hubicka  wrote:

> Hello,
> > While going through the patch and simple-object.c I understood that the
> > file simple-object.c is used to handle the object file format. However,
> > this file does not contain all the architecture information required for
> > LTO object files, so the workaround used in the patch is to read the
> > crtbegin.o file and merge the missing attributes. While this workaround
> is
> > functional, it is not optimal, and the ideal solution would be to extend
> > simple-object.c to include the missing information.
>
> Yes, simple-object.c simply uses architecture settings it read earlier
> which is problem since at compile time we do not read any object files,
> just parse sources). In my original patch the architecture flags were
> simply left blank.  I am not sure if there is a version reading
> crtbeing.o which would probably not a be that bad workaround, at least
> for the start.  Having a way to specify this from the machine descriptions
> would be better.
>


>
> Besides the architecture bits, for simple-object files to work we need
> to add the symbol table. For practically useful information we also need
> to stream the debug info.
>
>
> > Regarding the phrase "Support in the driver to properly execute *1
> binary",
> > it is not entirely clear what it refers to. My interpretation is that the
> > compiler driver (the program that coordinates the compilation process)
> > needs to be modified to correctly output LTO object files instead of
> > assembler files (the current approach involves passing the -S and -o
> > .o options) and also skip the assembler option while using
> > -fbypass-asm option but I am not sure. Can Jan or Martin please shed some
> > light on this?
> Yes, compiler drivers decides what to do and it needs to know that with
> -flto it does not need to produce assembly file and then invoke gas.  If
> we go the way of reading in crtbegin.o it will also need to pass correct
> crtbegin to *1 binary.  This is generally not that hard to do, just
> needs to be done :)
>
Honza
> >
> > Thanks & Regards
> >
> > Rishi Raj
> >
> > On Sun, 2 Apr 2023 at 03:05, Rishi Raj  wrote:
> >
> > > Hii Everyone,
> > > I had already expressed my interest in the " Bypass assembler when
> > > generating LTO object files" project and making a proposal for the
> same. I
> > > know I should have done it earlier but I was admitted to the hospital
> for
> > > past few days :(.
> > > I have a few doubts.
> > > 1)
> > >
> > > "One problem is that the object files produced by
> libiberty/simple-object.c
> > > (which is the low-level API used by the LTO code)
> > > are missing some information (such as the architecture info and symbol
> > > table) and API of the simple object will need to be extended to handle
> > > that" I found this in the previous mailing list discussion. So who
> output this information currently in the object file, is it assembler?
> > >
> > > Also in the current patch for this project by Jan Hubica, from where
> are we getting these information from? Is it from crtbegin.o?
> > >
> > > 2)
> > > "Support in driver to properly execute *1 binary." I found this on Jan
> original patch's email. what does it mean
> > >
> > > exactly?
> > >
> > > Regards
> > >
> > > Rishi Raj
> > >
> > >
> > >
> > >
>

Re: [GSOC] few question about Bypass assembler when generating LTO object files

Thanks, Jan for the Reply! I have completed a draft proposal for this
project. I will appreciate your's, Martin's, or anybody else feedback on
the same.
Here is the link to my proposal
https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing

On Tue, 4 Apr 2023 at 04:35, Jan Hubicka  wrote:

> Hello,
> > While going through the patch and simple-object.c I understood that the
> > file simple-object.c is used to handle the object file format. However,
> > this file does not contain all the architecture information required for
> > LTO object files, so the workaround used in the patch is to read the
> > crtbegin.o file and merge the missing attributes. While this workaround
> is
> > functional, it is not optimal, and the ideal solution would be to extend
> > simple-object.c to include the missing information.
>
> Yes, simple-object.c simply uses architecture settings it read earlier
> which is problem since at compile time we do not read any object files,
> just parse sources). In my original patch the architecture flags were
> simply left blank.  I am not sure if there is a version reading
> crtbeing.o which would probably not a be that bad workaround, at least
> for the start.  Having a way to specify this from the machine descriptions
> would be better.
>


>
> Besides the architecture bits, for simple-object files to work we need
> to add the symbol table. For practically useful information we also need
> to stream the debug info.
>
>
> > Regarding the phrase "Support in the driver to properly execute *1
> binary",
> > it is not entirely clear what it refers to. My interpretation is that the
> > compiler driver (the program that coordinates the compilation process)
> > needs to be modified to correctly output LTO object files instead of
> > assembler files (the current approach involves passing the -S and -o
> > .o options) and also skip the assembler option while using
> > -fbypass-asm option but I am not sure. Can Jan or Martin please shed some
> > light on this?
> Yes, compiler drivers decides what to do and it needs to know that with
> -flto it does not need to produce assembly file and then invoke gas.  If
> we go the way of reading in crtbegin.o it will also need to pass correct
> crtbegin to *1 binary.  This is generally not that hard to do, just
> needs to be done :)
>
Honza
> >
> > Thanks & Regards
> >
> > Rishi Raj
> >
> > On Sun, 2 Apr 2023 at 03:05, Rishi Raj  wrote:
> >
> > > Hii Everyone,
> > > I had already expressed my interest in the " Bypass assembler when
> > > generating LTO object files" project and making a proposal for the
> same. I
> > > know I should have done it earlier but I was admitted to the hospital
> for
> > > past few days :(.
> > > I have a few doubts.
> > > 1)
> > >
> > > "One problem is that the object files produced by
> libiberty/simple-object.c
> > > (which is the low-level API used by the LTO code)
> > > are missing some information (such as the architecture info and symbol
> > > table) and API of the simple object will need to be extended to handle
> > > that" I found this in the previous mailing list discussion. So who
> output this information currently in the object file, is it assembler?
> > >
> > > Also in the current patch for this project by Jan Hubica, from where
> are we getting these information from? Is it from crtbegin.o?
> > >
> > > 2)
> > > "Support in driver to properly execute *1 binary." I found this on Jan
> original patch's email. what does it mean
> > >
> > > exactly?
> > >
> > > Regards
> > >
> > > Rishi Raj
> > >
> > >
> > >
> > >
>

Re: [GSOC] few question about Bypass assembler when generating LTO object files

2023-04-03 Thread Jan Hubicka via Gcc

Hello,
> While going through the patch and simple-object.c I understood that the
> file simple-object.c is used to handle the object file format. However,
> this file does not contain all the architecture information required for
> LTO object files, so the workaround used in the patch is to read the
> crtbegin.o file and merge the missing attributes. While this workaround is
> functional, it is not optimal, and the ideal solution would be to extend
> simple-object.c to include the missing information.

Yes, simple-object.c simply uses architecture settings it read earlier
which is problem since at compile time we do not read any object files,
just parse sources). In my original patch the architecture flags were
simply left blank.  I am not sure if there is a version reading
crtbeing.o which would probably not a be that bad workaround, at least
for the start.  Having a way to specify this from the machine descriptions
would be better.

Besides the architecture bits, for simple-object files to work we need
to add the symbol table. For practically useful information we also need
to stream the debug info.
> 
> Regarding the phrase "Support in the driver to properly execute *1 binary",
> it is not entirely clear what it refers to. My interpretation is that the
> compiler driver (the program that coordinates the compilation process)
> needs to be modified to correctly output LTO object files instead of
> assembler files (the current approach involves passing the -S and -o
> .o options) and also skip the assembler option while using
> -fbypass-asm option but I am not sure. Can Jan or Martin please shed some
> light on this?
Yes, compiler drivers decides what to do and it needs to know that with
-flto it does not need to produce assembly file and then invoke gas.  If
we go the way of reading in crtbegin.o it will also need to pass correct
crtbegin to *1 binary.  This is generally not that hard to do, just
needs to be done :)

Honza
> 
> Thanks & Regards
> 
> Rishi Raj
> 
> On Sun, 2 Apr 2023 at 03:05, Rishi Raj  wrote:
> 
> > Hii Everyone,
> > I had already expressed my interest in the " Bypass assembler when
> > generating LTO object files" project and making a proposal for the same. I
> > know I should have done it earlier but I was admitted to the hospital for
> > past few days :(.
> > I have a few doubts.
> > 1)
> >
> > "One problem is that the object files produced by libiberty/simple-object.c
> > (which is the low-level API used by the LTO code)
> > are missing some information (such as the architecture info and symbol
> > table) and API of the simple object will need to be extended to handle
> > that" I found this in the previous mailing list discussion. So who output 
> > this information currently in the object file, is it assembler?
> >
> > Also in the current patch for this project by Jan Hubica, from where are we 
> > getting these information from? Is it from crtbegin.o?
> >
> > 2)
> > "Support in driver to properly execute *1 binary." I found this on Jan 
> > original patch's email. what does it mean
> >
> > exactly?
> >
> > Regards
> >
> > Rishi Raj
> >
> >
> >
> >

RE: GSoC Separate Host Process Offloading

2023-04-03 Thread Thomas Schwinge

Hi Adi!

I've not been able yet to review your items in detail, but it's very good
that you're discussing your ideas!

At least a few comments:

On 2023-04-01T03:16:28+, "Prasad, Adi via Gcc"  wrote:
> Tobias wrote:
>> [...] permit something like -foffload=host instead of having to
>> specify -foffload=x86_64-none-linux-gnu

Right -- but I'd be happy if initially the latter worked, and then a
'host' variant can be made work incrementally.

> Understood. Forgive me if I'm misunderstanding this, but [...]

No, these are certainly good ideas!  :-) (I can't investigate the details
right now, but surely will, once the time comes.)

Please spend some time on this central question that I'd raised:

| Make some thoughts (or actual experiments) about how we could
| use/implement a separate host process for code offloading.

That is, include in your project proposal (or, discuss here, if there's
still time) your ideas about how to actually implement that.

As Martin wrote, don't worry too much about the specific format of your
application.  It's more important that we're able to see that you're
understanding the scope of the project, timeline, expected difficulties,
and so on.  All within reasonable bounds, of course -- we're all very
well aware of the difficulties of estimating software projects...  Yet,
some plausible timeline, milestones, etc. are necessary in the project
proposal.

Good luck!

Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [GSOC] few question about Bypass assembler when generating LTO object files