[PATCH] newlib: remove unused fenv flags

[PATCH] newlib: remove unused fenv flags

[Mike Frysinger]

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

Re: [PATCH] newlib: remove unused fenv flags

[Corinna Vinschen]

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

Re: [PATCH] newlib: remove unused fenv flags

[C Howland]

>
>
> ------------------------------
> *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.
Craig

Re: [PATCH] newlib: remove unused fenv flags

[Joel Sherrill]

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

Re: [PATCH] newlib: remove unused fenv flags

[Mike Frysinger]

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

On 10 Feb 2022 13:02, C Howland wrote:
> > 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.
> 
> 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.

you seemed to be confused as to how this works.  there is no machine code
here.  there are only stubs.  machine code lives under libm/machine/$arch/,
not under libm/fenv/.  compiler flags in one directory only affects files
in that one directory, they don't propagate out to every other directory in
the build.

i'll also note that none of the machine code explicitly uses -fno-builtin.
there is a configure option for it that affects all newlib files instead.

so either cite exactly what doesn't work, or withdraw your objection please.
-mike

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

Re: [PATCH] newlib: remove unused fenv flags

[C Howland]

On Thu, 10 Feb 2022 at 13:41, Mike Frysinger <vapier@gentoo.org> wrote:

> On 10 Feb 2022 13:02, C Howland wrote:
> > > 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.
> >
> > 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.
>
> you seemed to be confused as to how this works.  there is no machine code
> here.  there are only stubs.  machine code lives under libm/machine/$arch/,
> not under libm/fenv/.  compiler flags in one directory only affects files
> in that one directory, they don't propagate out to every other directory in
> the build.
>
> i'll also note that none of the machine code explicitly uses -fno-builtin.
> there is a configure option for it that affects all newlib files instead.
>
> so either cite exactly what doesn't work, or withdraw your objection
> please.
> -mike
>

     Granted, I might be confused as to how this works.  I am aware of the
code in the machine directories.  What I am not familiar with is whether
the flags in the main tree propagate to the machine directories in any way,
and I thought it would, in possibly 2 ways.
     First, would be if a machine directory can override just some files
from the main--as if viewpathed--and this can also apply to the makefile.
(Does the machine directory totally replace the main branch directory, or
can it be supplemental?  My impression was a viewpath model, which can be
supplementary or replace all.)  If I'm wrong about this, no problem, no
objection for this specific reason.
     The second is if the main branch is intended to also be a template for
new machine directories.  The C part of it definitely is, but the makefile
does not necessarily fall into that category.  So I'll turn that into a
question:  if the main branch makefile does not serve as a template for the
machine directories, where would that be?  That is, while these arguments
are superfluous in the main dir,  should they remain in comments as an aid
to machine developers, in the same manner in which the source code is
annotated?  (It's not so much these specific arguments, themselves, but
having an example how ones like this would be added.  These particular ones
are reasonable for serving that purpose, however.)  The real makefile seems
the best place for this.  We could have Makefile.template, or something
along those lines, but the real one is forced to be valid by being used,
while maintaining a separate template would be additional maintenance work.
     So if I'm wrong about the viewpathing model, a suggestion:  rather
than deleting the lines, comment them out and add some comment text
suitable for a template.  If you're amenable to this approach and would
like, I (or possibly Joel if he's interested) could contribute suggested
comments for you to use.
                          Craig

Re: [PATCH] newlib: remove unused fenv flags

[Joel Sherrill]

On Thu, Feb 10, 2022 at 1:18 PM C Howland <cc1964t@gmail.com> wrote:
>
> On Thu, 10 Feb 2022 at 13:41, Mike Frysinger <vapier@gentoo.org> wrote:
>
> > On 10 Feb 2022 13:02, C Howland wrote:
> > > > 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.
> > >
> > > 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.
> >
> > you seemed to be confused as to how this works.  there is no machine code
> > here.  there are only stubs.  machine code lives under libm/machine/$arch/,
> > not under libm/fenv/.  compiler flags in one directory only affects files
> > in that one directory, they don't propagate out to every other directory in
> > the build.
> >
> > i'll also note that none of the machine code explicitly uses -fno-builtin.
> > there is a configure option for it that affects all newlib files instead.
> >
> > so either cite exactly what doesn't work, or withdraw your objection
> > please.
> > -mike
> >
>
>      Granted, I might be confused as to how this works.  I am aware of the
> code in the machine directories.  What I am not familiar with is whether
> the flags in the main tree propagate to the machine directories in any way,
> and I thought it would, in possibly 2 ways.
>      First, would be if a machine directory can override just some files
> from the main--as if viewpathed--and this can also apply to the makefile.
> (Does the machine directory totally replace the main branch directory, or
> can it be supplemental?  My impression was a viewpath model, which can be
> supplementary or replace all.)  If I'm wrong about this, no problem, no
> objection for this specific reason.
>      The second is if the main branch is intended to also be a template for
> new machine directories.  The C part of it definitely is, but the makefile
> does not necessarily fall into that category.  So I'll turn that into a
> question:  if the main branch makefile does not serve as a template for the
> machine directories, where would that be?  That is, while these arguments
> are superfluous in the main dir,  should they remain in comments as an aid
> to machine developers, in the same manner in which the source code is
> annotated?  (It's not so much these specific arguments, themselves, but
> having an example how ones like this would be added.  These particular ones
> are reasonable for serving that purpose, however.)  The real makefile seems
> the best place for this.  We could have Makefile.template, or something
> along those lines, but the real one is forced to be valid by being used,
> while maintaining a separate template would be additional maintenance work.
>      So if I'm wrong about the viewpathing model, a suggestion:  rather
> than deleting the lines, comment them out and add some comment text
> suitable for a template.  If you're amenable to this approach and would
> like, I (or possibly Joel if he's interested) could contribute suggested
> comments for you to use.

One significant purpose for the files in libm/fenv is that is where
the documentation
for the fenv.h methods comes from.  They are not just implementation templates.

And I still think they are the default implementation for targets which do
not have target specific implementations.

All of the architectures that were added by RTEMS GSoC students
came from other projects (FreeBSD, NetBSD, etc) and did not
use these as templates.

--joel

>                           Craig

Re: [PATCH] newlib: remove unused fenv flags

[Mike Frysinger]

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

On 10 Feb 2022 14:18, C Howland wrote:
>      First, would be if a machine directory can override just some files
> from the main--as if viewpathed--and this can also apply to the makefile.
> (Does the machine directory totally replace the main branch directory, or
> can it be supplemental?  My impression was a viewpath model, which can be
> supplementary or replace all.)  If I'm wrong about this, no problem, no
> objection for this specific reason.

assuming "viewpathed" means "VPATH in the makefile", then no, that's not how
newlib works.  that is how glibc works, so maybe you're thinking of that.
newlib compiles all objects in all subdirs in isolation.  it then assembles
the final libm.a/libc.a in a specific order (with the machine dir last).  so
it adds fenv/*.o to libm.a by basename, then replaces any existing ones with
machine/$arch/*.o.

>      The second is if the main branch is intended to also be a template for
> new machine directories.  The C part of it definitely is, but the makefile
> does not necessarily fall into that category.  So I'll turn that into a
> question:  if the main branch makefile does not serve as a template for the
> machine directories, where would that be?  That is, while these arguments
> are superfluous in the main dir,  should they remain in comments as an aid
> to machine developers, in the same manner in which the source code is
> annotated?  (It's not so much these specific arguments, themselves, but
> having an example how ones like this would be added.  These particular ones
> are reasonable for serving that purpose, however.)  The real makefile seems
> the best place for this.  We could have Makefile.template, or something
> along those lines, but the real one is forced to be valid by being used,
> while maintaining a separate template would be additional maintenance work.
>      So if I'm wrong about the viewpathing model, a suggestion:  rather
> than deleting the lines, comment them out and add some comment text
> suitable for a template.  If you're amenable to this approach and would
> like, I (or possibly Joel if he's interested) could contribute suggested
> comments for you to use.

this isn't specific to fenv/.  you can make this argument against any of
the subdirs.

even then, the use of -fbuiltin & -fno-math-errno kind of seem like the
opposite of what you're arguing.  -fno-math-errno shouldn't be used in
general as it is an optimization that can break correctness wrt IEEE
standards.  -fbuiltin probably shouldn't be applied to entire subdirs
without strict review since it allows the compiler to rewrite calls
that assume C library behavior, but the C library might be violating
those assumptions specifically as part of its implementation.
-mike

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

Re: [PATCH] newlib: remove unused fenv flags

[C Howland]

On Fri, 11 Feb 2022 at 05:09, Mike Frysinger <vapier@gentoo.org> wrote:

> On 10 Feb 2022 14:18, C Howland wrote:
> >      First, would be if a machine directory can override just some files
> > from the main--as if viewpathed--and this can also apply to the makefile.
> > (Does the machine directory totally replace the main branch directory, or
> > can it be supplemental?  My impression was a viewpath model, which can be
> > supplementary or replace all.)  If I'm wrong about this, no problem, no
> > objection for this specific reason.
>
> assuming "viewpathed" means "VPATH in the makefile", then no, that's not
> how
> newlib works.  that is how glibc works, so maybe you're thinking of that.
> newlib compiles all objects in all subdirs in isolation.  it then assembles
> the final libm.a/libc.a in a specific order (with the machine dir last).
> so
> it adds fenv/*.o to libm.a by basename, then replaces any existing ones
> with
> machine/$arch/*.o.
>

Yes, I meant as in VPATH in a makefile with individual file granularity.
So, yes, I was thinking not the right thing for newlib, sorry for
conflating Newlib with other things.

>
> >      The second is if the main branch is intended to also be a template
> for
> > new machine directories.  The C part of it definitely is, but the
> makefile
> > does not necessarily fall into that category.  So I'll turn that into a
> > question:  if the main branch makefile does not serve as a template for
> the
> > machine directories, where would that be?  That is, while these arguments
> > are superfluous in the main dir,  should they remain in comments as an
> aid
> > to machine developers, in the same manner in which the source code is
> > annotated?  (It's not so much these specific arguments, themselves, but
> > having an example how ones like this would be added.  These particular
> ones
> > are reasonable for serving that purpose, however.)  The real makefile
> seems
> > the best place for this.  We could have Makefile.template, or something
> > along those lines, but the real one is forced to be valid by being used,
> > while maintaining a separate template would be additional maintenance
> work.
> >      So if I'm wrong about the viewpathing model, a suggestion:  rather
> > than deleting the lines, comment them out and add some comment text
> > suitable for a template.  If you're amenable to this approach and would
> > like, I (or possibly Joel if he's interested) could contribute suggested
> > comments for you to use.
>
> this isn't specific to fenv/.  you can make this argument against any of
> the subdirs.
>
> even then, the use of -fbuiltin & -fno-math-errno kind of seem like the
> opposite of what you're arguing.  -fno-math-errno shouldn't be used in
> general as it is an optimization that can break correctness wrt IEEE
> standards.  -fbuiltin probably shouldn't be applied to entire subdirs
> without strict review since it allows the compiler to rewrite calls
> that assume C library behavior, but the C library might be violating
> those assumptions specifically as part of its implementation.
> -mike
>

OK, neither you nor Joel think templating for the makefile to be of much
use, that makes a majority in comments so far and I'll go along.  (Since
fenv is special and tricky I think we would be better off with better
instructions for this one particularly, as it would encourage/help people
to add new targets.)
I agree that these specific compiler options do need care taken.  But
that's part of the reason they're good examples for the fenv environment,
as that's a tricky subject that needs special attention and might need
things like them.  But at the same time I agree that they are also for the
same reason potentially dangerous to suggest.
(By the way, off the specific topic, but thanks for spending all the time
on cleaning up the build process.)
Craig

Re: [PATCH] newlib: remove unused fenv flags

[Mike Frysinger]

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

On 11 Feb 2022 11:10, C Howland wrote:
> On Fri, 11 Feb 2022 at 05:09, Mike Frysinger wrote:
> > On 10 Feb 2022 14:18, C Howland wrote:
> > >      First, would be if a machine directory can override just some files
> > > from the main--as if viewpathed--and this can also apply to the makefile.
> > > (Does the machine directory totally replace the main branch directory, or
> > > can it be supplemental?  My impression was a viewpath model, which can be
> > > supplementary or replace all.)  If I'm wrong about this, no problem, no
> > > objection for this specific reason.
> >
> > assuming "viewpathed" means "VPATH in the makefile", then no, that's not
> > how newlib works.  that is how glibc works, so maybe you're thinking of that.
> > newlib compiles all objects in all subdirs in isolation.  it then assembles
> > the final libm.a/libc.a in a specific order (with the machine dir last).
> > so it adds fenv/*.o to libm.a by basename, then replaces any existing ones
> > with machine/$arch/*.o.
> 
> Yes, I meant as in VPATH in a makefile with individual file granularity.
> So, yes, I was thinking not the right thing for newlib, sorry for
> conflating Newlib with other things.

i'm not sure pulling off a vpath build in newlib would be that easy.  or at
least, it would require writing more custom logic that we get for free when
we use automake.  at this point, with the size of newlib, i'm not sure we
would gain that much.  yes, we double compile the common code, but since the
files are small and so few, so eh.

> OK, neither you nor Joel think templating for the makefile to be of much
> use, that makes a majority in comments so far and I'll go along.  (Since
> fenv is special and tricky I think we would be better off with better
> instructions for this one particularly, as it would encourage/help people
> to add new targets.)
> I agree that these specific compiler options do need care taken.  But
> that's part of the reason they're good examples for the fenv environment,
> as that's a tricky subject that needs special attention and might need
> things like them.  But at the same time I agree that they are also for the
> same reason potentially dangerous to suggest.

with the new unified non-recursive automake patch i posted, it actually
would be feasible to put compiler settings in one makefile and have them
apply to others (by declaring the flags by filename).  but the question
of whether we even want to do that in the first place is still open.
-mike

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

Re: [PATCH] newlib: remove unused fenv flags

[C Howland]

On Sat, 12 Feb 2022 at 15:42, Mike Frysinger <vapier@gentoo.org> wrote:

> On 11 Feb 2022 11:10, C Howland wrote:
> > On Fri, 11 Feb 2022 at 05:09, Mike Frysinger wrote:
> > > On 10 Feb 2022 14:18, C Howland wrote:
> > > >      First, would be if a machine directory can override just some
> files
> > > > from the main--as if viewpathed--and this can also apply to the
> makefile.
> > > > (Does the machine directory totally replace the main branch
> directory, or
> > > > can it be supplemental?  My impression was a viewpath model, which
> can be
> > > > supplementary or replace all.)  If I'm wrong about this, no problem,
> no
> > > > objection for this specific reason.
> > >
> > > assuming "viewpathed" means "VPATH in the makefile", then no, that's
> not
> > > how newlib works.  that is how glibc works, so maybe you're thinking
> of that.
> > > newlib compiles all objects in all subdirs in isolation.  it then
> assembles
> > > the final libm.a/libc.a in a specific order (with the machine dir
> last).
> > > so it adds fenv/*.o to libm.a by basename, then replaces any existing
> ones
> > > with machine/$arch/*.o.
> >
> > Yes, I meant as in VPATH in a makefile with individual file granularity.
> > So, yes, I was thinking not the right thing for newlib, sorry for
> > conflating Newlib with other things.
>
> i'm not sure pulling off a vpath build in newlib would be that easy.  or at
> least, it would require writing more custom logic that we get for free when
> we use automake.  at this point, with the size of newlib, i'm not sure we
> would gain that much.  yes, we double compile the common code, but since
> the
> files are small and so few, so eh.
>
> > OK, neither you nor Joel think templating for the makefile to be of much
> > use, that makes a majority in comments so far and I'll go along.  (Since
> > fenv is special and tricky I think we would be better off with better
> > instructions for this one particularly, as it would encourage/help people
> > to add new targets.)
> > I agree that these specific compiler options do need care taken.  But
> > that's part of the reason they're good examples for the fenv environment,
> > as that's a tricky subject that needs special attention and might need
> > things like them.  But at the same time I agree that they are also for
> the
> > same reason potentially dangerous to suggest.
>
> with the new unified non-recursive automake patch i posted, it actually
> would be feasible to put compiler settings in one makefile and have them
> apply to others (by declaring the flags by filename).  but the question
> of whether we even want to do that in the first place is still open.
> -mike
>


Given the "take whole machine directory" model, it's probably best to take
this patch as proposed.  The thoughts about templating fenv to keep it easy
for people not familiar with automake stuff, trying to avoid that aspect
being an impediment to people taking on doing fenv for a new platform, can
be handled separately by adding some separate notes.
Craig

Re: [PATCH] newlib: remove unused fenv flags

[Joel Sherrill]

On Mon, Feb 14, 2022, 10:50 AM C Howland <cc1964t@gmail.com> wrote:

> On Sat, 12 Feb 2022 at 15:42, Mike Frysinger <vapier@gentoo.org> wrote:
>
> > On 11 Feb 2022 11:10, C Howland wrote:
> > > On Fri, 11 Feb 2022 at 05:09, Mike Frysinger wrote:
> > > > On 10 Feb 2022 14:18, C Howland wrote:
> > > > >      First, would be if a machine directory can override just some
> > files
> > > > > from the main--as if viewpathed--and this can also apply to the
> > makefile.
> > > > > (Does the machine directory totally replace the main branch
> > directory, or
> > > > > can it be supplemental?  My impression was a viewpath model, which
> > can be
> > > > > supplementary or replace all.)  If I'm wrong about this, no
> problem,
> > no
> > > > > objection for this specific reason.
> > > >
> > > > assuming "viewpathed" means "VPATH in the makefile", then no, that's
> > not
> > > > how newlib works.  that is how glibc works, so maybe you're thinking
> > of that.
> > > > newlib compiles all objects in all subdirs in isolation.  it then
> > assembles
> > > > the final libm.a/libc.a in a specific order (with the machine dir
> > last).
> > > > so it adds fenv/*.o to libm.a by basename, then replaces any existing
> > ones
> > > > with machine/$arch/*.o.
> > >
> > > Yes, I meant as in VPATH in a makefile with individual file
> granularity.
> > > So, yes, I was thinking not the right thing for newlib, sorry for
> > > conflating Newlib with other things.
> >
> > i'm not sure pulling off a vpath build in newlib would be that easy.  or
> at
> > least, it would require writing more custom logic that we get for free
> when
> > we use automake.  at this point, with the size of newlib, i'm not sure we
> > would gain that much.  yes, we double compile the common code, but since
> > the
> > files are small and so few, so eh.
> >
> > > OK, neither you nor Joel think templating for the makefile to be of
> much
> > > use, that makes a majority in comments so far and I'll go along.
> (Since
> > > fenv is special and tricky I think we would be better off with better
> > > instructions for this one particularly, as it would encourage/help
> people
> > > to add new targets.)
> > > I agree that these specific compiler options do need care taken.  But
> > > that's part of the reason they're good examples for the fenv
> environment,
> > > as that's a tricky subject that needs special attention and might need
> > > things like them.  But at the same time I agree that they are also for
> > the
> > > same reason potentially dangerous to suggest.
> >
> > with the new unified non-recursive automake patch i posted, it actually
> > would be feasible to put compiler settings in one makefile and have them
> > apply to others (by declaring the flags by filename).  but the question
> > of whether we even want to do that in the first place is still open.
> > -mike
> >
>
>
> Given the "take whole machine directory" model, it's probably best to take
> this patch as proposed.  The thoughts about templating fenv to keep it easy
> for people not familiar with automake stuff, trying to avoid that aspect
> being an impediment to people taking on doing fenv for a new platform, can
> be handled separately by adding some separate notes.
>

I don't know that any of the fenv implementations would have benefited from
a template approach anyway. All the ones I was involved in ported from some
other existing source. We just tried to minimize the changes as we merged
it into the newlib structure.

Certainly if someone does implement it from scratch for newlib first, they
can always copy from an existing implementation. But unless it is unusual
embedded only architecture, will probably always port from another project.

--joel

Craig
>