This is the mail archive of the
mailing list for the GCC project.
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
- From: Martin Jambor <mjambor at suse dot cz>
- To: sameeran joshi <gsocsameeran at gmail dot com>, gcc at gcc dot gnu dot org
- Cc: Andi Kleen <ak at linux dot intel dot com>
- Date: Mon, 18 Feb 2019 19:22:08 +0100
- Subject: Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
- References: <CAKz4L0ER_F1N=gxq75pS0=vN5zayDivOCNYz5WZkOX78aDO0KA@mail.gmail.com>
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
> 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,