Re: [PATCH] newlib: remove unused fenv flags

[Joel Sherrill <joel@rtems.org>]

On Thu, Feb 10, 2022 at 12:03 PM C Howland <cc1964t@gmail.com> wrote:
>
> >
> >
> > ------------------------------
> > *From:* Newlib <newlib-bounces+craig.howland=caci.com@sourceware.org> on
> > behalf of Corinna Vinschen <vinschen@redhat.com>
> > *Sent:* Thursday, February 10, 2022 10:04 AM
> > *To:* newlib@sourceware.org <newlib@sourceware.org>
> > *Subject:* Re: [PATCH] newlib: remove unused fenv flags
> >
> >
> >
> > On Feb 10 00:53, Mike Frysinger wrote:
> > > These look like they were just copied & pasted from common/Makefile.am.
> > > The funcs in this dir are all stubs that don't actually call any math
> > > or builtin functions, and a simple compile shows they produce identical
> > > object code.  So delete to simplify the build rules.
> > > ---
> > >  newlib/libm/fenv/Makefile.am |  3 --
> > >  newlib/libm/fenv/Makefile.in | 90 +++---------------------------------
> > >  2 files changed, 6 insertions(+), 87 deletions(-)
> > >
> > > diff --git a/newlib/libm/fenv/Makefile.am b/newlib/libm/fenv/Makefile.am
> > > index 50b59004c17e..66755e394cb7 100644
> > > --- a/newlib/libm/fenv/Makefile.am
> > > +++ b/newlib/libm/fenv/Makefile.am
> > > @@ -6,11 +6,8 @@ src =        feclearexcept.c fe_dfl_env.c fegetenv.c
> > fegetexceptflag.c \
> > >       fegetround.c feholdexcept.c feraiseexcept.c fesetenv.c \
> > >       fesetexceptflag.c fesetround.c fetestexcept.c feupdateenv.c
> > >
> > > -lib_a_CFLAGS = -fbuiltin -fno-math-errno
> > > -
> > >  noinst_LIBRARIES = lib.a
> > >  lib_a_SOURCES = $(src)
> > > -lib_a_CFLAGS += $(AM_CFLAGS)
> > >
> > >  # A partial dependency list.
> > >
> > > --
> > > 2.34.1
> >
> > Ok.
> >
> >
> > Thanks,
> > Corinna
> >
>
>
> No, not OK, it doesn't sound like.  The fenv functions are all
> machine-specific and the files in the libm/fenv directory are all stubs
> (which they clearly state internally).  Unless all targets were checked
> (and it doesn't sound like they were), the conclusion is faulty that no
> difference happens.  Taking away -fbuiltin would definitely break any
> machine source relying on it, but not the stubs.

I think these are analogous to the default implementations of
str* and mem* methods. All libm builds should get a stub if they
don't provide an architecture specific override. And the only way
to get a functional implementation AFAIK is to have an architecture
specific version.

I know I helped add a lot of these implementations but I'm drawing
a blank beyond that.

--joel

> Craig