From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1382 invoked by alias); 11 Nov 2008 21:41:16 -0000 Received: (qmail 1360 invoked by uid 22791); 11 Nov 2008 21:41:15 -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; Tue, 11 Nov 2008 21:40:39 +0000 Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id mABLeuK2001076; Tue, 11 Nov 2008 13:40:59 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id mABKP5UN038269; Tue, 11 Nov 2008 12:25:05 -0800 (PST) (envelope-from sgk) Date: Tue, 11 Nov 2008 21:56:00 -0000 From: Steve Kargl To: Tobias =?iso-8859-1?Q?Schl=FCter?= Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, Feng Wang Subject: Re: [PATCH] Fold VIEW_CONVERT_EXPR generated by Fortran FE a lot (PR target/35366) Message-ID: <20081111202505.GA38251@troutmask.apl.washington.edu> References: <20081111131749.GZ3572@tyan-ft48-01.lab.bos.redhat.com> <4919A8A4.8000001@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: <4919A8A4.8000001@physik.uni-muenchen.de> User-Agent: Mutt/1.4.2.3i 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/msg00479.txt.bz2 On Tue, Nov 11, 2008 at 04:45:40PM +0100, Tobias Schlüter wrote: > Jakub Jelinek wrote: > >Unfortrunately, it causes 2 Fortran testsuite failures, hollerith.f90 > >and transfer_simplify_4.f90, both at all optimization levels. > >I believe the tests are just invalid though. The first one does: > >logical l > >l = 4Ho wo > >and expects all the 32 bits preserved, but that is certainly against > >the semantics of BOOLEAN_TYPE and from quick skimming of the Fortran > >standard also LOGICAL type. BOOLEAN_TYPE has just two values, false > >and true (similarly for LOGICAL .false. and .true.) and so the folder > >IMHO correctly folds this into > >l = .true. > >(4Ho wo is non-zero). The transfer_simplify_4.f90 testcase transfers an > >integer into logical and back and expects again all the 32-bits to be > >preserved. > > > >Fortran folks, can you please look at these 2 testcases and say whether > >they are valid Fortran or just undefined behavior? > > 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. > My changes in hollerith.f90 were of the form 'complex*16 --> complex(kind=8)'. It would not have any affect on Jakub proposed patched. In reviewing the thread, it appears that gfortran may need to abandon BOOLEAN_TYPE because the description of TRANSFER is quite clear: If D and E are scalar variables such that the physical representation of D is as long as or longer than that of E, the value of TRANSFER (TRANSFER (E, D), E) shall be the value of E. unless gfortran can provide a special case for the above. Also, note that integer f, e logical d e = 42 f = transfer(transfer(e,d),e) if (f /= e) abort() end and integer f, e logical d e = 42 d = transfer(e,d) f = transfer(d,e) if (f /= e) abort() end can be argued to have different results because the latter has two explicitly assignments and hence type conversions whereas the former has only a single assignment with an accompanying type conversion. -- Steve