------- 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
