Re: What is acceptable for -ffast-math? (Was: associative law in combine)

[Jan Hubicka <jh at suse dot cz>]

> glibc as a whole is so dependent on i386 assembly that it would be a
> major project to change.  It might be interesting to include direct
Gcc currently have an method to add machine dependent builtins used
by the SSE code.  I think in same sense we can add machine dependent
builtins for the few remaining i387 instructions we don't generate
directly and then use mathinline.h to do right job converting them
to 'C' way.

I believe this is clean solution.
> support for more math intrinsics in gcc, but that begins to encroach on
> the traditional separation between gcc and support libraries.  I suppose
> this would involve built-ins for frexp(), ldexp() et al. in each
> supported precision.  I fear that a noticeable amount of efficiency
I must say I don't follow the above...
> could be lost, and we would remain with the question of full accuracy
> and safety vs speed in certain cases.  A beginning would be to organize
> mathinline.h so as to be based on such a group of builtins in order to
> test them in the current framework.  This project may not offer
This sounds exactly what I say :) So we seems to be in tune.

Honza
> sufficient return without assurance of glibc taking advantage of it and
> becoming more portable.
> >
> > If you have sanified version and you can get the copyring issues,
> > please try to contribute the changed to glibc.
> I took this far enough with the glibc maintainers to see that their
> point of view does not allow introduction of any "safety features."  Now
> I will be even further away, wanting to improve support for P4.
I