From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69210 invoked by alias); 26 Mar 2019 08:00:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 68661 invoked by uid 89); 26 Mar 2019 08:00:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-io1-f65.google.com Received: from mail-io1-f65.google.com (HELO mail-io1-f65.google.com) (209.85.166.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Mar 2019 08:00:30 +0000 Received: by mail-io1-f65.google.com with SMTP id u12so9934203iop.11 for ; Tue, 26 Mar 2019 01:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PDyxOjK5h+6HEAEkdLjsLuqroo9aDj6/KqjRNWcFV2g=; b=gZkbAiAXcCMDYu//5npP2mX+PzhDDWmkYjRUNTqVRnGhpJu+5B1TcpNn15LE+lqxjs 2MyBn45v1aVq9IihRC/SXTmMOHWs8G3VdOqgXkcmoy5y//NI7m1HQiDl/SNR8rFk5pUu D9GwsaoxF9dp+3g0uDl2JU2Se5KRFC3dJWDrR5NMymY4K0F/gTCjv2pJ6O1nuDWOTs2B XXQg3jyN01d+M/BPiC8sAVSKyo9U5ij4mmHqiapb1KO+cxsMvS+Ov/WRBrMQDypOM9js O4NCdSpjR6q8DlAG5uVydLX67gFUPgXWZvVwBrqsWrqV3DLZOlsgL9mcGYo2xpq1Ib4S SkUQ== MIME-Version: 1.0 Received: by 2002:ac0:9022:0:0:0:0:0 with HTTP; Tue, 26 Mar 2019 01:00:28 -0700 (PDT) In-Reply-To: <20190326072935.GY7611@tucnak> References: <20190324025508.GF18020@tassilo.jf.intel.com> <87o95yxya1.fsf@linux.intel.com> <20190326072935.GY7611@tucnak> From: sameeran joshi Date: Tue, 26 Mar 2019 08:00:00 -0000 Message-ID: Subject: Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions] To: gcc@gcc.gnu.org Cc: Andi Kleen , Jakub Jelinek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00209.txt.bz2 On 3/26/19, Jakub Jelinek wrote: > On Mon, Mar 25, 2019 at 05:41:26PM -0700, Andi Kleen wrote: >> sameeran joshi writes: >> >> > On 3/24/19, Andi Kleen 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=3D3&t=3D= 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 =3D (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 =E2=80=98main=E2=80=99: fail_for.c:5:17: error: invalid controlling predicate for (i =3D (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 :=3D variable of signed or unsigned type | variable of pointer t= ype >> >>> 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 =3D 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 =3D 0 ; var1.f0< (20); var1.f0++) { } } swamimauli@swamimauli:~$ gcc fail_struct.c -Wall -Wextra -fopenmp fail_struct.c: In function =E2=80=98main=E2=80=99: fail_struct.c:9:14: error: expected iteration declaration or initialization before =E2=80=98var1=E2=80=99 for (var1.f0 =3D 0 ; var1.f0< (20); var1.f0++) { ^~~~ Thanks, Sameeran Joshi > Jakub >