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

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Mar 25, 2019 at 05:41:26PM -0700, Andi Kleen wrote:
> sameeran joshi <gsocsameeran@gmail.com> writes:
> 
> > 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?
> 
> 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