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

[Andi Kleen <ak at linux dot intel dot com>]

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