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
