Re: [PATCH 1/1] fenv support arm

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 07/02/2020 17:33, Joel Sherrill wrote:
> Szabolcs, is the code in question compiled with any feature flags set?

feature flags are not relevant to my issue.

> 
> I see on Linux that the prototypes would be triggered by _GNU_SOURCE while
> in newlib, it is _BSD_SOURCE. Is that possibly contributing?

(feenableexcept should be hidden when compiling
in standard conform mode, _BSD_VISIBLE is a bit
misleading as it is historically a gnu extension
not BSD, but it does not matter: _GNU_SOURCE
exposes _BSD_VISISBLE code.)

> 
> Can you post a test case? The command line that is failing would also help.

the problem is simply that sys/fenv.h has no
function declarations at all with hard float
abi. (fenv.h still has declarations but only
the standard apis) e.g.

echo '#include <fenv.h>
void *p = (void*)feenableexcept;' | \
 arm-none-eabi-gcc -march=armv5te+fp -mfloat-abi=hard -include fenv.h -xc -c -

<stdin>:2:16: error: 'feenableexcept' undeclared here (not in a function); did you mean 'feraiseexcept'?

echo '#include <sys/fenv.h>
void *p = (void*)feraiseexcept;' | \
 arm-none-eabi-gcc -march=armv5te+fp -mfloat-abi=hard -include fenv.h -xc -c -

<stdin>:2:16: error: 'feraiseexcept' undeclared here (not in a function)


> 
> I'd like to not guess at what's wrong.

i can submit a patch for removing the VFP ifndef
but i wanted to understand why is it there?

> 
> --joel
> 
> On Thu, Jul 2, 2020 at 10:48 AM Joel Sherrill <joel@rtems.org> wrote:
> 
> >
> >
> > On Thu, Jul 2, 2020 at 7:11 AM Szabolcs Nagy <szabolcs.nagy@arm.com>
> > wrote:
> >
> >> The 06/03/2020 23:15, Eshan dhawan via Newlib wrote:
> >> > --- /dev/null
> >> > +++ b/newlib/libc/machine/arm/sys/fenv.h
> >> ...
> >> > +#ifndef __ARM_PCS_VFP
> >> > +
> >> > +int feclearexcept(int excepts);
> >> > +int fegetexceptflag(fexcept_t *flagp, int excepts);
> >> > +int fesetexceptflag(const fexcept_t *flagp, int excepts);
> >> > +int feraiseexcept(int excepts);
> >> > +int fetestexcept(int excepts);
> >> > +int fegetround(void);
> >> > +int fesetround(int round);
> >> > +int fegetenv(fenv_t *envp);
> >> > +int feholdexcept(fenv_t *envp);
> >> > +int fesetenv(const fenv_t *envp);
> >> > +int feupdateenv(const fenv_t *envp);
> >> > +#if __BSD_VISIBLE
> >> > +int feenableexcept(int __mask);
> >> > +int fedisableexcept(int __mask);
> >> > +int fegetexcept(void);
> >> > +#endif /* __BSD_VISIBLE */
> >> > +
> >> > +#endif       /* __ARM_PCS_VFP */
> >>
> >> why are these declarations conditional?
> >>
> >
> > The prototypes for the POSIX methods are in the shared fenv.h.
> >
> > Since the ARM has the BSD_VISIBLE extras, those should be left in the arm
> > specific sys/fenv.h.
> >
> > But (I don't think) they need a ARM_PCS_VFP wrapper since there should be
> > an implementation for all multilibs.  We could discuss the BSD_VISIBLE
> > prototypes being moved to <fenv.h> and removed from all the architecture
> > <sys/fenv.h>
> > but that was also how the code I moved from Cygwin to newlib libm was done
> > so
> > maybe there is a reason that I don't know to leave it here.
> >
> >>
> >> i get build failures e.g. in libgfortran
> >> because configure detects the availability
> >> of feenableexcept in libm.a so it starts
> >> using it but then fenv.h does not have the
> >> declaration so compilation fails.
> >>
> >> it seems there is vfp code for all this
> >> so why are the declarations removed?
> >>
> >
> > The FreeBSD headers rely on the architecture sys/fenv.h prototypes
> > even for POSIX standard methods. Most of the block of code is removed
> > because the prototypes were in <fenv.h> which is where this file is
> > included
> > from.
> >
> > Eshan... re-add the BSD_VISIBLE block please and resubmit. It also
> > looks like the test code isn't exercising those methods so that should
> > be updated after this patch is updated. We don't want libfortran broken
> > for longer than neccessary.
> >
> > --joel
> >

--