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?
>
>> 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
>
