Re: [Static Analyzer] Loop handling - False positive for malloc-sm

[Pierrick Philippe]

On 21/03/2023 00:30, David Malcolm wrote:

On Mon, 2023-03-20 at 13:28 +0100, Pierrick Philippe wrote:

Hi everyone,

I'm still playing around with the analyzer, and wanted to have a look
at
loop handling.
I'm using a build from /trunk/ branch (/20230309/).

Here is my analyzed code:

'''
1| #include 
2| int main(void) {
3|    void * ptr = malloc(sizeof(int));
4|    for (int i = 0; i < 10; i++) {
5|    if (i == 5) free(ptr);
6|    }
7|}
'''

[stripping]

So, I'm guessing that this false positive is due to how the analyzer
is
handling loops.
Which lead to my question: how are loops handled by the analyzer?

Sadly, the answer is currently "not very well" :/

I implemented my own approach, with a "widening_svalue" subclass of
symbolic value.  This is widening in the Abstract Interpretation sense,
(as opposed to the bitwise operations sense): if I see multiple values
on successive iterations, the widening_svalue tries to simulate that we
know the start value and the direction the variable is moving in.

This doesn't work well; arguably I should rewrite it, perhaps with an
iterator_svalue, though I'm not sure how it ought to work.  Some ideas:

* reuse gcc's existing SSA-based loop analysis, which I believe can
identify SSA names that are iterator variables, figure out their
bounds, and their per-iteration increments, etc.

* rework the program_point or supergraph code to have a notion of "1st
iteration of loop", "2nd iteration of loop", "subsequent iterations",
or similar, so that the analyzer can explore those cases differently
(on the assumption that such iterations hopefully catch the most
interesting bugs)


I see, I don't know if you ever considered allowing state machines to 
deal with loops on their own.
Such as having an API to allow to register a callback to handle loops, 
but not in a mandatory way.

Or having a set of APIs to optionally implement for the analyzer to call.

It would allow state machines to analyze loops with the meaning of their 
inner analysis.


Which could allow them to try to find a fixed point in the loop 
execution which doesn't have
any impact on the program state for that state machine. Kind of like a 
custom loop invariant.
Because depending of the analysis goal of the state machine, you might 
need to symbolically execute the loop
only a few times before reentering the loop and having the entry state 
being the same as the end-of-loop state.


In fact, this could be done directly by the analyzer, and only calling 
state machine APIs for loop handling which still has not reached
such a fixed point in their program state for the analyzed loop, with a 
maximum number of execution fixed by the analyzer to limit execution time.


Does what I'm saying make sense?

In terms of implementation, loop detection can be done by looking for 
strongly connected components (SCCs)

in a function graph having more than one node.
I don't know if this is how it is already done within the analyzer or not?

Thank you for your time,

Pierrick

Re: [Static Analyzer] Loop handling - False positive for malloc-sm

[Shengyu Huang via Gcc]

Hi Dave,

> I implemented my own approach, with a "widening_svalue" subclass of
> symbolic value.  This is widening in the Abstract Interpretation sense,
> (as opposed to the bitwise operations sense): if I see multiple values
> on successive iterations, the widening_svalue tries to simulate that we
> know the start value and the direction the variable is moving in.

I guess you are using interval domain? I haven’t played with abstract 
interpretation a lot, but I think the polyhedra domain is the more popular 
domain used (but more difficult to implement ofc). In a course project I did 
before, I remember switching to polyhedra domain from the interval domain 
allowed me to prove the properties I wanted to prove.

Also, are you using the same approach maybe to detect nontermination of loops? 
Maybe when you find out you have to widen the variable range to (minus) 
infinity?

> 
> This doesn't work well; arguably I should rewrite it, perhaps with an
> iterator_svalue, though I'm not sure how it ought to work.  Some ideas:
> 
> * reuse gcc's existing SSA-based loop analysis, which I believe can
> identify SSA names that are iterator variables, figure out their
> bounds, and their per-iteration increments, etc.
> 
> * rework the program_point or supergraph code to have a notion of "1st
> iteration of loop", "2nd iteration of loop", "subsequent iterations",
> or similar, so that the analyzer can explore those cases differently
> (on the assumption that such iterations hopefully catch the most
> interesting bugs)

I haven’t thought about how to do this properly in gcc, but maybe we can infer 
loop invariants (or even allow users to annotate loop invariants…but I guess it 
would change a lot of things outside the scope of current analyzer) that can 
help us do multiple checks for a loop. I have only seen this strategy used on 
the source level before, and I don’t know how difficult it will be to implement 
it on gimple…There is a paper I haven’t had the time to read but maybe you will 
find interesting: https://arxiv.org/pdf/1407.5286.pdf

Best,
Shengyu

Re: [Static Analyzer] Loop handling - False positive for malloc-sm

[Shengyu Huang via Gcc]

Hi Dave,

> On 21 Mar 2023, at 00:30, David Malcolm via Gcc  wrote:
> 
> I implemented my own approach, with a "widening_svalue" subclass of
> symbolic value.  This is widening in the Abstract Interpretation sense,
> (as opposed to the bitwise operations sense): if I see multiple values
> on successive iterations, the widening_svalue tries to simulate that we
> know the start value and the direction the variable is moving in.

I forgot to mention there is a relevant section “path selection” in the paper I 
mentioned several times 
(https://users.ece.cmu.edu/~aavgerin/papers/Oakland10.pdf). 

Interested in participating in GSoC

[Sanskriti Mathuria via Gcc]

Hi everyone!
My name is Sanskriti Mathuria and I am a student pursuing computer science
at PES University, Bangalore, India. I am in my third year of college. The
project "Enable incremental Link Time Optimization (LTO) linking" and "C++:
Implement compiler built-in traits for the standard library traits" in the
GSoC projects idea list sparked my interest, and I wanted to know what
resources could I look into to understand these problems better, and what
more I could research to prepare a proposal for this project.
Thank you!

Regards,
Sanskriti Mathuria

[no subject]

[Shreyash Pawar via Gcc]

I am interested in gsoc and I know cpp language

Interested in GSoC (was: )

[Tobias Burnus]

Hi Shreyash,

On 21.03.23 12:45, Shreyash Pawar via Gcc wrote:

I am interested in gsoc and I know cpp language


See https://gcc.gnu.org/wiki/SummerOfCode for project ideas. I helps to
think about a certain project and to get familiar with GCC.

In particular, please read "Before you apply".

Thanks,

Tobias

-
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: Static Analyzer: correlate state for different region/svalue for reporting

[Pierrick Philippe]

On 16/03/2023 14:44, David Malcolm wrote:

On Thu, 2023-03-16 at 09:54 +0100, Pierrick Philippe wrote:

On 15/03/2023 17:26, David Malcolm wrote:

On Wed, 2023-03-15 at 16:24 +0100, Pierrick Philippe wrote:

[stripping]

So, first question: is there any way to associate and track the
state
of
a rvalue, independently of its lvalue?

To try to clarify the question, here's an example:

'''
int __attribute__("__some_attribute__") x = 42;
/* STEP-1
   From now on, we consider the state of x as being marked by
some_attribute.
But in fact, in the log, we can observe that we'll have something
like
this in the new '/ana::program_state/':
{0x4b955b0: (int)42: marked_state (‘x’)} */

[stripping]

int *y = &x;
/* STEP-2
For analysis purpose, you want to know that from now on, y is
pointing
to marked data.
So you set state of the LHS of the GIMPLE statement (i.e. some
ssa_name
instance of y) accordingly, with a state named 'points-
to_marked_data'
and setting 'x' as the origin of the state (in the sense of the
argument
/origin/ from '/ana::sm_context::on_transition/'.
What we now have in the new '/ana::program_state/' is this:
{0x4b9acb0: &x: points-to-marked_data (‘&x’) (origin: 0x4b955b0:
(int)42
(‘x’)), 0x4b955b0: (int)42: marked_state (‘x’)} */

Yes: you've set the state on the svalue "&x", not on "y".


int z = *y;
/* STEP-3
Now you have implicit copy of marked data, and you want to report
it.
So you state the LHS of the GIMPLE statement (i.e. some ssa_name
instance of z) as being marked, with 'y' as the origin.
What we now have in the new '/ana::program_state/' is this:
{0x4b9acb0: &x: points-to-marked_data (‘&x’) (origin: 0x4b955b0:
(int)42
(‘x’)), 0x4b955b0: (int)42: marked_state (‘x’)} */
'''

Presumably the program_state also shows that you have a binding for
the
region "z", containing the svalue 42 (this is represented within
the
"store", within the region_model within the program_state).


[stripping]

This is an update about tracking state of svalues instead of region for 
other kind of variables than pointers.


If you consider the following code:

'''
int __attribute__((__taint__)) x = 42;
/* Program state:
{0x4b955b0: (int)42: marked_state (‘x’)}
*/
int y = 42;
// Program state unchanged
if (y);
/* When querying the sm_context about the state of y,
it returns it as being in a "marked_state", because its svalue is the 
same as x's one.

Even though no call to change y's state has been made.
And here it triggers a diagnostic for my analysis.
*/
'''

I understand way better now the internals of the analyzer regarding the 
state's tracking.
I do completely understand now, why you've said you've mainly designed 
it for pointers, because this allow you to avoid to do some points-to 
analysis, by associating state with pointer's svalues instead of 
pointer's region.


But as you can see in the above code example, it has its drawback for 
analyzing variables with a different semantics, such as integer type 
variable.


I will have to modified the analyzer's code to add a way for state 
machine to ask the analyzer to track region's state instead of svalue's 
state to be able to keep using it with my analysis plugin.


Do you think it would be interesting having such features merged within 
the analyzer?
In any case, I'll start to work on it over the last /trunk/ branch, 
within an appropriate branch.


Thank you for your time,

Pierrick

GSOC 2023 Proposal about MetaData Exports by Parthib Datta

[Parthib Datta via Gcc]

There is my GSOC 2023 Proposal about the Metadata Exports project please
review it and let me know what you guys think about it??


GSOC Proposal for Metadata Exports in Rust-GCC by Parthib Datta.docx
Description: MS-Word 2007 document

GSoC Applicant

[Arunesh Choudhary]

Hi there,

I am 3rd year computer science student at University of Windsor, Canada. I 
would like to apply for one of the projects for GCC.
On the website, it was recommended to contact team as soon as possible. So, I 
am sending this email to show my interest.

Also, I noticed that it is mentioned that student must have C\C++ experience. 
To be honest, I have used both these languages just as a part of my courseware. 
I am willing to put efforts to learn in deep if opportunity given.

This semester I am taking compiler course as well, so I have primarily 
knowledge about the compilers.

Hope to talk to you soon.

Thanks
Arunesh

Libgcc divide vectorization question

[Andrew Stubbs]

Hi all,

I want to be able to vectorize divide operators (softfp and integer), 
but amdgcn only has hardware instructions suitable for -ffast-math.


We have recently implemented vector versions of all the libm functions, 
but the libgcc functions aren't builtins and therefore don't use those 
hooks.


What's the best way to achieve this? Add a new __builtin_div (and 
__builtin_mod) that tree-vectorize can find, perhaps? Or something else?


Thanks

Andrew

Re: [RISC-V][tech-rvv-intrinsics] RISC-V V C Intrinsic API v1.0 release meeting reminder (March 20th, 2023)

[Eop Chen via Gcc]

The meeting minutes in added in the note. 


You can also find it under riscv-admin/rvv-intrinsics. 


> eop Chen via lists.riscv.org  於 
> 2023年3月20日 下午3:56 寫道：
> 
> Hi all,
> 
> A reminder that the next open meeting to discuss on the RISC-V V C Intrinsic 
> API v1.0 is going to
> be held later on 2023/03/20 6AM (GMT -7) / 11PM (GMT +8).
> 
> The agenda can be found in the second page of the meeting slides (link 
> ).
> Please join the calendar to be constantly notified - Google calender link 
> ,
>  ICal 
> 
> We also have a mailing list now hosted by RISC-V International (link 
> ).
> 
> I was busy in SiFive-related work for the past month, so the implementation 
> of tuple-types is not done
> as we expected for our planning until 03/20. We might not have much to 
> discuss for today but I will
> hold the meeting for discussion of planning. Any other topics related to RVV 
> intrinsics are welcomed.
> 
> Regards,
> 
> eop Chen
> 
> _._,_._,_
> Links:
> You receive all messages sent to this group.
> 
> View/Reply Online (#32) 
>  | Reply To Group 
> 
>  | Reply To Sender 
> 
>  | Mute This Topic  | New Topic 
> 
> Your Subscription 
>  | Contact 
> Group Owner  | Unsubscribe 
> 
>  [eop.c...@sifive.com]
> 
> _._,_._,_

Tobias Burnus as OpenMP and libgomp reviewer

[Jason Merrill via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed
Tobias Burnus as an additional OpenMP and libgomp maintainer.

Tobias, please update your listing in the MAINTAINERS file.

Cheers,
Jason

Re: [GSOC] getting "gdb: unrecognized option '-dumpdir'' while trying to debug gcc using gdb

[James K. Lowden]

On Mon, 20 Mar 2023 15:08:41 -0400
David Malcolm via Gcc  wrote:

> Another way to invoke cc1 under the debugger is to add "-v" to the gcc
> invocation to get verbose output, and then see what command-line it
> uses to invoke cc1, and then run:
> 
>   gdb --args ARGS_OF_CC1_INVOCATION

I find it easiest just to invoke the compiler proper.  

$ echo $cobol1
[...]/build/gcc/cobol1

$ gdb --args $cobol1 -oo  foo.cbl

That sets the compiler driver aside, and lets me work directly on the
compiler.  

Of course, I'm concerned with just one language, and just one
compiler.  If your concern crosses languages, I'd imagine the -wrapper
technique would be easier.  

--jkl

Re: GSoC'2023: Bypass assembler when generating LTO object files: GCC

[Martin Jambor]

Hello,

please make sure you CC the mailing list in these communications.

On Thu, Mar 16 2023, Madhu patel wrote:
> Hi,
>
>>That is an impressive list.  On a more specific note, do you have any -
>> rudimentary is fine - background in the theory of compilers?  Are you
>> familiar with concepts like intermediate representation (intermediate
>> language)?
>
> Yes! I have Built the GCC from source and Yes, I do have good knowledge of
> compilers. We had this subject in the college curriculum where we studied
> intermediate representation.  I have good knowledge of C++, c, Java, and
> Bash. etc.
>
>>Great.  What are the issues you have encountered?  I assume you have
>>seen David's guide for newcomers too?  If not, have a look at it at
>>https://gcc-newbies-guide.readthedocs.io/en/latest/index.html
>
> Yes, I have built the GCC from scratch on my Linux Machine.
> I have written the documentation for the same. And working on understanding
> the details of offLoading.
> https://www.dropbox.com/scl/fi/ffx7c29f0yfhvbiuvndku/GCC.paper?dl=0&rlkey=76x89xkzz3h41uemor9ksw6sl

Just a note, using images to capture terminal (instead of the text that
is there) is a very bad practice.  (The configure step is also quite
conspicuously missing in your text, why?)

> And gone through the
> https://gcc-newbies-guide.readthedocs.io/en/latest/index.html
>  and did a
> basic setup for GCC on my Linux machine.
>
> Can we schedule a meeting to discuss the project's timeline and specific
> tasks that I can take on?
> Please let me know your availability.

Sorry but no, I am not able to and do not intend to schedule calls with
GSoC applicants.  I'll be happy to discuss stuff on the mailing-list.

Estimating a timeline and coming up with (at least some) milestones of
the project is part of the exercise of writing a proposal.  GSoC
contributors need to demonstrate a certain level of independent thought
and initiative - though of course the community is always there to help
with specific questions and difficulties.

The project has been discussed already in
https://gcc.gnu.org/pipermail/gcc/2023-March/240833.html and this
message should be enough to get you started.

Good luck,

Martin


>
>
> On Tue, Mar 14, 2023 at 10:48 PM Martin Jambor  wrote:
>
>> Hello,
>>
>> We are delighted you found looking into GCC interesting.
>>
>> On Thu, Mar 09 2023, Madhu patel via Gcc wrote:
>> > Hi Jan,
>> >
>> > I'm interested in working on the project `Bypass assembler when
>> generating
>> > LTO object files` in the GCC organization through GSoC'2023.
>>
>> Great, please note that the task as already been discussed on the
>> mailing list and some information is available in the archives at
>>
>>https://gcc.gnu.org/pipermail/gcc/2023-March/240833.html
>>
>> >
>> > I am Madhu Patel, a fourth-year B.Tech. student in Computer Science at
>> > IGDTUW, with a CGPA of 8.7/10. I have previously interned at Adobe India,
>> > Rabvik Innovations, and FM solutions, and I am currently a research
>> intern
>> > at IIT Roorkee. I am also working on a research paper on Linux Kernel
>> > Evolution for the USENIX publication. Moreover, my research paper on
>> Stock
>> > Price Prediction was recently accepted at the IEEE Conference. You can
>> find
>> > more information about my work on my LinkedIn and GitHub profiles.
>>
>> That is an impressive list.  On a more specific note, do you have any -
>> rudimentary is fine - background in the theory of compilers?  Are you
>> familiar with concepts like intermediate representation (intermediate
>> language)?
>>
>> >
>> > Please suggest a few initial tasks I can work on during the application
>> > period and attach them to my application. I have already prepared a
>> > timeline/planner, great if you could have a look at it and suggest any
>> > enhancements. Additionally, I have signed in to the mailing lists, and
>> IRCs
>> > and done the initial tasks as described on the project page [1]
>> > .
>>
>> Great.  What are the issues you have encountered?  I assume you have
>> seen David's guide for newcomers too?  If not, have a look at it at
>> https://gcc-newbies-guide.readthedocs.io/en/latest/index.html
>>
>> I am afraid there are not very many small issues or problems that can be
>> dealt with in a few weeks.  Instead, I would encourage you to keep
>> investigating the code, particularly around the areas described in the
>> mailing list post I linked above, and start thinking about how you'd
>> achieve the overall goal.  Feel free to ask any specific questions you
>> might have about the project and GCC development in general here.
>>
>> Good luck!
>>
>> Martin
>>
>>

Re: Regarding GSOC

[Martin Jambor]

Hello,

please CC the mailing list on these discussions.

On Fri, Mar 17 2023, Megha Raj wrote:
> Thank you for your mail
> Now I'm focusing on internal working of compiler
> As having a rough idea is enough for the contribution or I need depth
> knowledge??

that depends on the project but for many, just having an idea what an
Intermediate Representation (IR), sometimes called Intermediate Language
(IL) is, can suffice.

But it really depends on what you would like to focus on.

Good luck,

Martin

>
> On Tue, 14 Mar, 2023, 22:55 Martin Jambor,  wrote:
>
>> Hello,
>>
>> On Mon, Mar 13 2023, Megha Raj via Gcc wrote:
>> > Respected sir/mam,
>> >
>> > Actually I want to know what are skills you desire to have in the members
>> > of your organization as I’m aware with c &c++ so, can you please let me
>> > know other than this what knowledge should I know for getting selected in
>> > your franchise in deep
>>
>> We are delighted you found contributing to GCC interesting.
>>
>> 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 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.
>>
>> Afterwards, look at a suggested idea, try to identify the portion of GCC
>> source which is involved and email us back to the mailing list,
>> describing the idea and (often with help from the community) what is
>> your plan to address it.  Also, we'll be happy to help with any specific
>> GCC development issues you may encounter.
>>
>> Good luck,
>>
>> Martin
>>

Re: GSoC 2023

[Martin Jambor]

Hello,

On Sun, Mar 19 2023, ANKESH PANDEY . wrote:
> Hello,
>
> I am Ankesh Pandey, a 3rd year Computer Science Undergraduate.
>
> I am interested in contributing for the following projects:

We are delighted you found contributing to GCC interesting.

>
>1.
>
>Unicode support: Our Lexer and AST do not support Unicode strings and
>identifiers, which we need to be a Rust compiler. The project will require
>a student to work mostly in the Lexer and AST but the changes here will
>ripple all the way through our HIR and code-generation passes. For example,
>in implementing Unicode support, it will make sense to ensure we improve
>location info, so instead of simply passing around Unicode strings in the
>IR's we should create a unique string data structure which also contains
>location info to improve our error diagnostics and debug
> information. *Difficulty:
>Hard Size: 350 hours (large) Mentors: Arthur and/or Philip*
>2.
>
>Improving user errors: We recently merged code enabling the Rust
>frontend to emit error codes similarly to rustc. We'd like for gccrs to be
>able to emit the same errors codes as rustc, in order to help bridge the
>gap between our two testsuites and enable us to eventually run the rustc
>one. The student will have to research rustc error codes, their various
>guarantees, and emit them throughout the frontend code. We would also like
>the code responsible for emitting errors to get more fleshed out and allow
>more functionality. Finally, this will also be a good project to start
>looking at a better user experience for gccrs: emitting more errors, in
>more places, with more hints to the users about ways to fix the
> code. *Difficulty:
>Medium Size: 175 (medium) Mentors: Arthur and/or Philip*
>

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 am really good at C, C++ and have decent experience working with FLEX and
> YACC and hence would be an appropriate candidate for the same.
>
> It would be great if you can give me insights on how I can formalize my
> proposal for GSoC 2023.

I assume you have already read through https://gcc.gnu.org/wiki/SummerOfCode  
The page has guidelines on what we expect to find a proposal.

Feel free to ask about any specifics either here on the mailing list or
on the Zulip linked above.

Good luck!

Martin

Re: [GSOC] query about C++: Implement compiler built-in traits for the standard library traits

[Martin Jambor]

Hello Anastasia,

we are very happy that you are considering contributing to GCC.

On Mon, Mar 20 2023, Anastasia3412 via Gcc wrote:
> Hello Everyone I'm Anastasia.
>
>I am a prospective GSOC Student. I wish to know if the project C++:
>Implement compiler built-in traits for the standard library traits is
>still available. I have already build and got my hand dirty on
>debugging GCC.

Various prospective contributors have shown interest in it but we have
not "promised" it to anyone, I don't think we can, so it is "available."
It has been discussed for example here:
https://gcc.gnu.org/pipermail/gcc/2023-February/240816.html

> How should I proceed to make a proposal.

I have listed what we expect to find in the proposal at
https://gcc.gnu.org/wiki/SummerOfCode  (but I assume you have already
read that page).  You need to figure out what the project would entail
and write it down, with a little bit of detail and milestones.

We'll be happy to help answering any specific questions.

> Also I want to
>know does having theoretical knowledge of compiler knowledge a
>prerequisite for this proposal, if yes I will do a course on compiler
>design.

I do not know this area of the compiler particularly well, but generally
speaking, some basic level of knowledge of the theory is necessary - at
least of the basic data structures that compilers operate on
(intermediate language or intermediate representation).

Good luck!

Martin

Re: [GSoC 2023] Rust front-end: Improving User Errors

[Martin Jambor]

Hello,

 We are delighted you found contributing to GCC interesting.

On Mon, Mar 20 2023, Panagiotis Foliadis via Gcc wrote:
> Greetings,
>
> My name is Panagiotis Foliadis, Ι'm 26 years old and I am from Athens, Greece.
>
> I'm interesting in the Rust frοnt-end project and especially at Improving 
> user errors. I'm a self taught 
> software developer with solid knowledge about Rust, and also Ι'm doing my 
> internship that mainly uses C. I'm really 
> interested in the low level side of programming and especially compilers. I 
> have already built gcc from source and 
> did some studying on the documentation to acquire some basic knowledge about 
> the 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 them there as well.

>
> I'd like some guidance from the mentors prior to making a proposal, if there 
> is any to give. 

I assume you have already read through https://gcc.gnu.org/wiki/SummerOfCode
The page has guidelines on what we expect to find a proposal.  Basically
you need to figure out what the project would entail and write it down,
with a little bit of detail and milestones.

Feel free to ask about any specifics either here on the mailing list or
on the Zulip linked above.

Good luck!

Martin

Re: GSoC Applicant

[Martin Jambor]

Hello Arunesh,

On Tue, Mar 21 2023, Arunesh Choudhary wrote:
> Hi there,
>
> I am 3rd year computer science student at University of Windsor, Canada. I 
> would like to apply for one of the projects for GCC.
> On the website, it was recommended to contact team as soon as possible. So, I 
> am sending this email to show my interest.

Indeed, thank you.  We are glad that you find contributing to GCC
interesting.

>
> Also, I noticed that it is mentioned that student must have C\C++
> experience. To be honest, I have used both these languages just as a
> part of my courseware. I am willing to put efforts to learn in deep if
> opportunity given.

Well, GCC is written mostly in C++ though because it was originally
written in C, it is not particularly "heavy."  You may not need to
define any templates in the course of your project but you would be
required to use them.  After all, have a look at the source code
yourself and decide for yourself, if you understand the code to the
point that you could extend it, little by little.

>
> This semester I am taking compiler course as well, so I have primarily 
> knowledge about the compilers.

Great.  Select a project, start investigating what it would entail to
complete it and start putting together your proposal.  We on the mailing
list will be happy to help with any specific question or particular
problem.

Good luck,

Martin

Re: [GSOC] query about C++: Implement compiler built-in traits for the standard library traits

[Jonathan Wakely via Gcc]

On Tue, 21 Mar 2023 at 21:16, Martin Jambor wrote:
>
> Hello Anastasia,
>
> we are very happy that you are considering contributing to GCC.
>
> On Mon, Mar 20 2023, Anastasia3412 via Gcc wrote:
> > Hello Everyone I'm Anastasia.
> >
> >I am a prospective GSOC Student. I wish to know if the project C++:
> >Implement compiler built-in traits for the standard library traits is
> >still available. I have already build and got my hand dirty on
> >debugging GCC.
>
> Various prospective contributors have shown interest in it but we have
> not "promised" it to anyone, I don't think we can, so it is "available."
> It has been discussed for example here:
> https://gcc.gnu.org/pipermail/gcc/2023-February/240816.html

We already have two candidates working on it, before their proposal
has even been accepted. As a result, I think you'd have to be a very
strong candidate to get accepted for that project, and it might be
better to pick another one.