sameeran joshi <gsocsamee...@gmail.com> writes: > On 3/24/19, Andi Kleen <a...@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 >> 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. >> 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. >> >>> >>> >>> 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. -Andi
