[PATCH 3/3] Add i386 and x86_64 fenv support from Cygwin.

[Corinna Vinschen]

On Aug 28 11:57, Joel Sherrill wrote:
> On Wed, Aug 28, 2019 at 10:41 AM Corinna Vinschen <vinschen@redhat.com> wrote:
> > > +/*  The <fenv.h> header shall define the following constant, which
> > > +   represents the default floating-point environment (that is, the one
> > > +   installed at program startup) and has type pointer to const-qualified
> > > +   fenv_t. It can be used as an argument to the functions within the
> > > +   <fenv.h> header that manage the floating-point environment.  */
> > > +
> > > +extern const fenv_t *_fe_dfl_env;
> > > +#define FE_DFL_ENV (_fe_dfl_env)
> >
> > These can go away, right?  They are already defined in
> > newlib/libc/include/sys/fenv.h.
> 
> Each architecture overrides sys/fenv.h. There is no sharing of
> libc/include/sys/fenv.h
> with a functional implementation.

Miscomprehension on my side, sorry.

> > > +/*  Returns the currently selected precision, represented by one of the
> > > +   values of the defined precision macros.  */
> > > +int
> > > +fegetprec (void)
> > > +{
> > > [...]
> > > +int
> > > +fesetprec (int prec)
> > > +{
> > > [...]
> > > +#endif
> >
> > Uh oh.  What about _feinitialise()?  Cygwin calls this function
> > right from the initial code, but is it really the right thing
> > to enforce this for all i386/x86_64 targets?
> >
> > Any idea how we can generate the default environment on the fly
> > while maintaining backward compat on Cygwin?
> 
> Cygwin, libgloss, and RTEMS could call this I suppose. But each OS would have
> to do their own thing.
> 
> Should be really be called from the beginning of each thread? Otherwise,
> things are inconsistent.

What about initializing on the fly at the start of each affected function?
If we find a nice way to do that I'd also push that chage into Cygwin.
There's no obvious reason that we actually *have* to initalize the
fp environment in each process.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20190829/3de83bec/attachment.sig>