From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82855 invoked by alias); 4 Oct 2018 15:41:41 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 82842 invoked by uid 89); 4 Oct 2018 15:41:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:ISO-8859-1, Hx-languages-length:1280, facility, H*f:sk:01899EC X-HELO: ppsw-32.csi.cam.ac.uk Received: from ppsw-32.csi.cam.ac.uk (HELO ppsw-32.csi.cam.ac.uk) (131.111.8.132) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 04 Oct 2018 15:41:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cam.ac.uk; s=20180806.ppsw; h=Sender:Content-Type:Mime-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=w34EcimydUUVFe//zs4Krdpeqfz2uotfrOlxCt51oLc=; b=u78FkrdL+3OjCcnI2BEiKTcio7 flgIdDg9PZpDmzQ7P1y6DvfAm5zj00Lb0Swk82/bUsdla1T9+hgLe6ljkk8NEE9QN824V8dqheZJZ 6cH3ldlVVuqywgyfVSUuWnBnirTu8wVUZe7d+xkUaP472yPiy+GmZMJQZ2meQem0PCEQ=; Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40788) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:nmm1) id 1g85kf-000D7j-2e (Exim 4.91) (return-path ); Thu, 04 Oct 2018 16:41:35 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1g85kf-0004Bn-QD (Exim 4.91) (return-path ); Thu, 04 Oct 2018 16:41:21 +0100 Received: from [51.6.55.214] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 04 Oct 2018 16:41:21 +0100 Date: Thu, 04 Oct 2018 15:41:00 -0000 From: "N.M. Maclaren" To: Paul Koning Cc: Richard Biener , "fortran@gcc.gnu.org" Subject: Re: Target control of Fortran options Message-ID: In-Reply-To: <01899EC4-4F6C-4592-AFB6-D29DA79F1BCB@comcast.net> References: <984F5B1C-CAFB-4131-A90F-3805D674857B@comcast.net> <01899EC4-4F6C-4592-AFB6-D29DA79F1BCB@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: "N.M. Maclaren" X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00015.txt.bz2 On Oct 4 2018, Paul Koning wrote: > > It appears that Fortran has a different approach. Fortran has syntax like > "REAL*8" to request a float of a specific size. And what gfortran does is > assume that "REAL" without a size specifier means "REAL*n" for a well > known fixed n. Without switches, n is 4, which is indeed the common > answer. But in my case, there isn't any 4-byte float type unless you say > -mfloat32. If you don't have a 4-byte REAL, why do you make default REAL 4 bytes? Do you mean that the front-end code assumes that it is? In which case, I would say that it's a clear design bug! If not, why not just set it to your basic floating type? It's commonly 8 bytes on machines where that is the basic real size (e.g. Cray vector systems); I don't know if gfortran supports any such systems, but that's the approach that is universally taken for them. In fact, mapping REAL*4 to 8 bytes is quite common with precision-extension options in some compilers, and your implementation sounds similar. I assume that you know that REAL*n isn't a standard Fortran facility, and the "n" isn't always the size in bytes. For the standard equivalent, what does your version map REAL(SELECTED_REAL_SIZE(6)) to? Regards, Nick Maclaren.