From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98075 invoked by alias); 4 Oct 2018 15:48:49 -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 92973 invoked by uid 89); 4 Oct 2018 15:48:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:Prayer., H*f:sk:Prayer. X-HELO: resqmta-po-11v.sys.comcast.net Received: from resqmta-po-11v.sys.comcast.net (HELO resqmta-po-11v.sys.comcast.net) (96.114.154.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 04 Oct 2018 15:48:30 +0000 Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-11v.sys.comcast.net with ESMTP id 83Y6gUxkcPPjr85rZgbqTu; Thu, 04 Oct 2018 15:48:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1538668109; bh=mQSdcs5FHerucMxptbSzagN1F6CIzh8DTk11HihOxT4=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=B+g6Zf3ScdOShAT+zsvsc4MF32hTwAW2sAVRgbYQx8LuXM4WnLYoeNcor75JGH6sd axMxsu8Rfn/6Q3iO2XN8/N7QuHJ6URqn2jYUz6rpMqjVWWTLMrb9W7qYuOYEj/MigV fu2bsco91hGM21BBXTMrzoMjKaJizCDD7KiIQqzwpyXHPIvmTw/WouXQKcJFMPVttx Ie23a8HNEgM/nRwrgEg4qYQ+XZQMwwjKX7MiKX+i1OXkdp89tDJ93pqLBvUsXGhTg7 Z8/xRdfRs/TUM8Ebg5ybgYGem3IGYEPkseZfTWCX4+ilvxWIeH5tYPkgIwAbSqMvsF DIoRdJpU/zZPg== Received: from [192.168.10.125] ([73.60.223.101]) by resomta-po-13v.sys.comcast.net with ESMTPSA id 85rYgstVCQIZL85rYg2nWT; Thu, 04 Oct 2018 15:48:29 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Target control of Fortran options From: Paul Koning In-Reply-To: Date: Thu, 04 Oct 2018 15:48:00 -0000 Cc: Richard Biener , "fortran@gcc.gnu.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9A8B6E3D-D56C-45D0-93AE-8ED9EB0ADE1A@comcast.net> References: <984F5B1C-CAFB-4131-A90F-3805D674857B@comcast.net> <01899EC4-4F6C-4592-AFB6-D29DA79F1BCB@comcast.net> To: "N.M. Maclaren" X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00016.txt.bz2 > On Oct 4, 2018, at 11:41 AM, N.M. Maclaren wrote: >=20 > On Oct 4 2018, Paul Koning wrote: >>=20 >> It appears that Fortran has a different approach. Fortran has syntax lik= e "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 know= n 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. >=20 > 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? That's what I expected and apparently I'm not the only one. But the actual= code says that the default REAL is the 4 byte one, and if the compiler doe= sn't supply a float type of that size, the compiler crashes at startup. Janne raises an interesting point, about Fortran requirements of int and fl= oat and double sizes that I was not aware of. Given those, it seems that t= he correct answer is to do the more traditional thing where "float" (REAL) = is SFmode, 4 bytes -- always. In other words, make -mfloat32 be the only o= perating mode and retire that switch. paul