From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14815 invoked by alias); 9 May 2014 20:23:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 14795 invoked by uid 89); 9 May 2014 20:23:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 May 2014 20:23:07 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s49KN6td029511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 May 2014 16:23:06 -0400 Received: from tucnak.zalov.cz (ovpn-116-116.ams2.redhat.com [10.36.116.116]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s49KN4sM029566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 May 2014 16:23:05 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.8/8.14.7) with ESMTP id s49KN2Pl019569; Fri, 9 May 2014 22:23:02 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.8/8.14.8/Submit) id s49KMxDc019568; Fri, 9 May 2014 22:22:59 +0200 Date: Fri, 09 May 2014 20:23:00 -0000 From: Jakub Jelinek To: Tobias Burnus Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Subject: Re: [PATCH] Fortran OpenMP 4.0 support, part 1 Message-ID: <20140509202259.GO10386@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20140507205303.GF10386@tucnak.redhat.com> <536D2DE7.8060701@net-b.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536D2DE7.8060701@net-b.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00646.txt.bz2 On Fri, May 09, 2014 at 09:35:03PM +0200, Tobias Burnus wrote: > >This patch attempts to implement first part of Fortran OpenMP 4.0 support, > >The testsuite coverage could certainly be improved, volunteers for that > >and/or bugreports will be certainly appreciated. Don't know how to actually > >test aligned clauses, is there any way (except for doing allocations in > >C/C++ on the side) to allocate objects on aligned boundaries (aligned > >attribute, some way to dynamically allocate aligned storage, ...)? > > Fortran - as also C and C++ - does not provide much support for > aligned memory. [Well, C++ has now alignas and align(ment_)of.] But > contrary to C/C++, using library functions for dynamic allocation is > more difficult and gfortran doesn't support GCC's align attribute > for non-heap allocation. I only know of one commercial compiler, > which has alignment directives (for static and dynamically allocated > memory). I also was considering adding support for it - but I > haven't found the time to do so, yet. Yeah, but besides alignas/_Alignas in C/C++ one has also posix_memalign etc. The OpenMP standard allows for aligned clause: C_PTR or Cray pointer, or var with POINTER or ALLOCATABLE attribute. so best would be to actually test all of those, but supposedly one can't really test it e.g. with ALLOCATABLE attribute, unless say the test is restricted to x86_64-linux or similar platform where we know glibc malloc allocates 16 byte aligned chunks at least and we rely on libgfortran to use glibc malloc. > >Bootstrapped/regtested on x86_64-linux and i686-linux. Any comments on > >this? > > Looks good to me - not that I checked every line. One small nit below. > > > > +/* For use in OpenMP clauses in case we need extra information > >+ (aligned clause alignment, linear clause step, etc. */ > > The ")" is missing in the comment. Thanks, will fix. > BTW: I think it would be nice to have a better error message for the > following: > > ! --------------------------------------- > integer :: a(10) = [1,2,3,4,5,6,7,8,9,0] > integer :: i > > !$omp simd safelen(i) linear(a:2) safelen(i) > do i = 1, 5 > end do > end > ! --------------------------------------- > > It currently fails with: > Error: Unclassifiable OpenMP directive at (1) > but the only problem is that there are two "safelen". Yeah, the diagnostics could be improved, but this is a general issue of the whole OpenMP parsing, not specific to SIMD or OpenMP 4.0. Didn't have time for that yet and it wasn't too high priority so far. > With C, one gets a better message: > foo.c:6:25: error: too many 'safelen' clauses > > > Question is the following valid or not? > > void test() { > int a[10]; > int i; > #pragma omp simd linear(a:2) safelen(i) > for (i = 1; i < 5; i++) > ; > } > > It is rejected with: > foo.c:5:24: error: linear clause applied to non-integral non-pointer > variable with type 'int[10]' I believe it is invalid. a has array type, not pointer type, and array really can't be linear, as its address is constant, for linear you need to have something that is incremented by 2 every iteration... Jakub