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

[sameeran joshi <gsocsameeran at gmail dot com>]

On 3/24/19, Andi Kleen <ak@linux.intel.com> 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
>