foss-for-synopsys-dwc-arc-processors/toolchain

Newlib's trigonometric functions won't compile by Clang

Opened this issue · 2 comments

Consider a very simple example:

#include <tgmath.h>

float f1, f = 0.5f;

int main(void)
{
        f1 = acos(f);
}

Compile with a full GNU toolchain:

arc-elf32-gcc -c test.c

Compile with a full Clang/LLVM tollchain:

clang -c test.c

Now let's try to compile with Clang and headers of Newlib:

clang -c test.c -I.../newlib/install/arc/include
test.c:8:14: error: '__builtin_choose_expr' requires a constant expression
        f1 = acos(f);
             ^~~~~~~
.../newlib/install/arc/include/tgmath.h:111:20: note: expanded from macro 'acos'
#define acos(__x)               __tg_full(__x, acos)
                                ^~~~~~~~~~~~~~~~~~~~
.../newlib/install/arc/include/tgmath.h:107:2: note: expanded from macro '__tg_full'
        __tg_impl_full(__x, __x, __x, __fn, __fn##f, __fn##l, c##__fn, c##__fn##f, c##__fn##l, __x)
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../newlib/install/arc/include/tgmath.h:96:6: note: expanded from macro '__tg_impl_full'
            __tg_impl_simple(__x, __y, __z, __cfn, __cfnf, __cfnl, __VA_ARGS__),        \
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../newlib/install/arc/include/tgmath.h:86:3: note: expanded from macro '__tg_impl_simple'
                __tg_type_corr(x, y, z, double) || __tg_integer(x, y, z),\
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../newlib/install/arc/include/tgmath.h:71:2: note: expanded from macro '__tg_type_corr'
        (__tg_type3(__e1, __e2, __e3, __t) ||                           \
        ^
1 error generated.

Any ideas on how to fix that? Is that a problem in Newlib or Clang?

Hm, looks like we don't need these headers in Newlib in the first place, as compilers provide its own versions which are known to work for them. See picolibc/picolibc@7c9e9c3 & picolibc/picolibc@e6a8fc6.

Maybe this is an issue which you can discuss it with upstream Newlib maintainers. I see no problem with GNU toolchain.