GCC GSoC 2019 projects: announcement and a mandatory first step

[Martin Jambor]

[Sorry for a re-post, I forgot to write a subject and as a consequence
the email did not make it through to the mailing list]

Hello,

I am pleased to announce that six students will be working on GCC or
GCC-related Google Summer of Code (GSoC) projects:

  - JeanHeyd Meneide will be working on improving libstdc++, focusing on
vector and related algorithms and data structures (see
https://gcc.gnu.org/ml/libstdc++/2019-02/msg4.html and the
ensuing thread for more details),

  - Tejas Joshi will be working on adding new builtins for math
functions introduced in IEC 18661 and thus exposing them to
optimizations,

  - Akshat Garg will be making sure that gcc/g++ do not automatically
promote memory_order_consume to memory_order_acquire,

  - Giuliano Belinassi will be parallelizing GCC with Threads, 

  - Khurai Kim will be working on implementing OpenMP Work Stealing
Scheduling scheduling options, and

  - Shubham Narlawar will be working on enabling generation of GCC
extensions by the CSmith fuzzer.

I'd like to congratulate all of them for putting together very 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 27th.  One of the most important things all accepted
students who are expected to contribute directly to GCC code base should
do in this time is to request a copyright assignment[1] as soon as you
can (i.e. everybody but Shubham who is however also invited to do so).

Please email the following information to ass...@gnu.org, and they will
send you the assignment form for your past and future changes.  Use your
full legal name (in ASCII characters) as the subject line of the
message.

--
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

[For the copyright registration, what country are you a citizen of?]

[What year were you born?]

[Please write your email address here.]

[Please write your postal address here.]

[Which files have you changed so far, and which new files have you written
so far?]
--

Please report back to me when you have completed the process or if you
encounter any issues and/or unreasonably long delays.

Because GCC targets many computer platforms, you may also find it very
useful to get an account on the compile farm[2] so that you can test
your code on a variety of architectures.  Of course, you should get in
touch with your mentors unless you have already done so.  Last but not
least feel free to raise any question you might have on an appropriate
mailing list[3] or say hi to us on the gcc development IRC channel [4].

If you have any concerns or questions regarding the organizational part
of GSoC 2019, feel free to contact me throughout the duration of the
program.

Once more, congratulations and good luck!

Martin

[1] https://gcc.gnu.org/contribute.html#legal
[2] https://gcc.gnu.org/wiki/CompileFarm
[3] https://gcc.gnu.org/lists.html
[4] https://gcc.gnu.org/wiki/GCConIRC

Re: GCC GSOC 2019

[Shubham Narlawar]

On Fri, Apr 5, 2019 at 5:37 PM Martin Liška  wrote:

> On 4/4/19 1:44 PM, Shubham Narlawar wrote:
> > On Thu, Apr 4, 2019 at 2:13 PM Martin Liška  wrote:
> >
> >> On 4/3/19 6:31 PM, Martin Jambor wrote:
> >>> Hello Shubham,
> >>>
> >>> On Fri, Mar 29 2019, Shubham Narlawar wrote:
>  Hi, here is my proposal for the above idea. Please review and suggest
>  necessary changes.
> 
> 
> >>
> https://docs.google.com/document/d/11MNhuuD7dbwAfSW6ZgFrAys9My1Lw1PuMVcAqeNGr7A/edit?usp=sharing
> >>>
> >>> I have had a quick look and the proposal seems very nice.
> >>>
> >>> How did you select the attributes you want to implement in csmith?  It
> >>> is for example a little strange that you decided to include "pure" but
> >>> not "const."  If you handle visibility, you might as well consider
> >>> throwing in externally_visible too, I guess.  As a stretch goal, the
> >>> alias function attribute might be useful to exercise nasty paths in GCC
> >>> IPA optimizations.
> >>>
> >>> I assume Andi Kleen has seen this proposal and if he is fine with it,
> so
> >>> am I.
> >>>
> >>> Thanks,
> >>>
> >>> Martin
> >>>
> >>
> >> Hi.
> >>
> >> Just for the record, Martin Jambor asked me to co-mentor during time
> period
> >> when Andi will be on vacation (if I'm correct).
> >>
> >
> > I have included your name as co-mentor in my proposal. Is it fine?
>
> Yes.
>
> >
> >
> >> I have couple of questions/ideas about the proposal:
> >>
> >> 1) I would not spend much time with nested functions, it's quite legacy
> >> C extension
> >>
> >
> > Once Andi Kleen suggested that nested functions has lot of potential for
> > bugs.
> > I will not only just add nested functions but I plan to do integration
> > testing along with merging of previously implemented extensions in phase
> 3
> > of gsoc timeline
>
> I would be more interested in lambda functions, which is also kind of a
> nested function.
>

AFAIK, lambda expressions are strictly based on c++ 11 standard and Csmith
is only random C code generator and not C++. In this gsoc timeline, I am
extending Csmith for C extensions.

>
> >
> >
> >> 2) for functions, I would basically include add potential attribute:
> >>
> >>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
> >>
> >> see:
> >> gcc/c-family/c-attribs.c:242
> >> const struct attribute_spec c_common_attribute_table[] =
> >> ...
> >>
> >
> >
> >> I assume potential attributes means attributes that will trigger
> different
> > components of GCC. Can you point out such potential attributes such as
> > alias.
>
> Basically majority of them can stress a component in GCC. More you add
> better coverage
> we'll have.


I will definitely try to add more attributes rather than mentioned
attributes if time permits.


>
> >
> >
> >
> >>
> >> 3) similarly for variables:
> >>
> >>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes
> >
> >
> > Few of variables attributes like packed, unused, section, aligned are
> > already implemented in Csmith.
>
> Great then.
>
> >
> >
> >>
> >> 4) and similarly for types
> >>
> >>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attribute
> >> <
> https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attributes
> >
> >
> > 5) One big question about csmith I have. It's quite easy to come up with
> a
> >> test-case which
> >> causes an ICE. But it's more difficult to come up with a test-case that
> is
> >> miscompiled
> >> by a compiler. It's mainly due to an invalid behavior in the generated
> >> test-case.
> >> One can theoretically catch that with sanitizers (ASAN, UBSAN, ...). But
> >> still, it's
> >> not easy. Are you considering catching wrong-code issue?
> >>
> >
> > I use option -fsanitize=undefined and valgrind to check undefined
> > behaviour. Are there any other ways to check it rather than sanitizers?
>
> I'm not aware of any others. I'm curious if you we able to find a
> wrong-code
> with your periodic csmith runner?


>
> Thanks for working on csmith,
> Martin
>

Thanks.
Shubham

>
> >
> > Thanks,
> > Shubham
> >
> >
> >>
> >> Thanks,
> >> Martin
> >>
>
>

Re: GCC GSOC 2019

[Martin Liška]

On 4/4/19 1:44 PM, Shubham Narlawar wrote:
> On Thu, Apr 4, 2019 at 2:13 PM Martin Liška  wrote:
> 
>> On 4/3/19 6:31 PM, Martin Jambor wrote:
>>> Hello Shubham,
>>>
>>> On Fri, Mar 29 2019, Shubham Narlawar wrote:
 Hi, here is my proposal for the above idea. Please review and suggest
 necessary changes.


>> https://docs.google.com/document/d/11MNhuuD7dbwAfSW6ZgFrAys9My1Lw1PuMVcAqeNGr7A/edit?usp=sharing
>>>
>>> I have had a quick look and the proposal seems very nice.
>>>
>>> How did you select the attributes you want to implement in csmith?  It
>>> is for example a little strange that you decided to include "pure" but
>>> not "const."  If you handle visibility, you might as well consider
>>> throwing in externally_visible too, I guess.  As a stretch goal, the
>>> alias function attribute might be useful to exercise nasty paths in GCC
>>> IPA optimizations.
>>>
>>> I assume Andi Kleen has seen this proposal and if he is fine with it, so
>>> am I.
>>>
>>> Thanks,
>>>
>>> Martin
>>>
>>
>> Hi.
>>
>> Just for the record, Martin Jambor asked me to co-mentor during time period
>> when Andi will be on vacation (if I'm correct).
>>
> 
> I have included your name as co-mentor in my proposal. Is it fine?

Yes.

> 
> 
>> I have couple of questions/ideas about the proposal:
>>
>> 1) I would not spend much time with nested functions, it's quite legacy
>> C extension
>>
> 
> Once Andi Kleen suggested that nested functions has lot of potential for
> bugs.
> I will not only just add nested functions but I plan to do integration
> testing along with merging of previously implemented extensions in phase 3
> of gsoc timeline

I would be more interested in lambda functions, which is also kind of a nested 
function.

> 
> 
>> 2) for functions, I would basically include add potential attribute:
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
>>
>> see:
>> gcc/c-family/c-attribs.c:242
>> const struct attribute_spec c_common_attribute_table[] =
>> ...
>>
> 
> 
>> I assume potential attributes means attributes that will trigger different
> components of GCC. Can you point out such potential attributes such as
> alias.

Basically majority of them can stress a component in GCC. More you add better 
coverage
we'll have.

> 
> 
> 
>>
>> 3) similarly for variables:
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes
> 
> 
> Few of variables attributes like packed, unused, section, aligned are
> already implemented in Csmith.

Great then.

> 
> 
>>
>> 4) and similarly for types
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attribute
>> 
> 
> 5) One big question about csmith I have. It's quite easy to come up with a
>> test-case which
>> causes an ICE. But it's more difficult to come up with a test-case that is
>> miscompiled
>> by a compiler. It's mainly due to an invalid behavior in the generated
>> test-case.
>> One can theoretically catch that with sanitizers (ASAN, UBSAN, ...). But
>> still, it's
>> not easy. Are you considering catching wrong-code issue?
>>
> 
> I use option -fsanitize=undefined and valgrind to check undefined
> behaviour. Are there any other ways to check it rather than sanitizers?

I'm not aware of any others. I'm curious if you we able to find a wrong-code
with your periodic csmith runner?

Thanks for working on csmith,
Martin

> 
> Thanks,
> Shubham
> 
> 
>>
>> Thanks,
>> Martin
>>

Re: GCC GSOC 2019

[Shubham Narlawar]

On Thu, Apr 4, 2019 at 2:13 PM Martin Liška  wrote:

> On 4/3/19 6:31 PM, Martin Jambor wrote:
> > Hello Shubham,
> >
> > On Fri, Mar 29 2019, Shubham Narlawar wrote:
> >> Hi, here is my proposal for the above idea. Please review and suggest
> >> necessary changes.
> >>
> >>
> https://docs.google.com/document/d/11MNhuuD7dbwAfSW6ZgFrAys9My1Lw1PuMVcAqeNGr7A/edit?usp=sharing
> >
> > I have had a quick look and the proposal seems very nice.
> >
> > How did you select the attributes you want to implement in csmith?  It
> > is for example a little strange that you decided to include "pure" but
> > not "const."  If you handle visibility, you might as well consider
> > throwing in externally_visible too, I guess.  As a stretch goal, the
> > alias function attribute might be useful to exercise nasty paths in GCC
> > IPA optimizations.
> >
> > I assume Andi Kleen has seen this proposal and if he is fine with it, so
> > am I.
> >
> > Thanks,
> >
> > Martin
> >
>
> Hi.
>
> Just for the record, Martin Jambor asked me to co-mentor during time period
> when Andi will be on vacation (if I'm correct).
>

I have included your name as co-mentor in my proposal. Is it fine?


> I have couple of questions/ideas about the proposal:
>
> 1) I would not spend much time with nested functions, it's quite legacy
> C extension
>

Once Andi Kleen suggested that nested functions has lot of potential for
bugs.
I will not only just add nested functions but I plan to do integration
testing along with merging of previously implemented extensions in phase 3
of gsoc timeline


> 2) for functions, I would basically include add potential attribute:
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
>
> see:
> gcc/c-family/c-attribs.c:242
> const struct attribute_spec c_common_attribute_table[] =
> ...
>


> I assume potential attributes means attributes that will trigger different
components of GCC. Can you point out such potential attributes such as
alias.



>
> 3) similarly for variables:
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes


Few of variables attributes like packed, unused, section, aligned are
already implemented in Csmith.


>
> 4) and similarly for types
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attribute
> 

5) One big question about csmith I have. It's quite easy to come up with a
> test-case which
> causes an ICE. But it's more difficult to come up with a test-case that is
> miscompiled
> by a compiler. It's mainly due to an invalid behavior in the generated
> test-case.
> One can theoretically catch that with sanitizers (ASAN, UBSAN, ...). But
> still, it's
> not easy. Are you considering catching wrong-code issue?
>

I use option -fsanitize=undefined and valgrind to check undefined
behaviour. Are there any other ways to check it rather than sanitizers?

Thanks,
Shubham


>
> Thanks,
> Martin
>

Re: GCC GSOC 2019

[Shubham Narlawar]

On Wed, Apr 3, 2019 at 10:01 PM Martin Jambor  wrote:

> Hello Shubham,
>
> On Fri, Mar 29 2019, Shubham Narlawar wrote:
> > Hi, here is my proposal for the above idea. Please review and suggest
> > necessary changes.
> >
> >
> https://docs.google.com/document/d/11MNhuuD7dbwAfSW6ZgFrAys9My1Lw1PuMVcAqeNGr7A/edit?usp=sharing
>
> I have had a quick look and the proposal seems very nice.
>
> How did you select the attributes you want to implement in csmith?  It
> is for example a little strange that you decided to include "pure" but
> not "const."  If you handle visibility, you might as well consider
> throwing in externally_visible too, I guess.  As a stretch goal, the
> alias function attribute might be useful to exercise nasty paths in GCC
> IPA optimizations.
>

Thanks for the suggestion. I have added function attribute alias, const and
externally_visible in my proposal.
My bad, I forgot to add const.

Also, suggest some more attributes like alias which will help to exercise
different components of GCC, so that I can update my proposal accordingly.

>
> I assume Andi Kleen has seen this proposal and if he is fine with it, so
> am I.
>
Yes.

Thanks
Shubham


> Thanks,
>
> Martin
>
>

Re: GCC GSOC 2019

[Martin Liška]

On 4/3/19 6:31 PM, Martin Jambor wrote:
> Hello Shubham,
> 
> On Fri, Mar 29 2019, Shubham Narlawar wrote:
>> Hi, here is my proposal for the above idea. Please review and suggest
>> necessary changes.
>>
>> https://docs.google.com/document/d/11MNhuuD7dbwAfSW6ZgFrAys9My1Lw1PuMVcAqeNGr7A/edit?usp=sharing
> 
> I have had a quick look and the proposal seems very nice.
> 
> How did you select the attributes you want to implement in csmith?  It
> is for example a little strange that you decided to include "pure" but
> not "const."  If you handle visibility, you might as well consider
> throwing in externally_visible too, I guess.  As a stretch goal, the
> alias function attribute might be useful to exercise nasty paths in GCC
> IPA optimizations.
> 
> I assume Andi Kleen has seen this proposal and if he is fine with it, so
> am I. 
> 
> Thanks,
> 
> Martin
> 

Hi.

Just for the record, Martin Jambor asked me to co-mentor during time period
when Andi will be on vacation (if I'm correct).

I have couple of questions/ideas about the proposal:

1) I would not spend much time with nested functions, it's quite legacy
C extension
2) for functions, I would basically include add potential attribute:
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

see:
gcc/c-family/c-attribs.c:242
const struct attribute_spec c_common_attribute_table[] =
...

3) similarly for variables:
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes

4) and similarly for types
https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attributes

5) One big question about csmith I have. It's quite easy to come up with a 
test-case which
causes an ICE. But it's more difficult to come up with a test-case that is 
miscompiled
by a compiler. It's mainly due to an invalid behavior in the generated 
test-case.
One can theoretically catch that with sanitizers (ASAN, UBSAN, ...). But still, 
it's
not easy. Are you considering catching wrong-code issue?

Thanks,
Martin

Re: GCC GSOC 2019

[Martin Jambor]

Hello Shubham,

On Fri, Mar 29 2019, Shubham Narlawar wrote:
> Hi, here is my proposal for the above idea. Please review and suggest
> necessary changes.
>
> https://docs.google.com/document/d/11MNhuuD7dbwAfSW6ZgFrAys9My1Lw1PuMVcAqeNGr7A/edit?usp=sharing

I have had a quick look and the proposal seems very nice.

How did you select the attributes you want to implement in csmith?  It
is for example a little strange that you decided to include "pure" but
not "const."  If you handle visibility, you might as well consider
throwing in externally_visible too, I guess.  As a stretch goal, the
alias function attribute might be useful to exercise nasty paths in GCC
IPA optimizations.

I assume Andi Kleen has seen this proposal and if he is fine with it, so
am I. 

Thanks,

Martin

Re: GCC GSOC 2019

[Shubham Narlawar]

Hi, here is my proposal for the above idea. Please review and suggest
necessary changes.

https://docs.google.com/document/d/11MNhuuD7dbwAfSW6ZgFrAys9My1Lw1PuMVcAqeNGr7A/edit?usp=sharing

Thanks.
Shubham

On Mon, Feb 18, 2019 at 11:55 PM Martin Jambor  wrote:

> Hello Shubham,
>
> On Sun, Feb 10 2019, Shubham Narlawar wrote:
> > Hi,
> >
> > I am Shubham Narlawar. Currently, I am a Computer Engineering undergrad
> > student at Pune University, India. I am interested in contributing to GCC
> > for GSOC 2019.
> >
> > We have done a project from GCC GSOC 2018 idea list which is implementing
> > Csmith fuzzer leveraging GCC C Extensions under the guidance of Andi
> Kleen.
> >
> > Csmith is a C fuzzer which generates standard C code but no extensions.
> We
> > implemented few of GCC C extensions in Csmith (which now we call it as
> > "Extended Csmith"). Extended Csmith is now able to fuzz extensions along
> > with standard C code.
> >
> > Following GCC C Extensions are implemented in Csmith currently -
> > 1. Labels as Values (Computed Goto)
> > 2. Local Labels
> > 3. Typeof
> > 4. __int128 - Signed and unsigned integer of size 128 bits.
> > 5. Cast to Union
> > 6. Label attributes - hot cold
> > 7. Variable attributes - a) aligned
> > b) unused
> > c) section
> > 8. Binary constants
> > 9. Statement Expression
> >
> > 10. Transactional memory relaxed - tm_relaxed (not a GCC C extension)
> >
> > Note - Different Combinations of these extensions can be used while
> > generating random C code using extended csmith.
> >
> > Here is the github link of the project.
> > https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions
> >
> > Currently, We are running extended csmith on gcc10 of GCC Compile Farm
> > Project and found following bugs -
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89135
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89153
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87118
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
> >
> > We expect to find more bugs in GCC as the gcc compiler is being stress
> > tested now.
> >
> > Code coverage - Csmith vs Extended Csmith
> >
> >  Csmith i.e. [without gcc extn ]
> >   line - 35.2
> >   function - 43.2
> >   branch - 25.7
> >
> >   Extended Csmith [with gcc extn]
> >   line - 35.7
> >   function - 43.9
> >   branch - 26.1
> >
> >   %gain
> >   line - 0.5%
> >   function - 0.7%
> >   branch - 0.4%
> >
> > For GSOC 2019, I am proposing below project idea -
> >
> > Implementation of following extensions in the Csmith -
> > 1. Function attributes - aligned, alloc_align, always_inline, hot, cold,
> > deprecated, nothrow, used, etc
> > 2. Vector extensions
> > 3. Transactional Memory extensions
> > 4. Type attributes
> > and remaining GCC C extensions.
> >
> > Benefits to GCC -
> > 1. Increased code coverage.
> > 2. There is a possibility of finding more bugs after adding the above
> > extensions.
> >
>
> Thank you very much for sending us your project idea.  I have noted
> it down and am looking forward to your project submission (assuming
> Google approves us as a participating organization, of course).
>
> Meanwhile, if you have any technical questions, regarding the GCC
> extensions you listed above, feel free to ask here on the list.
>
> Thank you,
>
> Martin
>

Re: GCC GSOC 2019

[Martin Jambor]

Hello Shubham,

On Sun, Feb 10 2019, Shubham Narlawar wrote:
> Hi,
>
> I am Shubham Narlawar. Currently, I am a Computer Engineering undergrad
> student at Pune University, India. I am interested in contributing to GCC
> for GSOC 2019.
>
> We have done a project from GCC GSOC 2018 idea list which is implementing
> Csmith fuzzer leveraging GCC C Extensions under the guidance of Andi Kleen.
>
> Csmith is a C fuzzer which generates standard C code but no extensions. We
> implemented few of GCC C extensions in Csmith (which now we call it as
> "Extended Csmith"). Extended Csmith is now able to fuzz extensions along
> with standard C code.
>
> Following GCC C Extensions are implemented in Csmith currently -
> 1. Labels as Values (Computed Goto)
> 2. Local Labels
> 3. Typeof
> 4. __int128 - Signed and unsigned integer of size 128 bits.
> 5. Cast to Union
> 6. Label attributes - hot cold
> 7. Variable attributes - a) aligned
> b) unused
> c) section
> 8. Binary constants
> 9. Statement Expression
>
> 10. Transactional memory relaxed - tm_relaxed (not a GCC C extension)
>
> Note - Different Combinations of these extensions can be used while
> generating random C code using extended csmith.
>
> Here is the github link of the project.
> https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions
>
> Currently, We are running extended csmith on gcc10 of GCC Compile Farm
> Project and found following bugs -
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89135
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89153
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87118
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
>
> We expect to find more bugs in GCC as the gcc compiler is being stress
> tested now.
>
> Code coverage - Csmith vs Extended Csmith
>
>  Csmith i.e. [without gcc extn ]
>   line - 35.2
>   function - 43.2
>   branch - 25.7
>
>   Extended Csmith [with gcc extn]
>   line - 35.7
>   function - 43.9
>   branch - 26.1
>
>   %gain
>   line - 0.5%
>   function - 0.7%
>   branch - 0.4%
>
> For GSOC 2019, I am proposing below project idea -
>
> Implementation of following extensions in the Csmith -
> 1. Function attributes - aligned, alloc_align, always_inline, hot, cold,
> deprecated, nothrow, used, etc
> 2. Vector extensions
> 3. Transactional Memory extensions
> 4. Type attributes
> and remaining GCC C extensions.
>
> Benefits to GCC -
> 1. Increased code coverage.
> 2. There is a possibility of finding more bugs after adding the above
> extensions.
>

Thank you very much for sending us your project idea.  I have noted
it down and am looking forward to your project submission (assuming
Google approves us as a participating organization, of course).

Meanwhile, if you have any technical questions, regarding the GCC
extensions you listed above, feel free to ask here on the list.

Thank you,

Martin

GCC GSOC 2019

[Shubham Narlawar]

Hi,

I am Shubham Narlawar. Currently, I am a Computer Engineering undergrad
student at Pune University, India. I am interested in contributing to GCC
for GSOC 2019.

We have done a project from GCC GSOC 2018 idea list which is implementing
Csmith fuzzer leveraging GCC C Extensions under the guidance of Andi Kleen.

Csmith is a C fuzzer which generates standard C code but no extensions. We
implemented few of GCC C extensions in Csmith (which now we call it as
"Extended Csmith"). Extended Csmith is now able to fuzz extensions along
with standard C code.

Following GCC C Extensions are implemented in Csmith currently -
1. Labels as Values (Computed Goto)
2. Local Labels
3. Typeof
4. __int128 - Signed and unsigned integer of size 128 bits.
5. Cast to Union
6. Label attributes - hot cold
7. Variable attributes - a) aligned
b) unused
c) section
8. Binary constants
9. Statement Expression

10. Transactional memory relaxed - tm_relaxed (not a GCC C extension)

Note - Different Combinations of these extensions can be used while
generating random C code using extended csmith.

Here is the github link of the project.
https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions

Currently, We are running extended csmith on gcc10 of GCC Compile Farm
Project and found following bugs -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223

We expect to find more bugs in GCC as the gcc compiler is being stress
tested now.

Code coverage - Csmith vs Extended Csmith

 Csmith i.e. [without gcc extn ]
  line - 35.2
  function - 43.2
  branch - 25.7

  Extended Csmith [with gcc extn]
  line - 35.7
  function - 43.9
  branch - 26.1

  %gain
  line - 0.5%
  function - 0.7%
  branch - 0.4%

For GSOC 2019, I am proposing below project idea -

Implementation of following extensions in the Csmith -
1. Function attributes - aligned, alloc_align, always_inline, hot, cold,
deprecated, nothrow, used, etc
2. Vector extensions
3. Transactional Memory extensions
4. Type attributes
and remaining GCC C extensions.

Benefits to GCC -
1. Increased code coverage.
2. There is a possibility of finding more bugs after adding the above
extensions.

Thanks and Regards.
Shubham Narlawar