Re: [GSOC-2019] - Csmith fuzzer leveraging GCC C Extensions

[Shubham Narlawar]

Thanks. I will use plain text.

On Thu, May 16, 2019 at 2:32 PM Jonathan Wakely  wrote:
>
> On Wed, 15 May 2019 at 10:24, Shubham Narlawar wrote:
> > I tried to send you Aligned patch and one csmith program but it bounces
> > back. I don't know why it happened. Sorry for sending mail 5 times. Sure, I
> > will reply to single thread.
>
> If you're trying to send email to the GCC lists you need to use plain
> text (no HTML emails) or it will get rejected:
> https://gcc.gnu.org/lists.html#policies

Re: [GSOC-2019] - Csmith fuzzer leveraging GCC C Extensions

[Jonathan Wakely]

On Wed, 15 May 2019 at 10:24, Shubham Narlawar wrote:
> I tried to send you Aligned patch and one csmith program but it bounces
> back. I don't know why it happened. Sorry for sending mail 5 times. Sure, I
> will reply to single thread.

If you're trying to send email to the GCC lists you need to use plain
text (no HTML emails) or it will get rejected:
https://gcc.gnu.org/lists.html#policies

Re: [GSOC-2019] - Csmith fuzzer leveraging GCC C Extensions

[Shubham Narlawar]

On Wed, May 15, 2019 at 2:23 PM Martin Liška  wrote:

> On 5/15/19 9:49 AM, Shubham Narlawar wrote:
> > void func_1();
> > void func_3();
> > .
> >
> > void foo1() __attribute__ ((weak, alias("func_1")));
> > void foo3() __attribute__ ((weak, alias("func_3")));
>
> Hi.
>
> In all emails that you sent there's no patch that will implement 'alias'
> attribute.
>
I have not implemented alias attribute yet. I will send it to github fork
for review after aligned attribute.

>
> Thanks,
> Martin
>

Re: [GSOC-2019] - Csmith fuzzer leveraging GCC C Extensions

[Shubham Narlawar]

On Wed, May 15, 2019 at 2:13 PM Martin Liška  wrote:

> On 5/15/19 9:49 AM, Shubham Narlawar wrote:
> > Hello Martin and community,
>
> Hi Shubham.
>
> Thank you for starting working on the project. There are some
> recommendations
> before we fully being:
>
> 1) I've recently received 5 emails that have very similar subject and it's
>unclear why that happened? When you e.g. forget to add something into
>an email, it's easier to reply to your email and just mention what
>was forgotten.
>

I tried to send you Aligned patch and one csmith program but it bounces
back. I don't know why it happened. Sorry for sending mail 5 times. Sure, I
will reply to single thread.


> 2) Please reply to this email thread and for each new functionality, please
>adjust email subject so that it's easier to orient.
>

> 3) I would recommend to make a separate branch for each functionality and
>send a branch name here. I can easily pull and don't have to apply a
> patch.
>
Sure.

>
> 4) Can we directly use pull requests into
> https://github.com/csmith-project/csmith ?
>I can comment the changes there if you want.
>

I have created a fork github.com/shubhamnarlawar77/csmith/tree/csmith-gcc
I will make branch of csmith-gcc and send patches to it so that you can
pull and review. After review, I will push patch into csmith-gcc fork. Does
this work for you?


> 5) I'm quite new to csmith, so be patient with me ;)
>
> 6) Are you familiar with coding style of CSmith? I can't verify changes in
> that area.
>
Yes. I am quite familiar with it.

>
> Thanks for working on that.
> Martin
>

Re: [GSOC-2019] - Csmith fuzzer leveraging GCC C Extensions

[Martin Liška]

On 5/15/19 9:49 AM, Shubham Narlawar wrote:
> void func_1();
> void func_3();
> .
> 
> void foo1() __attribute__ ((weak, alias("func_1")));
> void foo3() __attribute__ ((weak, alias("func_3")));

Hi.

In all emails that you sent there's no patch that will implement 'alias' 
attribute.

Thanks,
Martin

Re: [GSOC-2019] - Implement Csmith fuzzer leveraging GCC C Extensions.

[Martin Liška]

On 5/15/19 10:12 AM, Shubham Narlawar wrote:
> Hello Martin and community,
> 
> Below is attached patch for Function Attribute Aligned -
> 
> The command line option to generate aligned attribute is -
> --func-attr-aligned which can be found in ./csmith --help
> 
> Please review the patch and suggest changes if any.
> 
> The process of adding any extension is same -
> 1. Implement an extension
> 2. Send patch for review to community.
> 3. Test GCC compiler and report bugs if found any.
> 4. Push patch into github fork.
> Continue.
> 
> I have a query regarding C extension "function attribute alias". Is it 
> correct way to add aliasing for functions in csmith program as shown below -
> 
> e.g. In csmith program, output aliasing below function declaration looks like 
> -
> 
> //function---declarations--
> void func_1();
> void func_3();
> .
> 
> void foo1() __attribute__ ((weak, alias("func_1")));
> void foo3() __attribute__ ((weak, alias("func_3")));
> ..
> 
> Looking forward to do this project with GCC community.
> 
> Thanks
> Shubham
> 
> func_attr_aligned.patch
> 
> diff --git a/src/CGOptions.cpp b/src/CGOptions.cpp
> index b74375a..98c629b 100644
> --- a/src/CGOptions.cpp
> +++ b/src/CGOptions.cpp
> @@ -202,6 +202,7 @@ DEFINE_GETTER_SETTER_BOOL(fast_execution);
>  
>  //GCC C Extensions
>  DEFINE_GETTER_SETTER_BOOL(func_attr_inline);
> +DEFINE_GETTER_SETTER_BOOL(func_attr_aligned);
>  
>  void
>  CGOptions::set_default_builtin_kinds()
> diff --git a/src/CGOptions.h b/src/CGOptions.h
> index 76887b8..a1aa389 100644
> --- a/src/CGOptions.h
> +++ b/src/CGOptions.h
> @@ -474,6 +474,9 @@ public:
>   static bool func_attr_inline(void);
>  static bool func_attr_inline(bool p);
>  
> + static bool func_attr_aligned(void);
> +static bool func_attr_aligned(bool p);
> +

Hi.

There you have a different indentation.

>  private:
>   static bool enabled_builtin_kind(const string &kind);
>  
> @@ -623,6 +626,7 @@ private:
>  
>   //GCC C Extensions
>   static bool func_attr_inline_;
> + static bool func_attr_aligned_;
>  private:
>   CGOptions(void);
>   CGOptions(CGOptions &cgo);
> diff --git a/src/Function.cpp b/src/Function.cpp
> index 9935552..1a769db 100644
> --- a/src/Function.cpp
> +++ b/src/Function.cpp
> @@ -396,6 +396,7 @@ Function::Function(const string &name, const Type 
> *return_type)
>  {
>   FuncList.push_back(this);   // Add to global list 
> of functions.
>   func_attr_inline = false;
> + func_attr_aligned = false;
>  }
>  
>  Function::Function(const string &name, const Type *return_type, bool builtin)
> @@ -411,6 +412,7 @@ Function::Function(const string &name, const Type 
> *return_type, bool builtin)
>  {
>   FuncList.push_back(this);   // Add to global list 
> of functions.
>   func_attr_inline = false;
> + func_attr_aligned = false;
>  }
>  
>  Function *
> @@ -434,8 +436,11 @@ Function::make_random_signature(const CGContext& 
> cg_context, const Type* type, c
>   if (CGOptions::inline_function() && rnd_flipcoin(InlineFunctionProb))
>   f->is_inlined = true;
>  
> - if(CGOptions::func_attr_inline() && rnd_flipcoin(InlineFunctionProb))
> + if(CGOptions::func_attr_inline() && rnd_flipcoin(FuncAttrInline))
>   f->func_attr_inline = true;

Are you sure here? Why are you removing InlineFunctionProb of an unrelated 
option (inline)?

> +
> + if(CGOptions::func_attr_aligned() && rnd_flipcoin(FuncAttrAligned))
> +f->func_attr_aligned = true;
>   return f;
>  }>  
> @@ -487,8 +492,11 @@ Function::make_first(void)
>   // collect info about global dangling pointers
>   fm->find_dangling_global_ptrs(f);
>  
> - if(CGOptions::func_attr_inline() && rnd_flipcoin(InlineFunctionProb))
> + if(CGOptions::func_attr_inline() && rnd_flipcoin(FuncAttrInline))
>  f->func_attr_inline = true;

Same comment here.

> +
> + if(CGOptions::func_attr_aligned() && rnd_flipcoin(FuncAttrAligned))
> +f->func_attr_aligned = true;
>   return f;
>  }
>  
> @@ -562,6 +570,43 @@ Function::OutputForwardDecl(std::ostream &out)
>   OutputHeader(out);
>   if(func_attr_inline)
>   out << " __attribute__((always_inline))";
> + if(func_attr_aligned){
> + int probability__BIGGEST_ALIGNMENT__ = 38;
> + bool use__BIGGEST_ALIGNMENT__ = 
> rnd_flipcoin(probability__BIGGEST_ALIGNMENT__);
> + if (use__BIGGEST_ALIGNMENT__)
> + out << " 
> __attribute__((aligned(__BIGGEST_ALIGNMENT__)))";
> + else{
> + int value = 0;
> + int power = rnd_upto(8);
> + if (power == 0)
> + power++;
> + switch (power){
> + case 1:
> + value = 2;
> +   

Re: [GSOC-2019] - Csmith fuzzer leveraging GCC C Extensions

[Martin Liška]

On 5/15/19 9:49 AM, Shubham Narlawar wrote:
> Hello Martin and community,

Hi Shubham.

Thank you for starting working on the project. There are some recommendations
before we fully being:

1) I've recently received 5 emails that have very similar subject and it's
   unclear why that happened? When you e.g. forget to add something into
   an email, it's easier to reply to your email and just mention what
   was forgotten.

2) Please reply to this email thread and for each new functionality, please
   adjust email subject so that it's easier to orient.

3) I would recommend to make a separate branch for each functionality and
   send a branch name here. I can easily pull and don't have to apply a patch.

4) Can we directly use pull requests into 
https://github.com/csmith-project/csmith ?
   I can comment the changes there if you want.

5) I'm quite new to csmith, so be patient with me ;)

6) Are you familiar with coding style of CSmith? I can't verify changes in that 
area.

Thanks for working on that.
Martin

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: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[sameeran joshi]

On 4/4/19, Martin Jambor  wrote:
> Hi,
>
> On Wed, Apr 03 2019, sameeran joshi wrote:
>> On 4/3/19, Martin Jambor  wrote:
>>> Hello Joshi,
>>>
>>> On Mon, Apr 01 2019, sameeran joshi wrote:
 HI,
 Discussing the project with Andi, I have drafted a proposal, please
 review and suggest
 necessary changes.
 If some OpenMP experts from GCC have some ideas or changes please
 suggest.

 https://docs.google.com/document/d/1axElw-I5pTwcjI4iMle5NhLeRCcshIjH5ZHm3GGwsZU/edit?usp=sharing
>>>
>>> I will leave most of the evaluation on Andi (and assume he likes the
>>> proposal, by the way).  However, I have read the proposal, I like it and
>>> I consider it very useful but also possibly quite ambitious.  But we can
>>> adjust expectations as we go forward.
>>>
>>> Please consider fixing some of the formatting in the document,
>>> especially of the code snippets, sometimes they are a bit difficult to
>>
>> Thanks for pointing it, I have indented them.
>
> Great, it indeed is now much better.
>
>>
>>> read without any indentation.  That may be also the reason why I don't
>>> quite understand what is the relationship of omp tasks and loops or
>>> uninitialized local arrays.
>>
>> I have removed the location to insert for OMP tasks at 'uninitialized
>> local array initialization'.
>> Only kept it for as it was getting more complex.
>>
>> 1. while loops
>> 2. nested for loops
>
> OK.
>
>>
>> If you could suggest which constructs do you feel more ambitious?, so
>
> The one thing I am quite intrigued by is how exactly you will detect
> data races,


There could be 2 approaches to it:

1. Not changing the current generation grammar :
How?

  //This is done after statement is generated and after fact analysis of
statement is done, inside Statement::make_random()
  //whenever statement is generated, can set flag to indicate a data race in it.

check_and set_data_race_in_statement(){
 1.retrieve write vars from current statement (Effect.h)
 2.loop through all write vars and check is_shared(write_var)
 if true
 its a data race
 set some flag to indicate
 }


This labels each statement with a flag to indicate data race in the
statement, now after generation of a particular block, looping through
the statements and checking whether they have a data race,
if YES:(possible solutions )
 1.Neglect the block for parallel region ( may not be
efficient as may neglect most of the blocks)

 2. May be apply some synchronization constructs to the block.
if NO race:
 good to go with the block to be parallel.

Andi suggested "that will be hard after the fact", But I found Csmith
doing some Fact analysis (DFA analysis) in it's code base.
Which I didn't explore during the previous project.

Will need some help to investigate about Fact Analysis (Fact*.h) which Csmith
 already implements, also they maintain the current generation context
 (CG_Context.h). As I think would solve most of the problems?


2. Decide before you generate the block that is parallel( a block
would be explicitly selected as a parallel block (based on
probability) ) and then avoid generating any data races. (Andi
suggested )


   So, how do you avoid them?
  e.g.
LHS OP EXPRESSION

Whenever a LHS variable is selected, care needs to be taken
it's not a shared variable.This avoids the data races during
generation itself.
But this approach restricts the generation grammar, so only
writes to  local variables from that block will be present in the
block . Will this work?

The above function could now become something like
Statement::check_and_avoid_data_races_in_statement()


---
> but I assume a conservative but useful approach will not be
> too difficult to devise.

I feel the most time consuming and challenging part would be adding
the first extension, i.e the ' #pragma omp parallel'  pragma.
Do you have more suggestions ?

>
>> I could work on it to modify them.
>
> Don't worry about the remark too much.  The proposal looks solid.
>
> Martin
>

Thanks,
Sameeran Joshi

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: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[Martin Jambor]

Hi,

On Wed, Apr 03 2019, sameeran joshi wrote:
> On 4/3/19, Martin Jambor  wrote:
>> Hello Joshi,
>>
>> On Mon, Apr 01 2019, sameeran joshi wrote:
>>> HI,
>>> Discussing the project with Andi, I have drafted a proposal, please
>>> review and suggest
>>> necessary changes.
>>> If some OpenMP experts from GCC have some ideas or changes please
>>> suggest.
>>>
>>> https://docs.google.com/document/d/1axElw-I5pTwcjI4iMle5NhLeRCcshIjH5ZHm3GGwsZU/edit?usp=sharing
>>
>> I will leave most of the evaluation on Andi (and assume he likes the
>> proposal, by the way).  However, I have read the proposal, I like it and
>> I consider it very useful but also possibly quite ambitious.  But we can
>> adjust expectations as we go forward.
>>
>> Please consider fixing some of the formatting in the document,
>> especially of the code snippets, sometimes they are a bit difficult to
>
> Thanks for pointing it, I have indented them.

Great, it indeed is now much better.

>
>> read without any indentation.  That may be also the reason why I don't
>> quite understand what is the relationship of omp tasks and loops or
>> uninitialized local arrays.
>
> I have removed the location to insert for OMP tasks at 'uninitialized
> local array initialization'.
> Only kept it for as it was getting more complex.
>
> 1. while loops
> 2. nested for loops

OK.

>
> If you could suggest which constructs do you feel more ambitious?, so

The one thing I am quite intrigued by is how exactly you will detect
data races, but I assume a conservative but useful approach will not be
too difficult to devise.

> I could work on it to modify them.

Don't worry about the remark too much.  The proposal looks solid.

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: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[sameeran joshi]

On 4/3/19, Martin Jambor  wrote:
> Hello Joshi,
>
> On Mon, Apr 01 2019, sameeran joshi wrote:
>> HI,
>> Discussing the project with Andi, I have drafted a proposal, please
>> review and suggest
>> necessary changes.
>> If some OpenMP experts from GCC have some ideas or changes please
>> suggest.
>>
>> https://docs.google.com/document/d/1axElw-I5pTwcjI4iMle5NhLeRCcshIjH5ZHm3GGwsZU/edit?usp=sharing
>
> I will leave most of the evaluation on Andi (and assume he likes the
> proposal, by the way).  However, I have read the proposal, I like it and
> I consider it very useful but also possibly quite ambitious.  But we can
> adjust expectations as we go forward.
>
> Please consider fixing some of the formatting in the document,
> especially of the code snippets, sometimes they are a bit difficult to

Thanks for pointing it, I have indented them.

> read without any indentation.  That may be also the reason why I don't
> quite understand what is the relationship of omp tasks and loops or
> uninitialized local arrays.

I have removed the location to insert for OMP tasks at 'uninitialized
local array initialization'.
Only kept it for as it was getting more complex.

1. while loops
2. nested for loops

If you could suggest which constructs do you feel more ambitious?, so
I could work on it to modify them.
>
> But apart from that it is nice, thanks for applying,

Thanks,
Sameeran Joshi

>
> Martin
>

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[Martin Jambor]

Hello Joshi,

On Mon, Apr 01 2019, sameeran joshi wrote:
> HI,
> Discussing the project with Andi, I have drafted a proposal, please
> review and suggest
> necessary changes.
> If some OpenMP experts from GCC have some ideas or changes please suggest.
>
> https://docs.google.com/document/d/1axElw-I5pTwcjI4iMle5NhLeRCcshIjH5ZHm3GGwsZU/edit?usp=sharing

I will leave most of the evaluation on Andi (and assume he likes the
proposal, by the way).  However, I have read the proposal, I like it and
I consider it very useful but also possibly quite ambitious.  But we can
adjust expectations as we go forward.

Please consider fixing some of the formatting in the document,
especially of the code snippets, sometimes they are a bit difficult to
read without any indentation.  That may be also the reason why I don't
quite understand what is the relationship of omp tasks and loops or
uninitialized local arrays.

But apart from that it is nice, thanks for applying,

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: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[sameeran joshi]

HI,
Discussing the project with Andi, I have drafted a proposal, please
review and suggest
necessary changes.
If some OpenMP experts from GCC have some ideas or changes please suggest.

https://docs.google.com/document/d/1axElw-I5pTwcjI4iMle5NhLeRCcshIjH5ZHm3GGwsZU/edit?usp=sharing

Thanks,
Sameeran Joshi.

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[sameeran joshi]

On 3/26/19, Andi Kleen  wrote:
>> That is a correct diagnostics.
>>
>> See Canonical loop form.
>>
>> test-exprOne of the following:
>>  var relational-op b
>>  b relational-op var
>>
>> ( var relational-op b )
>> is neither of those.
>
> Still seems strange to fail for some meaningless brackets.
>
> But ok.
>
> -Andi
>

Re: [GSoC 2019] Proposal: Parallelize GCC With Threads

[Richard Biener]

On Sun, 31 Mar 2019, Giuliano Belinassi wrote:

> Hi,
> 
> I wrote my GSoC Proposal to the "Parallelize GCC with threads" project,
> and if someone is interested in it, I am linking the text here in order
> to get feedback. Please let me know if something is not entirely clear,
> or if there are any problems with the calendar, or if you have any
> suggestions. :-)
> 
> Link to the proposal:
> https://github.com/giulianobelinassi/proposta-gsoc/blob/master/proposta.pdf
> 
> GitHub seems mess up with the PDF hyperlinks in their viewer, therefore you 
> will
> need to download the PDF if you want to click on them, or use this
> mirror i've set:
> https://www.ime.usp.br/~belinass/GSoC-Proposal.pdf

Hi,

I've read the proposal and it is great - the planned tasks timeline
is solid and realistic.  Of course what will happen between
second and final evaluation depends a lot on the amount of issues
unconvered.

Thanks,
Richard.

> Thank you,
> Giuliano.
> 

-- 
Richard Biener 
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany;
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)

[GSoC 2019] Proposal: Parallelize GCC With Threads

[Giuliano Belinassi]

Hi,

I wrote my GSoC Proposal to the "Parallelize GCC with threads" project,
and if someone is interested in it, I am linking the text here in order
to get feedback. Please let me know if something is not entirely clear,
or if there are any problems with the calendar, or if you have any
suggestions. :-)

Link to the proposal:
https://github.com/giulianobelinassi/proposta-gsoc/blob/master/proposta.pdf

GitHub seems mess up with the PDF hyperlinks in their viewer, therefore you will
need to download the PDF if you want to click on them, or use this
mirror i've set:
https://www.ime.usp.br/~belinass/GSoC-Proposal.pdf

Thank you,
Giuliano.

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: [GSoC 2019]: Interested in "Make C/C++ not automatically promote memory_order_consume to memory_order_acquire"

[Martin Jambor]

Hello Akshatg,

On Tue, Mar 12 2019, Akshatg wrote:
> Hello all,
>
> I'm a 2nd year Master's student at IIT Bombay. I have taken advance 
> compiler related courses in the past semesters. I'm interested to work 
> on the project "Make C/C++ not automatically promote 
> memory_order_consume to memory_order_acquire" this summer. I have read 
> the documents shared.

We are glad that you find contributing to GCC interesting, I have
already talked with Paul about you and the project a little.

>
> Kindly, let me know what I can do next to make my proposal stronger?
>

If you have not done so yet, please look 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.  In your case, you
will most likely want to start at how built-in functions representing
atomic operations are defined in sync-builtins.def and used throughout
the compiler.  Grep is your friend.  Feel free to ask here on the list
if there is anything specific you don't understand or would like to
know.

Good luck,

Martin

Re: [GSoC 2019] No application template?

[김규래]

 
Hello,
Thanks for your guidance.
I adopted a little bit from the HPX form and the previous year's form that you 
provided.
Below is the link to my proposal yet submitted to GSoC.
I will happily receive any feedback before submitting.
https://docs.google.com/document/d/1UwrBOsiAXsZSClsq1r6tAEw6QdqUzJvgW74SQpcWlIU/edit?usp=sharing
 
Ray Kim.
 
-Original Message-
From: "Martin Jambor"
To: "김규래"; ;
Cc: "Jakub Jelinek";
Sent: 2019-03-26 (화) 08:32:51 (GMT+09:00)
Subject: Re: [GSoC 2019] No application template?
 
Hi,

On Sun, Mar 24 2019, 김규래 wrote:
> Hello,
> I was trying to write my application for GSoC 2019 but couldn't find an 
> application form for GCC.
> Some other organizations seem to have GSoC application forms/templates.
> The gcc GSoC wiki page doesn't mention any.
> Is the application format free? or did I miss it somewhere?

No, you did not miss anything, we do not have any specific application
format to follow.  In the OpenMP tread you sounded like you knew what
to do and why anyway.  But to at last give an example, last year this
was an application that would have been accepted if the applicant did
not retract it:
https://docs.google.com/document/d/1YkKYI3J-pKFfHLdxljWVoJ89l2oVGibxslIW3ikluz8/edit
(at least at the moment it i still available).

> If it is free, is there anything I should include else than what is mentioned 
> in [1, 2]
>  

Generally speaking, it is probably a good idea to accompany the proposed
project description with a brief motivation, an expected time-line (we
understand it is likely to change) and a brief introduction of your
technical background, skills and/or accomplishments.  The project
description is the most important part however (and each project is
perhaps best explained differently), we'll mostly judge your abilities
from your interactions with us, on mailing lists and IRC, rather than
from a CV.

If you share the proposal with us on this list some three or four work
days before submitting it, we are likely to have a look at it and
comment if we'd like something changed.

Good luck,

Martin


> Ray Kim
>  
> [1] https://www.drupal.org/node/59037
> [2] http://of-code.blogspot.com/2007/08/soc-experience-introduction.html

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[Andi Kleen]

> That is a correct diagnostics.
> 
> See Canonical loop form.
> 
> test-expr One of the following:
>   var relational-op b
>   b relational-op var
> 
> ( var relational-op b )
> is neither of those.

Still seems strange to fail for some meaningless brackets.

But ok.

-Andi

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[Jakub Jelinek]

On Tue, Mar 26, 2019 at 01:30:28PM +0530, sameeran joshi wrote:
> > I'd need to see an example of what you are talking about.
> 
>   int i;
>   #pragma omp parallel for
>   for (i = (0) ; (i< (20)) ; i++) {
>   printf ("\ntest expression fails due to brackets");
>   printf ("\n i< (20) works ");
>   printf ("\n (i< (20)) fails ");
>   }
> 
> commands: ~$ gcc fail_for.c -Wall -Wextra -fopenmp
> 
> fail_for.c: In function ‘main’:
> fail_for.c:5:17: error: invalid controlling predicate
>   for (i = (0) ; (i< (20)) ; i++) {
> ^

That is a correct diagnostics.

See Canonical loop form.

test-expr   One of the following:
var relational-op b
b relational-op var

( var relational-op b )
is neither of those.

> struct s{
> int f0;
> };
> void main (){
> int i;
> struct s var1 ;
> #pragma omp parallel for
> for (var1.f0 = 0 ; var1.f0< (20); var1.f0++) {
> 
> }
> }
> 
> swamimauli@swamimauli:~$ gcc fail_struct.c -Wall -Wextra -fopenmp
> fail_struct.c: In function ‘main’:
> fail_struct.c:9:14: error: expected iteration declaration or
> initialization before ‘var1’
>  for (var1.f0 = 0 ; var1.f0< (20); var1.f0++) {
>   ^~~~

Yeah, as I said, I believe the intent is that this is not valid, otherwise
the iterator var1.f0 could not be predetermined private, you can't write
private(var1.f0)
and all the compilers I've tried agree with me.

Jakub

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[sameeran joshi]

On 3/26/19, Jakub Jelinek  wrote:
> On Mon, Mar 25, 2019 at 05:41:26PM -0700, Andi Kleen wrote:
>> sameeran joshi  writes:
>>
>> > On 3/24/19, Andi Kleen  wrote:
>> >> On Sat, Mar 23, 2019 at 11:49:11PM +0530, sameeran joshi wrote:
>> >>> 1) check_structured_block_conditions()
>> >>>  checks for the conditions related to a structured block
>> >>>  1.no returns in block
>> >>
>> >> returns should be allowed inside statement expressions.
>> > If I am correct, we would create a new branch  "COMPsmith"(C OpenMP
>> > smith)(name will this work?)  from the master of Csmith and work on
>> > it, statement expression are in the "gcc c extensions" branch I guess
>> > which would be a separate branch.
>> >
>> > So it shouldn't allow return as well, right?
>>
>> Yes
>
> Yeah, break, return, throw that isn't caught within the body again and not
> rethrown are not valid, similarly say longjmp out of it, goto too.
> exit, abort are ok (the block is then single entry, no exit rather than
> single entry, single exit, but that is fine).
>
>> >> Yes check for continue too.
>> > referring this: http://forum.openmp.org/forum/viewtopic.php?f=3&t=458
>> > continue can be used but with some restriction as:
>> >
>> > "innermost associated loop may be curtailed by a continue statement "
>>
>> Ah you're right. Better don't do continue then.
>
> Why?  continue is just fine if it is in the body of the innermost loop.
> In OpenMP 4.5 the loops if collapsed had to be closely nested with no code
> at all in between (which is what GCC 9 still implements), so the only way
> to add invalid continue is to add it into statement expressions in the b,
> lb
> and incr expressions.
>
>> >> If yes that would seem like a gcc bug. I would file in bugzilla with a
>> >> simple test case.
>> >>
>> > Did you file it? can you please send me the bug id?
>>
>> I didn't. Can you show some simple example that errors first?
>>
>> Perhaps Jakub or some other OpenMP expert can also chime in.
>
> I'd need to see an example of what you are talking about.

int i;
#pragma omp parallel for
for (i = (0) ; (i< (20)) ; i++) {
printf ("\ntest expression fails due to brackets");
printf ("\n i< (20) works ");
printf ("\n (i< (20)) fails ");
}

commands: ~$ gcc fail_for.c -Wall -Wextra -fopenmp

fail_for.c: In function ‘main’:
fail_for.c:5:17: error: invalid controlling predicate
  for (i = (0) ; (i< (20)) ; i++) {
^
swamimauli@swamimauli:~$ gcc --version
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0

>
>> >>> 1.Can I use a struct field variable for initialization?:
>> >>>
>> >>> Whereas the 5.0 specification states:
>> >>> var operator lb
>> >>> var := variable of signed or unsigned type | variable of pointer type
>> >>> which obeys the specification rules.
>> >>>
>> >>> error:expected iteration declaration/initialization before 'g_371'
>> >>
>> >> Ok I guess it's not supported, so you can't.
>> > Any specific reason for not supporting struct variables as
>> > initialization, as the spec. doesn't impose any restriction
>>
>> Yes it seems like a gcc restriction. I would file a bug (feature
>> request) that one. It's good, these are the kind of things
>> the OpenMP fuzzing project should be finding.
>
> I can raise it on omp-lang, but I'm 100% sure the intent is to have only
> iterators which actually can be privatized, so:
> struct S { int s; void foo (); };
>
> void
> S::foo ()
> {
>   #pragma omp for
>   for (s = 0; s < 24; s++)
> ;
> }
>
> is fine (as one can in methods use non-static data members in private (s),
> but your example with obj.field iterator is rejected by all the compilers
> I've tried (gcc, icc, clang), so I guess we are just missing a restriction
> in the canonical loop form that
> \it{var} may not be part of another variable (as an array or structure
> element).
> for C and for C++ the with the exception for methods.
> Or say that var must be a base language identifier.
>

struct s{
int f0;
};
void main (){
int i;
struct s var1 ;
#pragma omp parallel for
for (var1.f0 = 0 ; var1.f0< (20); var1.f0++) {

}
}

swamimauli@swamimauli:~$ gcc fail_struct.c -Wall -Wextra -fopenmp
fail_struct.c: In function ‘main’:
fail_struct.c:9:14: error: expected iteration declaration or
initialization before ‘var1’
 for (var1.f0 = 0 ; var1.f0< (20); var1.f0++) {
  ^~~~
Thanks,
Sameeran Joshi
>   Jakub
>

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[Jakub Jelinek]

On Mon, Mar 25, 2019 at 05:41:26PM -0700, Andi Kleen wrote:
> sameeran joshi  writes:
> 
> > On 3/24/19, Andi Kleen  wrote:
> >> On Sat, Mar 23, 2019 at 11:49:11PM +0530, sameeran joshi wrote:
> >>> 1) check_structured_block_conditions()
> >>>   checks for the conditions related to a structured block
> >>>   1.no returns in block
> >>
> >> returns should be allowed inside statement expressions.
> > If I am correct, we would create a new branch  "COMPsmith"(C OpenMP
> > smith)(name will this work?)  from the master of Csmith and work on
> > it, statement expression are in the "gcc c extensions" branch I guess
> > which would be a separate branch.
> >
> > So it shouldn't allow return as well, right?
> 
> Yes

Yeah, break, return, throw that isn't caught within the body again and not
rethrown are not valid, similarly say longjmp out of it, goto too.
exit, abort are ok (the block is then single entry, no exit rather than
single entry, single exit, but that is fine).

> >> Yes check for continue too.
> > referring this: http://forum.openmp.org/forum/viewtopic.php?f=3&t=458
> > continue can be used but with some restriction as:
> >
> > "innermost associated loop may be curtailed by a continue statement "
> 
> Ah you're right. Better don't do continue then.

Why?  continue is just fine if it is in the body of the innermost loop.
In OpenMP 4.5 the loops if collapsed had to be closely nested with no code
at all in between (which is what GCC 9 still implements), so the only way
to add invalid continue is to add it into statement expressions in the b, lb
and incr expressions.

> >> If yes that would seem like a gcc bug. I would file in bugzilla with a
> >> simple test case.
> >>
> > Did you file it? can you please send me the bug id?
> 
> I didn't. Can you show some simple example that errors first?
> 
> Perhaps Jakub or some other OpenMP expert can also chime in.

I'd need to see an example of what you are talking about.

> >>> 1.Can I use a struct field variable for initialization?:
> >>>
> >>> Whereas the 5.0 specification states:
> >>> var operator lb
> >>> var := variable of signed or unsigned type | variable of pointer type
> >>> which obeys the specification rules.
> >>>
> >>> error:expected iteration declaration/initialization before 'g_371'
> >>
> >> Ok I guess it's not supported, so you can't.
> > Any specific reason for not supporting struct variables as
> > initialization, as the spec. doesn't impose any restriction
> 
> Yes it seems like a gcc restriction. I would file a bug (feature
> request) that one. It's good, these are the kind of things
> the OpenMP fuzzing project should be finding.

I can raise it on omp-lang, but I'm 100% sure the intent is to have only
iterators which actually can be privatized, so:
struct S { int s; void foo (); };

void
S::foo ()
{
  #pragma omp for
  for (s = 0; s < 24; s++)
;
}

is fine (as one can in methods use non-static data members in private (s),
but your example with obj.field iterator is rejected by all the compilers
I've tried (gcc, icc, clang), so I guess we are just missing a restriction
in the canonical loop form that
\it{var} may not be part of another variable (as an array or structure element).
for C and for C++ the with the exception for methods.
Or say that var must be a base language identifier.

Jakub

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[Andi Kleen]

sameeran joshi  writes:

> On 3/24/19, Andi Kleen  wrote:
>> On Sat, Mar 23, 2019 at 11:49:11PM +0530, sameeran joshi wrote:
>>> 1) check_structured_block_conditions()
>>> checks for the conditions related to a structured block
>>> 1.no returns in block
>>
>> returns should be allowed inside statement expressions.
> If I am correct, we would create a new branch  "COMPsmith"(C OpenMP
> smith)(name will this work?)  from the master of Csmith and work on
> it, statement expression are in the "gcc c extensions" branch I guess
> which would be a separate branch.
>
> So it shouldn't allow return as well, right?

Yes
>> Yes check for continue too.
> referring this: http://forum.openmp.org/forum/viewtopic.php?f=3&t=458
> continue can be used but with some restriction as:
>
> "innermost associated loop may be curtailed by a continue statement "

Ah you're right. Better don't do continue then.

>> If yes that would seem like a gcc bug. I would file in bugzilla with a
>> simple test case.
>>
> Did you file it? can you please send me the bug id?

I didn't. Can you show some simple example that errors first?

Perhaps Jakub or some other OpenMP expert can also chime in.

>>
>>>
>>>
>>> 1.Can I use a struct field variable for initialization?:
>>>
>>> Whereas the 5.0 specification states:
>>> var operator lb
>>> var := variable of signed or unsigned type | variable of pointer type
>>> which obeys the specification rules.
>>>
>>> error:expected iteration declaration/initialization before 'g_371'
>>
>> Ok I guess it's not supported, so you can't.
> Any specific reason for not supporting struct variables as
> initialization, as the spec. doesn't impose any restriction

Yes it seems like a gcc restriction. I would file a bug (feature
request) that one. It's good, these are the kind of things
the OpenMP fuzzing project should be finding.


-Andi

Re: [GSoC 2019] No application template?

[Martin Jambor]

Hi,

On Sun, Mar 24 2019, 김규래 wrote:
> Hello,
> I was trying to write my application for GSoC 2019 but couldn't find an 
> application form for GCC.
> Some other organizations seem to have GSoC application forms/templates.
> The gcc GSoC wiki page doesn't mention any.
> Is the application format free? or did I miss it somewhere?

No, you did not miss anything, we do not have any specific application
format to follow.  In the OpenMP tread you sounded like you knew what
to do and why anyway.  But to at last give an example, last year this
was an application that would have been accepted if the applicant did
not retract it:
https://docs.google.com/document/d/1YkKYI3J-pKFfHLdxljWVoJ89l2oVGibxslIW3ikluz8/edit
(at least at the moment it i still available).

> If it is free, is there anything I should include else than what is mentioned 
> in [1, 2]
>  

Generally speaking, it is probably a good idea to accompany the proposed
project description with a brief motivation, an expected time-line (we
understand it is likely to change) and a brief introduction of your
technical background, skills and/or accomplishments.  The project
description is the most important part however (and each project is
perhaps best explained differently), we'll mostly judge your abilities
from your interactions with us, on mailing lists and IRC, rather than
from a CV.

If you share the proposal with us on this list some three or four work
days before submitting it, we are likely to have a look at it and
comment if we'd like something changed.

Good luck,

Martin


> Ray Kim
>  
> [1] https://www.drupal.org/node/59037
> [2] http://of-code.blogspot.com/2007/08/soc-experience-introduction.html

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[sameeran joshi]

On 3/24/19, Andi Kleen  wrote:
> On Sat, Mar 23, 2019 at 11:49:11PM +0530, sameeran joshi wrote:
>> 1) check_structured_block_conditions()
>>  checks for the conditions related to a structured block
>>  1.no returns in block
>
> returns should be allowed inside statement expressions.
If I am correct, we would create a new branch  "COMPsmith"(C OpenMP
smith)(name will this work?)  from the master of Csmith and work on
it, statement expression are in the "gcc c extensions" branch I guess
which would be a separate branch.

So it shouldn't allow return as well, right?
>
>>  2.no gotos
>>  3.no breaks
>> and accordingly labels the blocks as structured block, for example
>>  for (){
>>  //unstructured
>> //block 1
>> if(){
>>  //unstructured
>> //block 2
>> if(){
>> //block 3
>>  //structured
>>   1.no gotos
>>  2.no breaks
>>  3.no return
>>  4.Do I need to check continue as well?
>
> Yes check for continue too.
referring this: http://forum.openmp.org/forum/viewtopic.php?f=3&t=458
continue can be used but with some restriction as:

"innermost associated loop may be curtailed by a continue statement "

Can you please elaborate this with some simple example?
IIUC , we can use continue for innermost loop blocks and their sibling
nodes, but not the parent blocks.
>
>> This applies mostly when the break,goto,return statements have some
>> probability of generation.
>> Another workaround I think(which would increase the generation of more
>> OpenMP constructs)is to make probabilities of above statements to '0'
>
> Sure, of course only within the structured expressions.
>
>> For the following code:
>> struct S1 {
>> int f0;
>> };
>> global variable:
>> static struct S1 g_371 = {0x54L};
>>
>> void main ( ){
>>  #pragma omp parallel for
>>  for (g_371.f0 = (-3); (g_371.f0 >= (-27)) ; g_371.f0 =
>> safe_sub_func_int32_t_s_s(g_371.f0, 2))
>>  {/* block id: 1 */
>>  structured block
>>  }
>> }
>> I have following 3 questions in regards to usage of openmp.
>>
>> 0.Can't I use a '(test)' a 'bracket' for a 'test' expression?
>> error:invalid controlling predicate
>> If I try removing the brackets the program works fine.
>
>
> You mean it errors for
>  for (g_371.f0 = (-3); (g_371.f0 >= (-27)) ; g_371.f0 =
> safe_sub_func_int32_t_s_s(g_371.f0, 2))
>
> and works for
>
>  for (g_371.f0 = (-3); g_371.f0 >= (-27) ; g_371.f0 =
> safe_sub_func_int32_t_s_s(g_371.f0, 2))
>
> ?
yes
>
> If yes that would seem like a gcc bug. I would file in bugzilla with a
> simple test case.
>
Did you file it? can you please send me the bug id?
>
>>
>>
>> 1.Can I use a struct field variable for initialization?:
>>
>> Whereas the 5.0 specification states:
>> var operator lb
>> var := variable of signed or unsigned type | variable of pointer type
>> which obeys the specification rules.
>>
>> error:expected iteration declaration/initialization before 'g_371'
>
> Ok I guess it's not supported, so you can't.
Any specific reason for not supporting struct variables as
initialization, as the spec. doesn't impose any restrictions.

>
>>
>>
>> 2.Consider a case where I need to increment the variable:
>>
>> Considering the grammar of Csmith, in increment expression I need to
>> use function safe_sub_func_int32_t_s_s(g_371.f0, 2)
>> the function decrements the variable(same as g_371.f0 = g_371.f0-1 )
>> but it does some checks for the bounds, which are essential for
>> checking the undefined conditions.
>
> Maybe could make the index only unsigned, then ++ would work.
> We definitely need increment expressions to be useful.
>
> And perhaps have an command line option to allow unchecked signed increment
> for this.
>>
>> What do you think about adding command lines so as to disable
>> generation of such increment expressions so it follows spec 5.0
>
> We need them, otherwise too much useful OpenMP won't be generated.

I was thinking about say, --no-func-as-incr will not generate safe_*
functions in increment expressions of for statement, but rather
generate simple and valid increment statements.

I am working on proposal currently and the timeline, will try sending
in couple of days.
>
> -Andi
>

[GSoC 2019] No application template?

[김규래]

Hello,
I was trying to write my application for GSoC 2019 but couldn't find an 
application form for GCC.
Some other organizations seem to have GSoC application forms/templates.
The gcc GSoC wiki page doesn't mention any.
Is the application format free? or did I miss it somewhere?
If it is free, is there anything I should include else than what is mentioned 
in [1, 2]
 
Ray Kim
 
[1] https://www.drupal.org/node/59037
[2] http://of-code.blogspot.com/2007/08/soc-experience-introduction.html

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[Andi Kleen]

On Sat, Mar 23, 2019 at 11:49:11PM +0530, sameeran joshi wrote:
> 1) check_structured_block_conditions()
>   checks for the conditions related to a structured block
>   1.no returns in block

returns should be allowed inside statement expressions.

>   2.no gotos
>   3.no breaks
> and accordingly labels the blocks as structured block, for example
>   for (){
>   //unstructured
> //block 1
> if(){
>   //unstructured
> //block 2
> if(){
> //block 3
>   //structured
>1.no gotos
>   2.no breaks
>   3.no return
>   4.Do I need to check continue as well?

Yes check for continue too.

> This applies mostly when the break,goto,return statements have some
> probability of generation.
> Another workaround I think(which would increase the generation of more
> OpenMP constructs)is to make probabilities of above statements to '0'

Sure, of course only within the structured expressions.

> For the following code:
> struct S1 {
> int f0;
> };
> global variable:
> static struct S1 g_371 = {0x54L};
> 
> void main ( ){
>   #pragma omp parallel for
>   for (g_371.f0 = (-3); (g_371.f0 >= (-27)) ; g_371.f0 =
> safe_sub_func_int32_t_s_s(g_371.f0, 2))
>   {/* block id: 1 */
>   structured block
>   }
> }
> I have following 3 questions in regards to usage of openmp.
> 
> 0.Can't I use a '(test)' a 'bracket' for a 'test' expression?
> error:invalid controlling predicate
> If I try removing the brackets the program works fine.


You mean it errors for
 for (g_371.f0 = (-3); (g_371.f0 >= (-27)) ; g_371.f0 = 
safe_sub_func_int32_t_s_s(g_371.f0, 2))

and works for

 for (g_371.f0 = (-3); g_371.f0 >= (-27) ; g_371.f0 = 
safe_sub_func_int32_t_s_s(g_371.f0, 2))

?

If yes that would seem like a gcc bug. I would file in bugzilla with a simple 
test case.


> 
> 
> 1.Can I use a struct field variable for initialization?:
> 
> Whereas the 5.0 specification states:
> var operator lb
> var := variable of signed or unsigned type | variable of pointer type
> which obeys the specification rules.
> 
> error:expected iteration declaration/initialization before 'g_371'

Ok I guess it's not supported, so you can't.

> 
> 
> 2.Consider a case where I need to increment the variable:
> 
> Considering the grammar of Csmith, in increment expression I need to
> use function safe_sub_func_int32_t_s_s(g_371.f0, 2)
> the function decrements the variable(same as g_371.f0 = g_371.f0-1 )
> but it does some checks for the bounds, which are essential for
> checking the undefined conditions.

Maybe could make the index only unsigned, then ++ would work.
We definitely need increment expressions to be useful.

And perhaps have an command line option to allow unchecked signed increment
for this.
> 
> What do you think about adding command lines so as to disable
> generation of such increment expressions so it follows spec 5.0

We need them, otherwise too much useful OpenMP won't be generated.

-Andi

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[sameeran joshi]

sions. Fuzzers like csmith are
>> fairly good at finding compiler bugs. But they only generate standard
>> C, but no extensions. GCC has many extensions, which are not covered.
>> It would be good to extend a fuzzer like csmith to fuzz extensions
>> like OpenMP, attributes, vector extensions, etc. Then run the fuzzer
>> and report compiler bugs.
>>
>> since June 2018 under the guidance of mentor Andi Kleen.
>> I worked on generating GCC C language extensions here is the link
>> (coverage reports,implemented extension's list,bugs found,test cases,
>> and usage are in README file on github)
>> github Link:
>> https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions
>>
>> We choose this as our university project as well, and are still
>> fuzzing the extensions on compiler farm.
>>
>> Based on the previous work I would like to propose the following idea
>> for GSoC 2019:
>> Extending Csmith for OpenMP extensions.
>>
>> I would implement following constructs of OpenMP
>>
>> 1.PARALLEL CONSTRUCT
>> 2.WORKSHARING CONSTRUCTS -
>>   2.1 sections
>>   2.2 single
>>   2.3 loop constructs
>>   2.4 master construct
>> 3.TEAMS CONSTRUCT
>> 4.TASKING CONSTRUCT -
>>   4.1 task
>>   4.2 taskloop
>>   4.3 taskloop simd
>>   4.4 taskyield
>> 5.SYNCHRONIZATION CONSTRUCTS -
>>   5.1 critical
>>   5.2 atomic
>>   5.3 barrier
>>   5.4 taskwait
>>   5.5 taskgroup
>> 6.DATA SHARING ATTRIBUTES -
>>   6.1 private
>>   6.2 public
>>   6.3 firstprivate
>>   6.4 lastprivate
>> Also, I would like to work on the target constrains if time permits.
>> The main challenge what I think would be to ensure that there aren't
>> any data races and data conflicts so that the parallelized program is
>> not undefined.
>>
>> Usage for the GCC community :
>> 1. It might have slight large increments in code coverage and trigger
>> a lot of unique code .
>>
>> I have watched
>>A "Hands-on" Introduction to OpenMP | Tim Mattson, Intel all 4
>> parts
>>https://www.youtube.com/watch?v=pRtTIW9-Nr0
>>
>> I have started reading the specification of latest 5.0 standard.
>> Please suggest if this could be an interesting idea for upcoming GSoC ?
>>
>
> Indeed it is, you clearly have it thought out very well.  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.
>
> Good luck diving into the OpenMP spec and thank you,
>
> Martin
>
>
>

[GSoC 2019]: Interested in "Make C/C++ not automatically promote memory_order_consume to memory_order_acquire"

[Akshatg]

Hello all,

I'm a 2nd year Master's student at IIT Bombay. I have taken advance 
compiler related courses in the past semesters. I'm interested to work 
on the project "Make C/C++ not automatically promote 
memory_order_consume to memory_order_acquire" this summer. I have read 
the documents shared.


Kindly, let me know what I can do next to make my proposal stronger?

Thanks,
Akshat

[GSoC 2019]: Interested in "Make C/C++ not automatically promote memory_order_consume to memory_order_acquire"

[akshatg]

Hello all,

I am a 2nd year Master's student at IIT Bombay. The project "Make C/C++ 
not automatically promote memory_order_consume to memory_order_acquire" 
caught my eye and I would like to be the part of it. I have taken 
advance compiler courses in past semesters. I have already build gcc and 
have gone through this document P0190R4:Proposal for New memory order 
consume Definition 
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf). 
Can anyone suggest some more prerequisites ?


Thanks,
Akshat Garg

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

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[Martin Jambor]

Hello Sameeran,

On Sun, Feb 10 2019, sameeran joshi wrote:
> Hi,I am an undergraduate student currently in final year of computer
> science and engineering degree course from Pune University, India. I
> and Shubham have been working on Last year's GSoC project idea :
>
> Implement a fuzzer leveraging GCC extensions. Fuzzers like csmith are
> fairly good at finding compiler bugs. But they only generate standard
> C, but no extensions. GCC has many extensions, which are not covered.
> It would be good to extend a fuzzer like csmith to fuzz extensions
> like OpenMP, attributes, vector extensions, etc. Then run the fuzzer
> and report compiler bugs.
>
> since June 2018 under the guidance of mentor Andi Kleen.
> I worked on generating GCC C language extensions here is the link
> (coverage reports,implemented extension's list,bugs found,test cases,
> and usage are in README file on github)
> github Link:   https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions
>
> We choose this as our university project as well, and are still
> fuzzing the extensions on compiler farm.
>
> Based on the previous work I would like to propose the following idea
> for GSoC 2019:
> Extending Csmith for OpenMP extensions.
>
> I would implement following constructs of OpenMP
>
> 1.PARALLEL CONSTRUCT
> 2.WORKSHARING CONSTRUCTS -
>   2.1 sections
>   2.2 single
>   2.3 loop constructs
>   2.4 master construct
> 3.TEAMS CONSTRUCT
> 4.TASKING CONSTRUCT -
>   4.1 task
>   4.2 taskloop
>   4.3 taskloop simd
>   4.4 taskyield
> 5.SYNCHRONIZATION CONSTRUCTS -
>   5.1 critical
>   5.2 atomic
>   5.3 barrier
>   5.4 taskwait
>   5.5 taskgroup
> 6.DATA SHARING ATTRIBUTES -
>   6.1 private
>   6.2 public
>   6.3 firstprivate
>   6.4 lastprivate
> Also, I would like to work on the target constrains if time permits.
> The main challenge what I think would be to ensure that there aren't
> any data races and data conflicts so that the parallelized program is
> not undefined.
>
> Usage for the GCC community :
> 1. It might have slight large increments in code coverage and trigger
> a lot of unique code .
>
> I have watched
>A "Hands-on" Introduction to OpenMP | Tim Mattson, Intel all 4 
> parts
>https://www.youtube.com/watch?v=pRtTIW9-Nr0
>
> I have started reading the specification of latest 5.0 standard.
> Please suggest if this could be an interesting idea for upcoming GSoC ?
>

Indeed it is, you clearly have it thought out very well.  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.

Good luck diving into the OpenMP spec and thank you,

Martin

Re: GSoC 2019

[Martin Jambor]

Hello Parashuram,

On Tue, Feb 12 2019, Shourya IIT B wrote:
> Respected Sir,
>
>I am Parashuram Shourya from India. Currently, I am doing my
> Master’s in Geoinformatics from Centre of Studies in Resources
> Engineering(CSRE),
> Indian Institute of Technology Bombay(IITB). I have a Bachelor's degree in
> Computer Science and Engineering.
>
> Currently, I am learning Machine Learning and High-Performance Computing. I
> have vast programming experience in C, C++, Python
>
>   I would love to contribute to GNU Compiler Collection in the upcoming
> Google Summer of Code 2019. I would be very grateful to get any directions
> to start with so that I can pursue and participate in GSoC 2019 with your
> organization.

we are delighted you found contributing to GCC interesting.  Please look
again at the "Before you apply" section of our GSoC wiki page at
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, if you still find contributing to GCC appealing, 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 which idea
you liked best and what your thoughts about it are.

Good luck,

Martin

GSoC 2019

[Shourya IIT B]

Respected Sir,

   I am Parashuram Shourya from India. Currently, I am doing my
Master’s in Geoinformatics from Centre of Studies in Resources
Engineering(CSRE),
Indian Institute of Technology Bombay(IITB). I have a Bachelor's degree in
Computer Science and Engineering.

Currently, I am learning Machine Learning and High-Performance Computing. I
have vast programming experience in C, C++, Python

  I would love to contribute to GNU Compiler Collection in the upcoming
Google Summer of Code 2019. I would be very grateful to get any directions
to start with so that I can pursue and participate in GSoC 2019 with your
organization.

[GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[sameeran joshi]

Hi,I am an undergraduate student currently in final year of computer
science and engineering degree course from Pune University, India. I
and Shubham have been working on Last year's GSoC project idea :

Implement a fuzzer leveraging GCC extensions. Fuzzers like csmith are
fairly good at finding compiler bugs. But they only generate standard
C, but no extensions. GCC has many extensions, which are not covered.
It would be good to extend a fuzzer like csmith to fuzz extensions
like OpenMP, attributes, vector extensions, etc. Then run the fuzzer
and report compiler bugs.

since June 2018 under the guidance of mentor Andi Kleen.
I worked on generating GCC C language extensions here is the link
(coverage reports,implemented extension's list,bugs found,test cases,
and usage are in README file on github)
github Link:   https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions

We choose this as our university project as well, and are still
fuzzing the extensions on compiler farm.

Based on the previous work I would like to propose the following idea
for GSoC 2019:
Extending Csmith for OpenMP extensions.

I would implement following constructs of OpenMP

1.PARALLEL CONSTRUCT
2.WORKSHARING CONSTRUCTS -
  2.1 sections
  2.2 single
  2.3 loop constructs
  2.4 master construct
3.TEAMS CONSTRUCT
4.TASKING CONSTRUCT -
  4.1 task
  4.2 taskloop
  4.3 taskloop simd
  4.4 taskyield
5.SYNCHRONIZATION CONSTRUCTS -
  5.1 critical
  5.2 atomic
  5.3 barrier
  5.4 taskwait
  5.5 taskgroup
6.DATA SHARING ATTRIBUTES -
  6.1 private
  6.2 public
  6.3 firstprivate
  6.4 lastprivate
Also, I would like to work on the target constrains if time permits.
The main challenge what I think would be to ensure that there aren't
any data races and data conflicts so that the parallelized program is
not undefined.

Usage for the GCC community :
1. It might have slight large increments in code coverage and trigger
a lot of unique code .

I have watched
   A "Hands-on" Introduction to OpenMP | Tim Mattson, Intel all 4 parts
   https://www.youtube.com/watch?v=pRtTIW9-Nr0

I have started reading the specification of latest 5.0 standard.
Please suggest if this could be an interesting idea for upcoming GSoC ?

Thanks,
Sameeran Joshi

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

GCC and GSoC 2019

[Martin Jambor]

Hi,

today I have filed an application on behalf of the GCC project to be a
mentoring organization in the year 2019 of Google Summer of Code.  I'd
like to have the following requests and announcements:

1. First and foremost, I would like to ask all (moderately) seasoned GCC
   contributors to consider mentoring a student 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, of course.

2. I would like to thank a lot to those who have already confirmed that
   they are willing to mentor a GSoC project.

3. 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, but please be aware that we can only make use the
   suggestion it if we find a mentor.  I might mention them on the wiki,
   but only less prominently.

4. All knowledgeable GCC folk are invited to go over
   https://gcc.gnu.org/wiki/SummerOfCode and simply remove any outdated
   or otherwise really bad project suggestions.  I would especially want
   to ask GFortran and to a lesser extent C++ people to do so.

5. Please continue helping (prospective) students figure stuff out about
   GCC like you always do.

6. I intend to be the main "org admin" for GCC organization, I have
   asked Prathamesh Kulkarni and Honza Hubička to be my co-admins,
   because we must have at least two.  If anybody else would like to join
   us, let me know.

More information together with GSoC 2019 time line is available at
https://summerofcode.withgoogle.com

Thank you, let's hope we attract some good young talent this year.

Martin