On Thu, Mar 02, 2006 at 05:19:20PM +0100, Richard Guenther wrote:
> On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 02, 2006 at 04:44:50PM +0100, Jakub Jelinek wrote:
> > > On Thu, Mar 02, 2006 at 07:38:47AM -0800, H. J. Lu wrote:
> > > > Yes. That is for float and double functions in libm.
> > > >
> > > > > to touch x387
> > > > > flags for XFmode long long operations.
> > > >
> > > > I assume you meant long double. If the library knows it doesn't long
> > > > double, it doesn't need to touch x87 unit control.
> > >
> > > But if you call one of the standard fenv.h functions, they
> > > are supposed to affect not just the calling routine (where you
> > > could through preprocessor magic tell what it uses, though e.g.
> > > not for inline asm), but for the whole process. And I don't understand
> > > how you can prove that if you call fesetround or similar from
> > > -mfpmath=sse compiled source file that the program doesn't anywhere
> > > in some other library or in the main binary use x87 unit (or vice versa).
> >
> > I was talking about glibc. sysdeps/ieee754/flt-32/e_expf.c has
> >
> > feholdexcept (&oldenv);
> > #ifdef FE_TONEAREST
> > fesetround (FE_TONEAREST);
> > #endif
> >
> > ...
> >
> > /* Return result. */
> > fesetenv (&oldenv);
> >
> > I don't see why it has to touch x87 unit. The same applies to most,
> > if not all, float/double functions in glibc.
>
> Right, but here a __builtin_fesetround and friends would be more appropriate
> that helping glibc with preprocessor magic.
However, given __builtin_fesetround, what will gcc generate for the
followings?
1.
double x, y;
....
__builtin_fesetround ();
2.
long double x, y;
...
__builtin_fesetround ();
3.
double x, y;
...
__builtin_fesetround ();
x = foo (y);
It is kind of complicated. The best gcc can do beyond asm statement is
__builtin_real_control_instruction, not __builtin_fesetround.
H.J.
