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

[sameeran joshi <gsocsameeran at gmail dot com>]

Hi,
I tried doing a basic/incomplete patch(needs more detailed conditions
check) for implementing a structured block in Csmith code base.
The structured block is almost needed for most of the constructs which
would be further implemented.
0)
The patch identifies and labels each block(after block created) as
leaf and non leaf block.
example:
        for (){
                //block 1
                if(){
                        //block 2
                        if(){
                                //block 3
                        }
			else{
				//block4
			}
                }
        }
leaf blocks:
	block3, block4
non-leaf:block1
		
1) check_structured_block_conditions()
	checks for the conditions related to a structured block
	1.no returns in block
	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?
                        }
			else{
				//block4
				//unstructured
				return ;
			}
                }
        }
	
structured:block3
unstructured: block1,2(one of the childs is unstructured), block4

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'
so code generated will have all structured blocks, which aids in
implementing the future OpenMP pargmas.

I have some questions regarding OpenMP:

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.


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'


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.

but openmp compiler gives following error:
error: invalid increment expression
Spec 5.0 needs something like var++, var = var +incr, etc...

How do I overcome this case, any workaround for this, but still using
the safe_sub_func_int32_t_s_s() ?

What do you think about adding command lines so as to disable
generation of such increment expressions so it follows spec 5.0

Thanks.
======================
diff --git a/src/Block.cpp b/src/Block.cpp
index ab2fe14..0928ad3 100644
--- a/src/Block.cpp
+++ b/src/Block.cpp
@@ -186,18 +186,60 @@ Block::make_random(CGContext &cg_context, bool looping)
 	}

 	// perform DFA analysis after creation
+	//for ex. 4 statements were created inside a block, but
+	//after DFA analysis they were removed

+	//function checks for leaf block, if yes then sets 'leaf_block' = true
+	b->set_leaf_or_nonleaf_block(b);
+	//check for structuredness
+	//function blocks are not structured, due to return
+	//need a more detailed conditions for above case
+	//arrayOp is in itself a structured block statement
+	if (curr_func->blocks[0] == b){//optimizes a bit
+		b->IsStructured = false;
+	}
+	else{
+		if (b->is_leaf_block ()){
+			if (b->check_structured_block_conditions() ){ // if true
+				//logic of struc block
+				b->IsStructured = true;
+			}
+			else{//not a structured block
+				b->IsStructured = false;
+			}
+		}
+		else{//a parent block
+			 if (b->check_structured_block_conditions() ){ // if true
+                                //logic of struc block
+				//wait the internal blocks remain to check
+				//1.get internal blocks
+				vector<const Block*> internal_blks;
+				for (size_t i =0 ; i< b->stms.size() ; i++)
+					b->stms[i]->get_blocks(internal_blks);
+
+				bool internal_block_fails=false;
+				for (size_t k = 0; k < internal_blks.size(); k++){
+					if(!internal_blks[k]->IsStructured){
+						internal_block_fails = true;
+						break;
+					}
+				}
+				(internal_block_fails == true) ? (b->IsStructured = false ) :
(b->IsStructured = true);
+                        }
+                        else{//not a structured block
+                                b->IsStructured = false;
+                        }
+
+		}
+	}

 	curr_func->stack.pop_back();


 		return NULL;
@@ -248,7 +290,49 @@ Block::make_random(CGContext &cg_context, bool looping)
 	}
 	return b;
 }
+//need to call after DFA analysis,else some statements removed
+//we check for for and if statements ( as have blocks to these statements )
+//if above statements not present it's a leaf node else a parent one
+
+void Block::set_leaf_or_nonleaf_block(Block *b){
+	b->leaf_block = true;//assume block is leaf,rule out later
+	for (int i =0 ; i<b->stms.size() ; i++){
+		if ( (b->stms[i]->eType == eFor) || (b->stms[i]->eType == eIfElse)
){ //if a for/ if statement.do we need to check any more?
+			b->leaf_block = false;
+		}
+	}
+}
+//checks whether block is a leaf
+bool Block::is_leaf_block(){
+	if (this->leaf_block)
+		return true;
+	else
+		return false;
+}
+bool Block::check_structured_block_conditions(){
+	//write here
+	size_t i ;
+	for (i = 0 ; i < this->stms.size(); i++){
+		if (this->stms[i]->eType == eReturn)
+			return false;
+		if (this->stms[i]->eType == eBreak)
+			return false;
+		if (this->stms[i]->eType == eGoto)
+			return false;
+		//continue is alowed,right?
+	//1.if no return
+	//2.no break
+	//3. no statement goto
+	//if no label present-hard
+	}
+	return true;//still need more detailed analysis
+}
+bool Block::is_structured_block(){
+	if (this->IsStructured)
+		return true;
+	else
+		return false;
+}
 /*
  *
  */
@@ -296,7 +380,7 @@ Block::~Block(void)
 	local_vars.clear();
 	macro_tmp_vars.clear();
 }
-
+//new temp variable created and stored in macro_tmp_vars(mentioned below)

 std::string
 Block::create_new_tmp_var(enum eSimpleType type) const
@@ -368,6 +452,17 @@ Block::Output(std::ostream &out, FactMgr* fm, int
indent) const
 //blockid
 	std::ostringstream ss;
 	ss << "block id: " << stm_id;
+	if (IsStructured){
+		outputln(out);
+		output_tab(out, indent);
+		output_comment_line (out , "structured");
+	}
+	else{
+		outputln(out);
+		output_tab(out, indent);
+		output_comment_line (out , "un structured");
+	}
+	output_tab(out, indent);
 	output_comment_line(out, ss.str());

 	if(CGOptions::stmt_expr()){
diff --git a/src/Block.h b/src/Block.h
index 23c939f..79f95a6 100644
--- a/src/Block.h
+++ b/src/Block.h
@@ -132,6 +132,14 @@ public:

         bool func_start_stmt_expr = false;

+//data variables
+	bool leaf_block ;//is it good if not initialized in constructor?
+	bool IsStructured ;
+//member functions
+	void set_leaf_or_nonleaf_block(Block *b);
+	bool is_leaf_block();
+	bool check_structured_block_conditions();
+	bool is_structured_block();
 private:

 	bool depth_protect;


On 2/18/19, Martin Jambor <mjambor@suse.cz> wrote:
> 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
>
>
>