From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3447 invoked by alias); 3 Nov 2008 11:17:23 -0000 Received: (qmail 3378 invoked by uid 22791); 3 Nov 2008 11:17:21 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Nov 2008 11:16:45 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id mA3BG4m8029788; Mon, 3 Nov 2008 06:16:08 -0500 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mA3BG3Ro010969; Mon, 3 Nov 2008 06:16:04 -0500 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.2/8.14.2/Submit) id mA3BG3mN003357; Mon, 3 Nov 2008 12:16:03 +0100 Date: Mon, 03 Nov 2008 11:17:00 -0000 From: Jakub Jelinek To: Tobias Burnus Cc: gcc-patches@gcc.gnu.org Subject: Re: PR37935 - libgomp.texi updates for OpenMP v3 Message-ID: <20081103111603.GF14706@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: <20081101204517.GA22830@net-b.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081101204517.GA22830@net-b.de> User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes 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 X-SW-Source: 2008-11/txt/msg00057.txt.bz2 On Sat, Nov 01, 2008 at 09:45:17PM +0100, Tobias Burnus wrote: > -Unique thread identification number. In a sequential parts of the program, > -@code{omp_get_thread_num} always returns 0. In parallel regions the return > -value varies from 0 to @code{omp_get_max_threads}-1 inclusive. The return > +Unique thread identification number with in the current team. s/with in/within/ > @end table > > > > +@node omp_set_schedule > +@section @code{omp_set_schedule} -- Set the runtime scheduling method > +@table @asis > +@item @emph{Description}: > +Sets the runtime scheduling method. The @var{kind} argument can have the > +value @code{omp_sched_static}, @code{omp_sched_dynamic}, > +@code{opm_sched_guided} or @code{auto}. Except for @code{auto}, the chunk s/auto/omp_sched_auto/g > +size is set to the value of @var{modifier} if positive or to the default > +value if zero or negative. For @code{auto} the @var{modifier} argument is > +ignored. Again. > +@node OMP_MAX_ACTIVE_LEVELS > +@section @env{OMP_MAX_ACTIVE_LEVELS} -- Set the maximal number of nested parallel regions > +@cindex Environment Variable > +@table @asis > +@item @emph{Description}: > +Specifies the initial value for the maximal number of nested parallel > +regions. The value of this variable shall be positive integer. > + > +@c FIXME: What is the default? The default is no limit. > +@node OMP_STACKSIZE > +@section @env{OMP_STACKSIZE} -- Set default thread stack size > +@cindex Environment Variable > +@table @asis > +@item @emph{Description}: > +Set the default thread stack size in kilobytes, unless the number > +is suffixed by @code{B}, @code{K}, @code{M} or @code{G}, in which > +case the size is, respectively, in bytes, kilobytes, megabytes > +or gigabytes. This is in opposition to @code{pthread_attr_setstacksize} > +which gets the number of bytes as an argument. If the stacksize can not "is in opposition to" doesn't sound good to me in this case, but I'm not a native speaker, so I could be wrong. > +@node OMP_THREAD_LIMIT > +@section @env{OMP_THREAD_LIMIT} -- Set the maximal number of threads > +@cindex Environment Variable > +@table @asis > +@item @emph{Description}: > +Specifies the number of threads to use for the whole program. The > +value of this variable shall be positive integer. > + > +@c FIXME: What is the default? The default is no limit. Jakub