[Bug target/19933] Problem with define of HUGE_VAL in math_c99.

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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