Something  weird is going on.  I condensed the newlib code into the
following files and when I compile and run the test,
it works as expected:

gcc -std=c99 -g3 -O0 test_sqrt.c fesetround.c ef_sqrt.c
[jjohnstn@localhost shared_x86]$ ./a.out
RNDN: 0x1.ff83fp+63
RNDZ: 0x1.ff83eep+63
RNDU: 0x1.ff83fp+63
RNDD: 0x1.ff83eep+63

Can you verify that you are calling the fesetround in fenv.c and what
configuration call did you use for building newlib?

-- Jeff J.



On Wed, Jun 2, 2021 at 3:12 PM Joel Sherrill <joel@rtems.org> wrote:

> On Wed, Jun 2, 2021, 2:08 PM Marco Atzeri <marco.atzeri@gmail.com> wrote:
>
> > On 02.06.2021 20:43, Jeff Johnston wrote:
> > > On Wed, Jun 2, 2021 at 9:08 AM Joel Sherrill <joel@rtems.org> wrote:
> > >
> > >>
> > >>
> > >> On Wed, Jun 2, 2021 at 2:51 AM Paul Zimmermann <
> > Paul.Zimmermann@inria.fr>
> > >> wrote:
> > >>
> >
> > >>
> > > I'll second Joel's comment.  The code is extremely close to the glibc
> > code
> > > both in sqrtf and fesetround.  The only
> > > thing I can think of is that the glibc code does the x87 stuff first
> and
> > > does the set back into FPU state before doing the
> > > SSE stuff.  The newlib code sets back the FPU state at the end after
> the
> > > SSE stuff.  Don't know if this is relevant or not.
> > >
> > > Any Cygwin users out there who can verify that the code is working/not
> > > working for them?
> > >
> > > -- Jeff J.
> > >
> >
> > current Cygwin produces for both i686 and X86_64
> >
> >   $ gcc -DNEWLIB -fno-builtin test_sqrt.c  -lm
> >
> >   $ ./a.exe
> > RNDN: 0x1.ff83fp+63
> > RNDZ: 0x1.ff83fp+63
> > RNDU: 0x1.ff83fp+63
> > RNDD: 0x1.ff83fp+63
> >
>
> Does fegetround() return different values based on what mode was set?
>
> --joel
>
> >
> >
>
>