public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: sameeran joshi <gsocsameeran@gmail.com>
To: gcc@gcc.gnu.org
Cc: Andi Kleen <ak@linux.intel.com>, Jakub Jelinek <jakub@redhat.com>
Subject: Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
Date: Tue, 26 Mar 2019 08:00:00 -0000	[thread overview]
Message-ID: <CAKz4L0E0yyx_pW8OBstv4CvUxkVmsUys7YVu=MbybJUGXgT5PA@mail.gmail.com> (raw)
In-Reply-To: <20190326072935.GY7611@tucnak>

On 3/26/19, Jakub Jelinek <jakub@redhat.com> wrote:
> 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.

	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
>

  reply	other threads:[~2019-03-26  8:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-10  5:45 sameeran joshi
2019-02-18 18:22 ` Martin Jambor
2019-03-23 18:19   ` sameeran joshi
2019-03-24  2:55     ` Andi Kleen
2019-03-24 19:33       ` sameeran joshi
2019-03-26  0:41         ` Andi Kleen
2019-03-26  7:29           ` Jakub Jelinek
2019-03-26  8:00             ` sameeran joshi [this message]
2019-03-26  8:05               ` Jakub Jelinek
2019-03-26 13:32                 ` Andi Kleen
2019-04-01 16:52                   ` sameeran joshi
2019-04-01 17:02                     ` sameeran joshi
2019-04-03 16:50                       ` Martin Jambor
2019-04-03 17:46                         ` sameeran joshi
2019-04-04 11:20                           ` Martin Jambor
2019-04-04 13:45                             ` sameeran joshi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKz4L0E0yyx_pW8OBstv4CvUxkVmsUys7YVu=MbybJUGXgT5PA@mail.gmail.com' \
    --to=gsocsameeran@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).