From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5426 invoked by alias); 24 Mar 2019 02:55:14 -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 5391 invoked by uid 89); 24 Mar 2019 02:55:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1 autolearn=ham version=3.3.1 spammy=11pm, 11PM X-HELO: mga01.intel.com Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 24 Mar 2019 02:55:11 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2019 19:55:09 -0700 Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.137]) by fmsmga002.fm.intel.com with ESMTP; 23 Mar 2019 19:55:08 -0700 Received: by tassilo.localdomain (Postfix, from userid 1000) id D234B3015F7; Sat, 23 Mar 2019 19:55:08 -0700 (PDT) Date: Sun, 24 Mar 2019 02:55:00 -0000 From: Andi Kleen To: sameeran joshi Cc: gcc@gcc.gnu.org Subject: Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions] Message-ID: <20190324025508.GF18020@tassilo.jf.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-03/txt/msg00183.txt.bz2 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