From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28938 invoked by alias); 11 Nov 2008 17:57:42 -0000 Received: (qmail 28850 invoked by uid 22791); 11 Nov 2008 17:57:41 -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; Tue, 11 Nov 2008 17:57:04 +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 mABHnWUb013360; Tue, 11 Nov 2008 12:49:32 -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 mABHnWFO010561; Tue, 11 Nov 2008 12:49:32 -0500 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.2/8.14.2/Submit) id mABHnVV3010563; Tue, 11 Nov 2008 18:49:31 +0100 Date: Tue, 11 Nov 2008 18:10:00 -0000 From: Jakub Jelinek To: Tobias =?iso-8859-1?Q?Schl=FCter?= 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) Message-ID: <20081111174931.GG3572@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek 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> <4919B110.6060400@physik.uni-muenchen.de> <20081111165200.GF3572@tyan-ft48-01.lab.bos.redhat.com> <4919BA80.3060602@physik.uni-muenchen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4919BA80.3060602@physik.uni-muenchen.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/msg00459.txt.bz2 On Tue, Nov 11, 2008 at 06:01:52PM +0100, Tobias Schlüter wrote: > Jakub Jelinek wrote: >> On Tue, Nov 11, 2008 at 05:21:36PM +0100, Tobias Schlüter wrote: >>> 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. >> >> That's pretty sad. Stopping using BOOLEAN_TYPE is going to break >> basically everything, so certainly can't be done for 4.4. I expect >> that you'd need to add a lot of conversions everywhere, from the >> logical*N INTEGER_TYPE to correspondingly sized BOOLEAN_TYPE and back >> all the time. > > Maybe setting TYPE_PRECISION to bit_size in gfc_build_logical_type() > would do the trick without any further changes? This depends on how the > middle-end deals with BOOLEAN_TYPES with TYPE_PRECISION > 1. It wouldn't help: /* Boolean type (true or false are the only values). Looks like an INTEGRAL_TYPE. */ DEFTREECODE (BOOLEAN_TYPE, "boolean_type", tcc_type, 0) On the other side, if you have to convert from INTEGER_TYPE to BOOLEAN_TYPE all the time, the generated code will be very abysmal. How is LOGICAL supposed to behave if it is storage associated with an integer? Defined only if the integer stored has been 0 or 1, or 0 .false. and non-zero .true., or something else? Also, even with my patch integer, parameter :: i = transfer (transfer (42, .true.), 0) will work as the standard requires (in this case the transfers are resolved in the FE, and only one VIEW_CONVERT_EXPR is created (and folded to 42). But that's not what is failing in transfer_simplify_4.f90. What fails is: a = transfer(ip1, .true.) i = transfer(a, 0) if (i .ne. ip1) call abort () (as ip1 is parameter, then this is the same as a = transfer(42, .true.) i = transfer(a, 0) if (i .ne. ip1) call abort () ). If I modify the testcase slightly: implicit none integer :: ip1 logical :: a integer :: i ip1 = 42 a = transfer(ip1, .true.) i = transfer(a, 0) if (i .ne. ip1) call abort () end then it fails even with unpatched gfortran (even with 4.3) at -O1 and higher. But does the standard really say anything about this? Isn't assignment to a LOGICAL value supposed to set to to .false. or .true.? Jakub