public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/19933] Problem with define of HUGE_VAL in math_c99.
Date: Sun, 01 May 2005 14:24:00 -0000 [thread overview]
Message-ID: <20050501142442.30014.qmail@sourceware.org> (raw)
In-Reply-To: <20050213054900.19933.casevh@comcast.net>
------- Additional Comments From joseph at codesourcery dot com 2005-05-01 14:24 -------
Subject: Re: Problem with define of HUGE_VAL in math_c99.
On Sun, 1 May 2005, ebotcazou at gcc dot gnu dot org wrote:
> > In principle all the macros can be defined along the lines of
> > the isnan/isfinite/isinf definitions in libgcc2.c, with GNU extensions to
> > avoid multiple evaluation, but this is not very efficient.
>
> Joseph, we are severely bitten by the __builtin_isfinite problem for the Fortran
> compiler (this is PR target/21315). What do you suggest? Fixincluding to GCC
> __builtin_* functions when possible and fixincluding away in the other cases?
Fixincluding everything to working definitions if possible, even if
cumbersome, with all the fixes disabled conditional on __GNUC__ being
mentioned in the header. (If support for some of these built-in functions
is then added to GCC, remove the relevant fixes, but I suppose you want to
fix things on 4.0 branch as well as mainline for now.) I'm not sure what
is best done with the signbit definition (maybe nothing if it will never
call a library function at present, even though it isn't properly
type-generic); but the others can be done, e.g.
#define isfinite(x) __extension__ ({ __typeof (x) __x = (x); __builtin_expect (!isnan(__x - __x), 1); })
following libgcc2.c but using statement expressions and __typeof to avoid
multiple evaluation. (This includes fixincluding isinf, per bug 20558.)
I'd recommend making each fixed definition a separate fixinclude (so they
still work if e.g. the header gets reordered; and so if Sun produce a
partially fixed header version then the disabling on __GNUC__ only needs
changing for those definitions which remain problematic).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
next prev parent reply other threads:[~2005-05-01 14:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-13 18:17 [Bug preprocessor/19933] New: " casevh at comcast dot net
2005-02-13 20:13 ` [Bug target/19933] " pinskia at gcc dot gnu dot org
2005-03-04 18:10 ` ebotcazou at gcc dot gnu dot org
2005-03-04 18:12 ` ebotcazou at gcc dot gnu dot org
2005-03-07 6:15 ` casevh at comcast dot net
2005-03-22 20:53 ` jsm28 at gcc dot gnu dot org
2005-04-30 17:10 ` ebotcazou at gcc dot gnu dot org
2005-05-01 12:21 ` ebotcazou at gcc dot gnu dot org
2005-05-01 14:24 ` joseph at codesourcery dot com [this message]
2005-05-03 9:49 ` ebotcazou at gcc dot gnu dot org
2005-05-03 10:55 ` joseph at codesourcery dot com
2005-05-03 11:36 ` ebotcazou at gcc dot gnu dot org
2005-05-03 13:02 ` joseph at codesourcery dot com
2005-05-03 14:39 ` ebotcazou at gcc dot gnu dot org
2005-05-03 16:22 ` joseph at codesourcery dot com
2005-05-19 7:06 ` cvs-commit at gcc dot gnu dot org
2005-05-19 7:12 ` cvs-commit at gcc dot gnu dot org
2005-05-19 7:16 ` ebotcazou at gcc dot gnu dot org
2005-05-24 13:39 ` ebotcazou at gcc dot gnu dot org
2005-05-29 20:53 ` ebotcazou at gcc dot gnu dot org
2005-05-29 20:53 ` cvs-commit at gcc dot gnu dot 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=20050501142442.30014.qmail@sourceware.org \
--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).