On Aug  8 15:04, Joel Sherrill wrote:
> On Thu, Aug 8, 2019 at 2:05 PM Corinna Vinschen <vinschen@redhat.com> wrote:
> 
> > On Aug  8 11:27, joel@rtems.org wrote:
> > > +/*
> > > + * 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.
> > > + */
> > > +static const fenv_t fe_dfl_env = { 0 };
> > > +const fenv_t *_fe_dfl_env = &fe_dfl_env;
> >
> > Bummer.  This doesn't work.  The problem is that Cygwin needs to
> > initialize fe_dfl_env, like this:
> >
> >   fegetenv (&fe_dfl_env);
> >
> > However, even if I drop `const' as in Cygwin, if fe_dfl_env is static
> > I can't access it from the _feinitialise() function at DLL init time.
> >
> > I'm not quite sure how to fix this.  Any ideas?  Do I have to drop
> > the idea to reuse this file and we need our own target-specific one?
> >
> 
> I'm not opposed to making it non-const and not static. Whatever it
> takes to make it work on Cygwin.

Ok, if nobody else disagrees.  I'll wait over the weekend.

I think, if the variable is non-static it should start with two
underscores.  This was no problem in Cygwin which only exports symbols
we add to a linker definition file, but in case of a "normal" lib, it
makes probably sense not to pollute the namespace.

You don't have to create another patch in that case, I care for it.

> > P.S.: Apart from this problem we can use this now.  We should just add
> > the GNU specific FE_NOMASK_ENV soon, too.
> >
> 
> I'm not disagreeing but can that be added after this bulk is pushed?

Sure!  I wrote "soon" not "now" :)


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat