i386 and x86_64 fenv support

i386 and x86_64 fenv support

[Joel Sherrill]

Hi

Earlier we discussed moving the winsup fenv.h files to newlib. Splitting
winsup/cygwin/include/fenv.h to create a sys/fenv.h looks easy enough.
But I have some status and a question after tinkering with this code out
of tree and compiling with the RTEMS i386 and x86_64

It includes winsup.h and wincap.h but it doesn't need them.

It is a C++ file and changing it to C only resulted in needing to change
bool to int and true/false to 1/0. That should be OK.

There are prototypes for fegetprec() and fesetprec(). I think the
prototypes need to move to the shared fenv.h and commented
stubs for the constants needs to be in the shared dummy sys/fenv.h.
Does this sound right?

My remaining issue is that it appears that i386 and x86_64 will need to
share the same files. Do I just copy the files to both machine directories?
I don't know if newlib's build infrastructure supports putting it in one
place and using it in another architecture.

FWIW this moved up in importance because the x86_64 RTEMS toolchain
won't build with the gcc/newlib master because libquadmath assumes the
existence of the FE_TONEAREST since it the autoconf probe now sees
we have fenv.h support now. This is probably a bug in this code since it
can't assume a rounding mode is supported.

Feedback appreciated.

Thanks.

--joel

Re: i386 and x86_64 fenv support

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 741 bytes --]

On 8/27/19 8:31 AM, Joel Sherrill wrote:
> Hi
> 
> Earlier we discussed moving the winsup fenv.h files to newlib. Splitting
> winsup/cygwin/include/fenv.h to create a sys/fenv.h looks easy enough.
> But I have some status and a question after tinkering with this code out
> of tree and compiling with the RTEMS i386 and x86_64
> 
> It includes winsup.h and wincap.h but it doesn't need them.
> 
> It is a C++ file and changing it to C only resulted in needing to change
> bool to int and true/false to 1/0. That should be OK.

Why not use <stdbool.h>, so you don't have to change bool to int?


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: i386 and x86_64 fenv support

[Joel Sherrill]

On Tue, Aug 27, 2019 at 8:37 AM Eric Blake <eblake@redhat.com> wrote:
>
> On 8/27/19 8:31 AM, Joel Sherrill wrote:
> > Hi
> >
> > Earlier we discussed moving the winsup fenv.h files to newlib. Splitting
> > winsup/cygwin/include/fenv.h to create a sys/fenv.h looks easy enough.
> > But I have some status and a question after tinkering with this code out
> > of tree and compiling with the RTEMS i386 and x86_64
> >
> > It includes winsup.h and wincap.h but it doesn't need them.
> >
> > It is a C++ file and changing it to C only resulted in needing to change
> > bool to int and true/false to 1/0. That should be OK.
>
> Why not use <stdbool.h>, so you don't have to change bool to int?

Good idea. That works.

Thank you.

> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3226
> Virtualization:  qemu.org | libvirt.org
>

Re: i386 and x86_64 fenv support

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

On Aug 27 08:31, Joel Sherrill wrote:
> Hi
> 
> Earlier we discussed moving the winsup fenv.h files to newlib. Splitting
> winsup/cygwin/include/fenv.h to create a sys/fenv.h looks easy enough.
> But I have some status and a question after tinkering with this code out
> of tree and compiling with the RTEMS i386 and x86_64
> 
> It includes winsup.h and wincap.h but it doesn't need them.

Yeah, that's kind of a boilerplate include in Cygwin code.  Just scratch
it, it can't be overly important for the fenv functionality.

> [...]
> There are prototypes for fegetprec() and fesetprec(). I think the
> prototypes need to move to the shared fenv.h and commented
> stubs for the constants needs to be in the shared dummy sys/fenv.h.
> Does this sound right?

As far as I can see, none of Linux or BSD have these functions.  It may
be the right thing to do to keep them local to Cygwin since they never
made it into a standard or one of the systems we're interested in here.

Ideally they are never defined in a header, not even on Cygwin.  We only
have to keep exporting these symbols in Cygwin for backward compat.

> My remaining issue is that it appears that i386 and x86_64 will need to
> share the same files. Do I just copy the files to both machine directories?
> I don't know if newlib's build infrastructure supports putting it in one
> place and using it in another architecture.

Shouldn't a symlink from x86_64/file to ../i386/file work?  git handles
symlinks just fine.



Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: i386 and x86_64 fenv support

[Joel Sherrill]

On Tue, Aug 27, 2019 at 10:39 AM Corinna Vinschen <vinschen@redhat.com> wrote:
>
> On Aug 27 08:31, Joel Sherrill wrote:
> > Hi
> >
> > Earlier we discussed moving the winsup fenv.h files to newlib. Splitting
> > winsup/cygwin/include/fenv.h to create a sys/fenv.h looks easy enough.
> > But I have some status and a question after tinkering with this code out
> > of tree and compiling with the RTEMS i386 and x86_64
> >
> > It includes winsup.h and wincap.h but it doesn't need them.
>
> Yeah, that's kind of a boilerplate include in Cygwin code.  Just scratch
> it, it can't be overly important for the fenv functionality.
>
> > [...]
> > There are prototypes for fegetprec() and fesetprec(). I think the
> > prototypes need to move to the shared fenv.h and commented
> > stubs for the constants needs to be in the shared dummy sys/fenv.h.
> > Does this sound right?
>
> As far as I can see, none of Linux or BSD have these functions.  It may
> be the right thing to do to keep them local to Cygwin since they never
> made it into a standard or one of the systems we're interested in here.
>
> Ideally they are never defined in a header, not even on Cygwin.  We only
> have to keep exporting these symbols in Cygwin for backward compat.

OK. They will disappear from the machine .h files then if that's OK.

>
> > My remaining issue is that it appears that i386 and x86_64 will need to
> > share the same files. Do I just copy the files to both machine directories?
> > I don't know if newlib's build infrastructure supports putting it in one
> > place and using it in another architecture.
>
> Shouldn't a symlink from x86_64/file to ../i386/file work?  git handles
> symlinks just fine.

Didn't think of that. Sounds good to me.

How does a patch to winsup get handled? Given the fact I can't build it,
should I just let you handle it after the patch is merged into newlib

I'll keep plugging at this slowly.

Thanks.

--joel

>
>
>
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat

Re: i386 and x86_64 fenv support

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]

On Aug 27 10:45, Joel Sherrill wrote:
> On Tue, Aug 27, 2019 at 10:39 AM Corinna Vinschen <vinschen@redhat.com> wrote:
> >
> > On Aug 27 08:31, Joel Sherrill wrote:
> > > Hi
> > >
> > > Earlier we discussed moving the winsup fenv.h files to newlib. Splitting
> > > winsup/cygwin/include/fenv.h to create a sys/fenv.h looks easy enough.
> > > But I have some status and a question after tinkering with this code out
> > > of tree and compiling with the RTEMS i386 and x86_64
> > >
> > > It includes winsup.h and wincap.h but it doesn't need them.
> >
> > Yeah, that's kind of a boilerplate include in Cygwin code.  Just scratch
> > it, it can't be overly important for the fenv functionality.
> >
> > > [...]
> > > There are prototypes for fegetprec() and fesetprec(). I think the
> > > prototypes need to move to the shared fenv.h and commented
> > > stubs for the constants needs to be in the shared dummy sys/fenv.h.
> > > Does this sound right?
> >
> > As far as I can see, none of Linux or BSD have these functions.  It may
> > be the right thing to do to keep them local to Cygwin since they never
> > made it into a standard or one of the systems we're interested in here.
> >
> > Ideally they are never defined in a header, not even on Cygwin.  We only
> > have to keep exporting these symbols in Cygwin for backward compat.
> 
> OK. They will disappear from the machine .h files then if that's OK.

Sure!

> > > My remaining issue is that it appears that i386 and x86_64 will need to
> > > share the same files. Do I just copy the files to both machine directories?
> > > I don't know if newlib's build infrastructure supports putting it in one
> > > place and using it in another architecture.
> >
> > Shouldn't a symlink from x86_64/file to ../i386/file work?  git handles
> > symlinks just fine.
> 
> Didn't think of that. Sounds good to me.
> 
> How does a patch to winsup get handled? Given the fact I can't build it,
> should I just let you handle it after the patch is merged into newlib

Just create the patch, I pick up any problems.

> I'll keep plugging at this slowly.

Reply in PM.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: i386 and x86_64 fenv support

[Joseph Myers]

On Tue, 27 Aug 2019, Joel Sherrill wrote:

> FWIW this moved up in importance because the x86_64 RTEMS toolchain
> won't build with the gcc/newlib master because libquadmath assumes the
> existence of the FE_TONEAREST since it the autoconf probe now sees
> we have fenv.h support now. This is probably a bug in this code since it
> can't assume a rounding mode is supported.

The rule in glibc is that architectures without support for rounding modes 
still define FE_TONEAREST, and return it from fegetround and accept it for 
fesetround, reflecting that to-nearest is the default (and only) rounding 
mode.

That is, only architectures that don't support to-nearest at all should 
fail to define FE_TONEAREST (and libquadmath doesn't support any such 
architectures anyway).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: i386 and x86_64 fenv support

[Joel Sherrill]

On Tue, Aug 27, 2019 at 12:11 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Tue, 27 Aug 2019, Joel Sherrill wrote:
>
> > FWIW this moved up in importance because the x86_64 RTEMS toolchain
> > won't build with the gcc/newlib master because libquadmath assumes the
> > existence of the FE_TONEAREST since it the autoconf probe now sees
> > we have fenv.h support now. This is probably a bug in this code since it
> > can't assume a rounding mode is supported.
>
> The rule in glibc is that architectures without support for rounding modes
> still define FE_TONEAREST, and return it from fegetround and accept it for
> fesetround, reflecting that to-nearest is the default (and only) rounding
> mode.
>
> That is, only architectures that don't support to-nearest at all should
> fail to define FE_TONEAREST (and libquadmath doesn't support any such
> architectures anyway).

So the stub version should define FE_TONEAREST, return 0 if that's the input
to fesetround, and return FE_TONEAREST from fegetround? The discussion
when the behavior was picked was to match soft float. But we could have
easily missed something.

There are other FE_xxx constants used in libquadmath/math and I haven't
looked at them in detail but grep output looked like they were all wrapped
in ifdef's.

--joel

>
> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: i386 and x86_64 fenv support

[Howland, Craig D. - US via newlib]

> From: newlib-owner@sourceware.org <newlib-owner@sourceware.org> on behalf of Joel Sherrill <joel@rtems.org>
> Sent: Tuesday, August 27, 2019 1:30 PM
> To: Joseph Myers
> Cc: Newlib
> Subject: Re: i386 and x86_64 fenv support
>
> On Tue, Aug 27, 2019 at 12:11 PM Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Tue, 27 Aug 2019, Joel Sherrill wrote:
> >
> > > FWIW this moved up in importance because the x86_64 RTEMS toolchain
> > > won't build with the gcc/newlib master because libquadmath assumes the
> > > existence of the FE_TONEAREST since it the autoconf probe now sees
> > > we have fenv.h support now. This is probably a bug in this code since it
> > > can't assume a rounding mode is supported.
> >
> > The rule in glibc is that architectures without support for rounding modes
> > still define FE_TONEAREST, and return it from fegetround and accept it for
> > fesetround, reflecting that to-nearest is the default (and only) rounding
> > mode.
> >
> > That is, only architectures that don't support to-nearest at all should
> > fail to define FE_TONEAREST (and libquadmath doesn't support any such
> > architectures anyway).
>
> So the stub version should define FE_TONEAREST, return 0 if that's the input
> to fesetround, and return FE_TONEAREST from fegetround? The discussion
> when the behavior was picked was to match soft float. But we could have
> easily missed something.
That GLIBC requirement violates what the standards say.  C99 says, "Each of
the macros FE_DOWNWARD FE_TONEAREST FE_TOWARDZERO FE_UPWARD is defined if and 
only if the implementation supports getting and setting the represented 
rounding direction by means of the fegetround and fesetround functions."
This GLIBC rule is saying that you have to pretend FE_TONEAREST works, even
when it does not.  It does half of what is required, allowing that value
with the functions, except they don't really do it.  And it also then 
improperly tells code that is the fixed rounding direction, when it really
is not.  So while I can see how GLIBC might have chosen that for expediency,
I think it is a very bad thing.  The best thing would be to not let GCC 
tell there is fenv support when there is not.  We were fine before, but now
the new fenv.h in Newlib breaks that due to this FE_TONEAREST quirk.  So is 
there a way to have the GCC autoconf libquadmath "have fenv?" check fail 
when we're only supplying the stub?  (It seems to me that it really ought to 
fail if FE_TONEAREST is not defined, since that is required.  I'd call it
a GCC bug, but we can at least try to work around it.)
 
Craig

Re: i386 and x86_64 fenv support

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Tue, 27 Aug 2019, Howland, Craig D. - US via newlib wrote:

> That GLIBC requirement violates what the standards say.  C99 says, "Each of
> the macros FE_DOWNWARD FE_TONEAREST FE_TOWARDZERO FE_UPWARD is defined if and 
> only if the implementation supports getting and setting the represented 
> rounding direction by means of the fegetround and fesetround functions."

If to-nearest is the default and only rounding mode, setting it is a 
no-op, so it would violate the standard not to define FE_TONEAREST, would 
violate the standard not to return success from fesetround (FE_TONEAREST) 
and would violate the standard not to return FE_TONEAREST from fegetround.

If a processor does not support rounding to-nearest (Cell SPU for 
single-precision, for example), of course FE_TONEAREST would not be 
defined (the C standard model doesn't really cover the SPU case where 
single-precision is only FE_TOWARDZERO but double precision handles all 
rounding modes, however).

-- 
Joseph S. Myers
joseph@codesourcery.com