Hi Joel,

I just noticed another problem in terms of using this (partially)
with Cygwin:

On Aug  8 10:10, joel@rtems.org wrote:
> + * NOTE: The extern'ed variable fe_default_env_p is an implementation
> + *       detail of this stub.  FE_DFL_ENV must point to an instance of
> + *       fenv_t with the default fenv_t. The format of fenv_t and where
> + *       FE_DFL_ENV is are implementation specific.
> + */
> +extern const fenv_t *fe_dfl_env_p;

Can we please rename this pointer to _fe_dfl_env, as it's already
defined in Cygwin?  The reason is that this pointer is exported
into user space via ...

> +#define FE_DFL_ENV fe_dfl_env_p

If you change the name here, Cygwin will not be able to use

> diff --git a/newlib/libm/fenv/fe_dfl_env.c b/newlib/libm/fenv/fe_dfl_env.c
> [...]

this file as storage for the default environment so as not to break
backward compatibility with existing executables.

> + * This is a non-functional implementation that should be overridden
> + * by an architecture specific implementation in newlib/libm/machine/ARCH.
> + *
> + * The implmentation must defined FE_DFL_ENV to point to a default
> + * environment of type fenv_t.
> + */
> +const fenv_t fe_dfl_env = { 0 };
> +const fenv_t *fe_dfl_env_p = &fe_dfl_env;

The funny thing here is, that this file could be used by all targets,
regardless of the definition of fenv_t, without the need to redefine it
per target.  Only Cygwin couldn't.  It would have to provide it's own,
even if the Cygwin code itself gets moved to i386 and x86_64, unless
fe_dfl_env_p is renamed to _fe_dfl_env.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat