From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30362 invoked by alias); 24 Feb 2007 18:50:20 -0000 Received: (qmail 30345 invoked by uid 22791); 24 Feb 2007 18:50:19 -0000 X-Spam-Check-By: sourceware.org Received: from troutmask.apl.washington.edu (HELO troutmask.apl.washington.edu) (128.208.78.105) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Feb 2007 18:50:13 +0000 Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.8/8.13.8) with ESMTP id l1OIlpwS059020; Sat, 24 Feb 2007 10:47:51 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.8/8.13.8/Submit) id l1OIlpTK059019; Sat, 24 Feb 2007 10:47:51 -0800 (PST) (envelope-from sgk) Date: Sat, 24 Feb 2007 22:51:00 -0000 From: Steve Kargl To: Daniel Franke Cc: Tobias Burnus , "'fortran@gcc.gnu.org'" , gcc-patches@gcc.gnu.org Subject: Re: [patch, fortran] fixes for the EXIT intrinsic function (PR30933) Message-ID: <20070224184751.GA58912@troutmask.apl.washington.edu> References: <45DF2C6A.6050202@net-b.de> <20070223231939.GA95457@troutmask.apl.washington.edu> <45E02FB0.60007@net-b.de> <200702241919.56272.franke.daniel@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200702241919.56272.franke.daniel@gmail.com> User-Agent: Mutt/1.4.2.2i 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: 2007-02/txt/msg01959.txt.bz2 On Sat, Feb 24, 2007 at 07:19:55PM +0100, Daniel Franke wrote: > On Saturday 24 February 2007 13:29:36 Tobias Burnus wrote: > > > > In any case which of the following option should we choose for those > > non-time critical functions which call C library functions? Currently, > > we have a mixure of (i), and (iv). > > > > i. Add i1, i2, and i16 versions to libgfortran > > > > ii. Convert kind > 8 to integer(8) and kind < 4 to integer(4) > > > > iii. As POSIX defines "exit(int)" and sizeof(int) is on most systems "4" > > convert everything to integer(4) > > > > iv. Convert everything to the default integer, i.e. integer(4) or > > integer(8) depending whether -fdefault-integer-8 is used. > > > > While (iv) is the easiest, it somehow looks a bit arbitrary. I therefore > > would prefer either of (i) to (iii), with (iii) seeming to be the > > cleanest - at least if one uses the same kind as the C library does. I think it depends on the INTENT of the arguments. If the args are INTENT(IN), then (iv) is probably best. A user calling FUNC(1_1) will see that FUNC works, but under the hood _gfortran_func_i4 or _gfortran_func_i8 is called depending on -fdefault-integer-8. For INTENT(INOUT) or INTENT(OUT) args, we'll probably need to go with (i). This may be accomplished by wrappers around the current implementations for func_i4 and/or func_i8. > > (How does one ensure this?) > > Additional question: > > If a subroutine/function takes multiple integer arguments, how many calls > should be considered valid? > > a) all possible combinations (i1/i1, i1/i2, i1/i4, ..., i8/i4, i8/i8) > b) only those with matching types (i1/i1, i2/i2, i4/i4, i8/i8) > I prefer (b). For many F95 intrinsics, this is the specified behavior, and so we'll be consistent with the standard. -- Steve