round() on arm vs aarch64

round() on arm vs aarch64

[Joel Sherrill]

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

Hi

This is likely not a newlib bug but I thought I would start here because
I'm not sure what is going on and I thought someone on this list would have
an idea: This is a simple C++ function that calls std::round. It compiles
on arm but aarch64 says round isn't in the std namespace.

If you change the program to just use round() and not std::round() it
compiles on both architectures.

The compiler versions are the same and report:

arm-rtems6-gcc (GCC) 12.2.1 20221014 (RTEMS 6, RSB
cb8821e93378118e78a9cb25859789b126bd5761, Newlib 0b6342c)

=====================
$ cat r.cc
#include <cmath>



int wrap(double v)

{

  double r = std::round((float)v);

  return (r > 0);

}

[joel@devel round]$ arm-rtems6-gcc -Wall -c r.cc
[joel@devel round]$ aarch64-rtems6-gcc -Wall -c r.cc
r.cc: In function 'int wrap(double)':
r.cc:5:19: error: 'round' is not a member of 'std'; did you mean 'round'?
    5 |   double r = std::round((float)v);
      |                   ^~~~~
In file included from
/home/joel/rtems-work/tools/6/lib/gcc/aarch64-rtems6/12.2.1/include/c++/cmath:45,
                 from r.cc:1:
/home/joel/rtems-work/tools/6/aarch64-rtems6/include/math.h:337:15: note:
'round' declared here
  337 | extern double round (double);
=====================

Any ideas what would cause this?

Thanks

--joel

Re: round() on arm vs aarch64

[Richard Earnshaw]

On 03/11/2022 14:13, Joel Sherrill wrote:
> Hi
> 
> This is likely not a newlib bug but I thought I would start here because
> I'm not sure what is going on and I thought someone on this list would have
> an idea: This is a simple C++ function that calls std::round. It compiles
> on arm but aarch64 says round isn't in the std namespace.
> 
> If you change the program to just use round() and not std::round() it
> compiles on both architectures.
> 
> The compiler versions are the same and report:
> 
> arm-rtems6-gcc (GCC) 12.2.1 20221014 (RTEMS 6, RSB
> cb8821e93378118e78a9cb25859789b126bd5761, Newlib 0b6342c)
> 
> =====================
> $ cat r.cc
> #include <cmath>
> 
> 
> 
> int wrap(double v)
> 
> {
> 
>    double r = std::round((float)v);
> 
>    return (r > 0);
> 
> }
> 
> [joel@devel round]$ arm-rtems6-gcc -Wall -c r.cc
> [joel@devel round]$ aarch64-rtems6-gcc -Wall -c r.cc
> r.cc: In function 'int wrap(double)':
> r.cc:5:19: error: 'round' is not a member of 'std'; did you mean 'round'?
>      5 |   double r = std::round((float)v);
>        |                   ^~~~~
> In file included from
> /home/joel/rtems-work/tools/6/lib/gcc/aarch64-rtems6/12.2.1/include/c++/cmath:45,
>                   from r.cc:1:
> /home/joel/rtems-work/tools/6/aarch64-rtems6/include/math.h:337:15: note:
> 'round' declared here
>    337 | extern double round (double);
> =====================
> 
> Any ideas what would cause this?
> 
> Thanks
> 
> --joel

Have you tried comparing the pre-processed output from the two versions? 
  It might give a clue as to what's going on.

R.

Re: round() on arm vs aarch64

[Joel Sherrill]

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

Digging a bit, I noticed a huge block of <cmath> is ifdef'ed out for
aarch64.
I found the file c++config.h which is different between the two.

Based on the diff of the arm and aarch64 versions, arm has
 _GLIBCXX_USE_C99_MATH_TR1 defined but aarch64 does not.

I have no idea where the settings in this file come from but this
appears to be the key difference.

More insight appreciated.

=====================================================
round]$ diff
 /home/joel/rtems-work/tools/6/lib/gcc/arm-rtems6/12.2.1/include/c++/arm-rtems6/bits/c++config.h
/home/joel/rtems-work/tools/6/lib/gcc/aarch64-rtems6/12.2.1/include/c++/aarch64-rtems6/bits/c++config.h
886c886
< /* #undef _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY */
---
> #define _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY 1
1702c1702
< #define _GLIBCXX_MANGLE_SIZE_T j
---
> #define _GLIBCXX_MANGLE_SIZE_T m
1711c1711
< #define _GLIBCXX_PTRDIFF_T_IS_INT 1
---
> /* #undef _GLIBCXX_PTRDIFF_T_IS_INT */
1717c1717
< #define _GLIBCXX_SIZE_T_IS_UINT 1
---
> /* #undef _GLIBCXX_SIZE_T_IS_UINT */
1774c1774
< #define _GLIBCXX_USE_C99_MATH_TR1 1
---
> /* #undef _GLIBCXX_USE_C99_MATH_TR1 */
=====================================================


On Mon, Nov 7, 2022 at 11:28 AM Richard Earnshaw <
Richard.Earnshaw@foss.arm.com> wrote:

>
>
> On 03/11/2022 14:13, Joel Sherrill wrote:
> > Hi
> >
> > This is likely not a newlib bug but I thought I would start here because
> > I'm not sure what is going on and I thought someone on this list would
> have
> > an idea: This is a simple C++ function that calls std::round. It compiles
> > on arm but aarch64 says round isn't in the std namespace.
> >
> > If you change the program to just use round() and not std::round() it
> > compiles on both architectures.
> >
> > The compiler versions are the same and report:
> >
> > arm-rtems6-gcc (GCC) 12.2.1 20221014 (RTEMS 6, RSB
> > cb8821e93378118e78a9cb25859789b126bd5761, Newlib 0b6342c)
> >
> > =====================
> > $ cat r.cc
> > #include <cmath>
> >
> >
> >
> > int wrap(double v)
> >
> > {
> >
> >    double r = std::round((float)v);
> >
> >    return (r > 0);
> >
> > }
> >
> > [joel@devel round]$ arm-rtems6-gcc -Wall -c r.cc
> > [joel@devel round]$ aarch64-rtems6-gcc -Wall -c r.cc
> > r.cc: In function 'int wrap(double)':
> > r.cc:5:19: error: 'round' is not a member of 'std'; did you mean 'round'?
> >      5 |   double r = std::round((float)v);
> >        |                   ^~~~~
> > In file included from
> >
> /home/joel/rtems-work/tools/6/lib/gcc/aarch64-rtems6/12.2.1/include/c++/cmath:45,
> >                   from r.cc:1:
> > /home/joel/rtems-work/tools/6/aarch64-rtems6/include/math.h:337:15: note:
> > 'round' declared here
> >    337 | extern double round (double);
> > =====================
> >
> > Any ideas what would cause this?
> >
> > Thanks
> >
> > --joel
>
> Have you tried comparing the pre-processed output from the two versions?
>   It might give a clue as to what's going on.
>
> R.
>

Re: round() on arm vs aarch64

[Stephanos Ioannidis]

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

On Tue, 2022-11-15 at 09:38 -0600, Joel Sherrill wrote:
> Digging a bit, I noticed a huge block of <cmath> is ifdef'ed out for
> aarch64.
> I found the file c++config.h which is different between the two.
> 
> Based on the diff of the arm and aarch64 versions, arm has
>  _GLIBCXX_USE_C99_MATH_TR1 defined but aarch64 does not.
> 
> I have no idea where the settings in this file come from but this
> appears to be the key difference.
> 
> More insight appreciated.

Funny how I came across a similar issue today. The following link might
be of help in understanding what is going on:

https://github.com/zephyrproject-rtos/sdk-ng/issues/566#issuecomment-1315165640

Regards,

Stephanos

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: round() on arm vs aarch64

[Joel Sherrill]

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

On Tue, Nov 15, 2022 at 9:58 AM Stephanos Ioannidis <root@stephanos.io>
wrote:

> On Tue, 2022-11-15 at 09:38 -0600, Joel Sherrill wrote:
> > Digging a bit, I noticed a huge block of <cmath> is ifdef'ed out for
> > aarch64.
> > I found the file c++config.h which is different between the two.
> >
> > Based on the diff of the arm and aarch64 versions, arm has
> >  _GLIBCXX_USE_C99_MATH_TR1 defined but aarch64 does not.
> >
> > I have no idea where the settings in this file come from but this
> > appears to be the key difference.
> >
> > More insight appreciated.
>
> Funny how I came across a similar issue today. The following link might
> be of help in understanding what is going on:
>
>
> https://github.com/zephyrproject-rtos/sdk-ng/issues/566#issuecomment-1315165640


Thanks for the quick reply. It is a shame that the lack of long double
methods
prevents the entire TR1 from being there. Wouldn't it be ok to just have the
prototypes and let the user get a link error?

Anyway, I have been very very slowly picking at newlib long double support
but haven't gotten a complete patch set that is acceptable. See
https://sourceware.org/newlib/ for the discussion. I am happy to share
my work in process.

As I recall, one of the sticking points is that the FreeBSD code has
long double support for architectures which have true long double but
nothing as far as I can tell for architectures where double == long double.
I was proposing a configure time selection of the current code for when
long double == double and use the imported FreeBSD code when there
is true long double support.

Making libstdc++'s configure probe more forgiving would be a nice step
but long term having complete long double support would be better.

How to progress?

--joel


>
> Regards,
>
> Stephanos
>