From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84761 invoked by alias); 4 Oct 2018 14:04:38 -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 84747 invoked by uid 89); 4 Oct 2018 14:04:37 -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*f:sk:GObtyiV, H*i:sk:GObtyiV, family X-HELO: resqmta-po-01v.sys.comcast.net Received: from resqmta-po-01v.sys.comcast.net (HELO resqmta-po-01v.sys.comcast.net) (96.114.154.160) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 04 Oct 2018 14:04:35 +0000 Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-01v.sys.comcast.net with ESMTP id 83fOgowrCdw1W84F0gqpCt; Thu, 04 Oct 2018 14:04:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1538661874; bh=vQncFiTknmbAr1+h4Wj/dSUvOdteyXKtekCQFB7yEsI=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=R+HGtcXjjrosv2cO5sSfTs/ZTH/SJuRd4VgH8NK0pPqIoBkRn3JgnlsJComoLwj3r WoZDMa94HX2LN78Jf1XI7qeH36uPWd+uhVpTxvx3PDDXVjtiC7syIzra2OoAhkRCP2 C7frquMkTX3M90L6d9QEdQcfUrRLeBCRuR0GpLulXGb/V69Q/1f8n9wews2nYXDRyK o8n4TgZ9DDhdX7Ca0+UMsPaNBlxYBfPKIrn2JB+f4aA70qmi6PmIUFQCgI0fAVg41Q eWHKF2hB+Voum0nM/R644yxs4fu6KzlVg4UazICpDMISrJTKmpTNNQ1tf5Q2xpHUTi I1wVpbrJtO6Cw== Received: from [192.168.10.125] ([73.60.223.101]) by resomta-po-04v.sys.comcast.net with ESMTPSA id 84EzgdJvZ15A684EzgixjE; Thu, 04 Oct 2018 14:04:33 +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 14:04:00 -0000 Cc: "fortran@gcc.gnu.org" Content-Transfer-Encoding: quoted-printable Message-Id: <01899EC4-4F6C-4592-AFB6-D29DA79F1BCB@comcast.net> References: <984F5B1C-CAFB-4131-A90F-3805D674857B@comcast.net> To: Richard Biener X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00014.txt.bz2 > On Oct 4, 2018, at 4:06 AM, Richard Biener w= rote: >=20 > On Wed, Oct 3, 2018 at 11:04 PM Paul Koning wrot= e: >>=20 >> In the C and C++ parts of GCC, the target has some ways to adjust the co= mpiler options depending on target settings. I'm looking for a way to do t= hat with gfortran. >>=20 >> The specific issue is in pdp11, which has an option to specify that "flo= at" is 8 bytes (same as "double") rather than 4 bytes. And the 8 byte choi= ce is the default. >>=20 >> As a result, if I invoke gfortran for that target, I get an ICE because = real*4 can't be found. If I say -fdefault-real-8 it works. >>=20 >> So what I'm hoping to do is to have the target switch processing code (f= or the TARGET_HANDLE_OPTION hook) react to the -mfloat32 and -mfloat64 swit= ches by passing appropriate -fdefault-real-* switches to Fortran. Is that = possible? >=20 > I think Fortran has to do it the same way the C family does. > float/double get assigned > by looking at FLOAT_TYPE_SIZE / [LONG_]DOUBLE_TYPE_SIZE. Iff that's not = good > for the Fortran FE we'd have to define additional target hooks the FE can= use. 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 know= n fixed n. Without switches, n is 4, which is indeed the common answer. B= ut in my case, there isn't any 4-byte float type unless you say -mfloat32. Maybe the answer is "that's a wrong thing to do". If so, I suppose I could= change it -- it was done before I got involved and I don't know for what r= eason. paul