public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>
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 15:02:23 +0000 [thread overview]
Message-ID: <bug-94586-4-FBk4BHsmaV@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-94586-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Apr 14, 2020 at 11:46:36PM +0000, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #10 from dave.anglin at bell dot net ---
> On 2020-04-14 6:08 p.m., sgk at troutmask dot apl.washington.edu wrote:
> > So, hppa64 has REAL(16), but it does not use __float128 or
> > GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Instead
> > of the above kludge you can do something like
> It appears GFC_REAL_16_IS_FLOAT128 is not getting set. Will investigate.
> There's a similar problem with the test dec_math.f90 which has started to fail
>
> We have when the hpux long double library is available:
>
> /* Under HPUX, the __float128 type is a synonym for "long double". */
> (*lang_hooks.types.register_builtin_type) (long_double_type_node,
> "__float128");
>
> We have __builtin_fabsq, __builtin_copysignq, __builtin_infq and
> __builtin_huge_valq.
> I suppose I could add "l" versions.
>
This seems to be confusing the simply assumptions in
libgfortran/kinds-override.h, which states
/* What are the C types corresponding to the real(kind=10) and
real(kind=16) types? We currently rely on the following assumptions:
-- if real(kind=10) exists, i.e. if HAVE_GFC_REAL_10 is defined,
then it is necessarily the "long double" type
-- if real(kind=16) exists, then:
* if HAVE_GFC_REAL_10, real(kind=16) is "__float128"
* otherwise, real(kind=16) is "long double"
To allow to change this in the future, we create the
GFC_REAL_16_IS_FLOAT128 macro that is used throughout libgfortran. */
#if defined(HAVE_GFC_REAL_16)
# if defined(HAVE_GFC_REAL_10)
# define GFC_REAL_16_IS_FLOAT128
# if !defined(HAVE_FLOAT128)
# error "Where has __float128 gone?"
# endif
# else
# define GFC_REAL_16_IS_LONG_DOUBLE
# endif
#endif
So, hpux does not have REAL(10) and has REAL(16). This is doing
what it is designed to do based on the assumption that a target
like hpux with REAL(16) will define the long double functions
with the 'l' suffix. It seems the the fix for hpux is to change
the test to something like
# if defined(HAVE_GFC_REAL_10) || defined(__HPUX__)
using, of course, whatever the relevant macro. This will then
select the 'q' suffix.
next prev parent reply other threads:[~2020-04-15 15:02 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-13 21:22 [Bug libfortran/94586] New: " danglin at gcc dot gnu.org
2020-04-14 3:02 ` [Bug libfortran/94586] " kargl at gcc dot gnu.org
2020-04-14 7:23 ` rguenth at gcc dot gnu.org
2020-04-14 7:51 ` sgk at troutmask dot apl.washington.edu
2020-04-14 12:55 ` dave.anglin at bell dot net
2020-04-14 15:40 ` sgk at troutmask dot apl.washington.edu
2020-04-14 17:24 ` dave.anglin at bell dot net
2020-04-14 18:12 ` sgk at troutmask dot apl.washington.edu
2020-04-14 20:48 ` dave.anglin at bell dot net
2020-04-14 22:08 ` sgk at troutmask dot apl.washington.edu
2020-04-14 23:46 ` dave.anglin at bell dot net
2020-04-15 15:02 ` sgk at troutmask dot apl.washington.edu [this message]
2020-04-15 15:28 ` dave.anglin at bell dot net
2020-04-15 18:04 ` dave.anglin at bell dot net
2020-04-15 18:14 ` sgk at troutmask dot apl.washington.edu
2020-04-15 18:32 ` sgk at troutmask dot apl.washington.edu
2020-04-15 19:10 ` dave.anglin at bell dot net
2020-04-15 19:26 ` dave.anglin at bell dot net
2020-04-16 1:10 ` dave.anglin at bell dot net
2020-04-16 1:15 ` dave.anglin at bell dot net
2020-04-16 2:10 ` sgk at troutmask dot apl.washington.edu
2020-04-16 20:06 ` danglin at gcc dot gnu.org
2020-04-16 21:07 ` sgk at troutmask dot apl.washington.edu
2020-04-16 21:32 ` dave.anglin at bell dot net
2020-04-17 0:58 ` sgk at troutmask dot apl.washington.edu
2020-04-21 17:03 ` jakub at gcc dot gnu.org
2020-04-21 17:29 ` danglin at gcc dot gnu.org
2020-04-21 17:36 ` danglin at gcc dot gnu.org
2020-04-21 20:17 ` danglin at gcc dot gnu.org
2020-04-22 14:54 ` foreese at gcc dot gnu.org
2020-04-22 15:12 ` danglin at gcc dot gnu.org
2020-04-22 15:33 ` dave.anglin at bell dot net
2020-04-22 15:47 ` danglin at gcc dot gnu.org
2020-04-22 16:02 ` dave.anglin at bell dot net
2020-04-22 16:27 ` sgk at troutmask dot apl.washington.edu
2020-04-22 17:10 ` dave.anglin at bell dot net
2020-04-22 19:34 ` cvs-commit at gcc dot gnu.org
2020-04-22 19:44 ` danglin at gcc dot gnu.org
2020-04-22 19:58 ` danglin at gcc dot gnu.org
2020-04-22 21:41 ` danglin at gcc dot gnu.org
2020-04-23 14:12 ` cvs-commit at gcc dot gnu.org
2020-04-23 14:38 ` jakub at gcc dot gnu.org
2020-04-24 11:35 ` rguenth at gcc dot gnu.org
2020-04-24 11:37 ` jakub at gcc dot gnu.org
2020-04-24 11:58 ` danglin at gcc dot gnu.org
2020-07-20 10:18 ` dominiq at lps dot ens.fr
2020-07-20 19:53 ` danglin at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-94586-4-FBk4BHsmaV@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).