From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27980 invoked by alias); 11 Nov 2008 16:22:38 -0000 Received: (qmail 27923 invoked by uid 22791); 11 Nov 2008 16:22:38 -0000 X-Spam-Check-By: sourceware.org Received: from mail.physik.uni-muenchen.de (HELO mail.physik.uni-muenchen.de) (192.54.42.129) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 11 Nov 2008 16:21:40 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 27B5227D46; Tue, 11 Nov 2008 17:21:37 +0100 (CET) Received: from mail.physik.uni-muenchen.de ([127.0.0.1]) by localhost (testmail.physik.uni-muenchen.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6Ek+mWiRozER; Tue, 11 Nov 2008 17:21:37 +0100 (CET) Received: from [129.187.180.11] (zuppc13.garching.physik.uni-muenchen.de [129.187.180.11]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 011C627CC8; Tue, 11 Nov 2008 17:21:36 +0100 (CET) Message-ID: <4919B110.6060400@physik.uni-muenchen.de> Date: Tue, 11 Nov 2008 16:26:00 -0000 From: =?ISO-8859-1?Q?Tobias_Schl=FCter?= User-Agent: Thunderbird 2.0.0.17 (X11/20081001) MIME-Version: 1.0 To: Jakub Jelinek CC: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, Steve Kargl , Feng Wang , Brooks Moses Subject: Re: [PATCH] Fold VIEW_CONVERT_EXPR generated by Fortran FE a lot (PR target/35366) References: <20081111131749.GZ3572@tyan-ft48-01.lab.bos.redhat.com> <4919A8A4.8000001@physik.uni-muenchen.de> <20081111161100.GE3572@tyan-ft48-01.lab.bos.redhat.com> In-Reply-To: <20081111161100.GE3572@tyan-ft48-01.lab.bos.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00447.txt.bz2 Jakub Jelinek wrote: >> They are not standard Fortran. Using Hollerith constants this way was >> the way of encoding strings before there was a Character type in >> Fortran, so the current behavior is intentional. Whether there actually >> is code that uses logicals to encode strings, I can't tell. I CCed Feng >> Wang who added the original Hollerith support, and Steve who last >> modified the testcase. > > If using logicals is required to store all the bits of the constants > (and similarly for TRANSFER from integer to logical), then I'm afraid the > Fortran FE would have to stop using BOOLEAN_TYPE for logical, as the > middle-end BOOLEAN_TYPE really has the semantics that it is either false or > true, nothing else. > For TRANSFER I found: > http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01903.html > but I'm still unconvinced. I'd say arguing that the logical must > hold all the bits is the same as if you said > real(kind=8), parameter :: a = transfer (transfer (3.1415926d0, 0), 0.d0) > print *, a > end > must print 3.14159... A precondition of the two transfers giving identity > is IMHO that no bits are lost, but if the precision of the middle-type > is smaller than of the other type, it can't be fully preserved. The > precision of integer(kind=4) is smaller than of real(kind=8), and similarly > I'd say for logical(kind=4) and integer(kind=4), because logical: > "The logical type has two values which represent true and false." Hm, I haven't found Richard Maine's post that is mentioned in the old thread, but Fortran has the notion of storage unit. LOGICAL*4, INTEGER*4 and REAL*4 all occupy 4 storage units. If a circular transfer(transfer (...) ...) between types with the same number of storage units is required to return the original value (as Richard Maine apparently argued), then we'll probably have no choice but to stop using BOOLEAN_TYPE for LOGICALs. Maybe Brooks can point us to the comp.lang.fortran thread. Cheers, - Tobi