On 3/26/19, Jakub Jelinek <ja...@redhat.com> wrote:
> On Mon, Mar 25, 2019 at 05:41:26PM -0700, Andi Kleen wrote:
>> 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
>
> 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.
int i;
#pragma omp parallel for
for (i = (0) ; (i< (20)) ; i++) {
printf ("\ntest expression fails due to brackets");
printf ("\n i< (20) works ");
printf ("\n (i< (20)) fails ");
}
commands: ~$ gcc fail_for.c -Wall -Wextra -fopenmp
fail_for.c: In function ‘main’:
fail_for.c:5:17: error: invalid controlling predicate
for (i = (0) ; (i< (20)) ; i++) {
^
swamimauli@swamimauli:~$ gcc --version
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
>
>> >>> 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.
>
struct s{
int f0;
};
void main (){
int i;
struct s var1 ;
#pragma omp parallel for
for (var1.f0 = 0 ; var1.f0< (20); var1.f0++) {
}
}
swamimauli@swamimauli:~$ gcc fail_struct.c -Wall -Wextra -fopenmp
fail_struct.c: In function ‘main’:
fail_struct.c:9:14: error: expected iteration declaration or
initialization before ‘var1’
for (var1.f0 = 0 ; var1.f0< (20); var1.f0++) {
^~~~
Thanks,
Sameeran Joshi
> Jakub
>
