From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 05FB7384A02F; Wed, 15 Apr 2020 19:10:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 05FB7384A02F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1586977840; bh=I7qzGEeaPdB4B8g6R7QJIbAYXt9nkM14FbdmkbON4Jc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pL9Yx/uf6Usi5fNqqveUkSOXPSA8fekAKdnpTkNgWaRiTnBZULb2NAtE6ss5Y5Zga zzXdWQuR6j8sM+fSFtEzm3C3A1T0yRz10NszN5f54x1t+KGhh2LOM/sy8zry13wPD2 41JiXDwwOSzH3MAXNwbQUOB1L2eJJ88uGIqwOwV4= From: "dave.anglin at bell dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf' Date: Wed, 15 Apr 2020 19:10:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libfortran X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dave.anglin at bell dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 19:10:40 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94586 --- Comment #16 from dave.anglin at bell dot net --- On 2020-04-15 2:14 p.m., sgk at troutmask dot apl.washington.edu wrote: > It likely is the start of an approach, but it seems hpux is conflating=20 > long double and __float128, where it flips between an 'l' and 'q' suffix. > gfortran simply assumes a correspondence with C types and C99 naming > conventions (e.g., sinf, sin, and sinl). If a target has REAL(4), REAL(8= ), > REAL(10), and REAL(16) the correspondence is float, double, long double, > and __float128, respectively. If a target has REAL(4), REAL(8), and REAL= (16), > then the correspondence is float, double, and long double. There is no > __float128, and by extension, no functions with a 'q' suffix. The long > double math function will end in 'l'. It's not hpux conflating long double and __float128.=C2=A0 On hppa, there's= a IEEE 128-bit float type defined in the architecture and a limited set of arithmetic routines availa= ble to manipulate this type. There's no C99 support until HP-UX 11i version 2.=C2=A0 Even then, no long = double routines were implemented for PA-RISC. IA64 has REAL(10). There's routine for both double extended (w) and=C2=A0 l= ong double (l).=C2=A0 Initially, the REAL(10) type was __float80.=C2=A0 REAL(16) on IA64 is quad (q).=C2=A0 __fl= oat128 is not used by HP-UX. There's no REAL(10) or REAL(16) on hppa.=C2=A0 Treating REAL(16) as __float= 128 was my choice some years ago.=C2=A0 It seemed compatible with gcc's __float128 on IA64 and I wanted = to take advantage of libquadmath if possible.=