picolibc is incompatible with xcc / xcc-clang toolchains

[laurenmurphyx64]

Describe the bug

Compilation of picolibc module for picolibc tests fails with XCC on ADSP platforms. Followup to #54224.

A few of the flags used by GCC to build the picolibc module are not compatible with XCC. Different flags are observed to be not working for different versions of XCC toolchain.

RI-2021.7-linux (xcc-clang) + MTL:

clang-10: error: unknown argument: '-fno-printf-return-value'
clang-10: warning: optimization flag '-fsignaling-nans' is not supported [-Wignored-optimization-argument]

RG-2017.8-linux (xcc) + CAVS15, 18, CAVS25:

xt-xcc ERROR parsing -frounding-math:  unknown flag
xt-xcc ERROR parsing -fsignaling-nans:  unknown flag
xt-xcc ERROR parsing -fno-stack-protector:  unknown flag
xt-xcc ERROR parsing -Warray-bounds:  unknown flag
xt-xcc ERROR parsing -ftls-model=local-exec:  unknown flag
xt-xcc ERROR parsing -fno-printf-return-value:  unknown flag

To Reproduce

export ZEPHYR_TOOLCHAIN_VARIANT=xcc
west build -p -b intel_adsp_cavs15 -T tests/kernel/common/kernel.common.picolibc

Expected behavior
Compilation

Impact
Annoyance

Logs and console output
See above.

Environment

• OS: Ubuntu 20.04
• Toolchain: XCC / XCC-clang (see above)
• Recent main

[nashif]

@keith-packard @stephanosio Is picolibc supposed to work with clang ?
gcc based xcc is old and it might have some gaps, but I was expecting clang to work... If not, we need to exclude the like it was done for metaware until we have this working.

[keith-packard]

@keith-packard @stephanosio Is picolibc supposed to work with clang ?

Yes, picolibc is routinely tested with clang. However, the current module using cmake does not work with clang. I've got upstream changes which should resolve this, but have not tested them with Zephyr. Does someone want to give that a try and report back?

I've pushed the current 'main' bits to the zephyr copy of the picolibc repository, so it should be a simple matter of 'git checkout main' in modules/lib/picolibc

[laurenmurphyx64]

@keith-packard @stephanosio Is picolibc supposed to work with clang ?

Yes, picolibc is routinely tested with clang. However, the current module using cmake does not work with clang. I've got upstream changes which should resolve this, but have not tested them with Zephyr. Does someone want to give that a try and report back?

I've pushed the current 'main' bits to the zephyr copy of the picolibc repository, so it should be a simple matter of 'git checkout main' in modules/lib/picolibc

Thanks for your help! I'm now getting this for CAVS15/18/25:

xt-xcc ERROR parsing -ftls-model=local-exec:  unknown flag
xt-xcc ERROR parsing -fno-printf-return-value:  unknown flag

And this for MTL:

clang-10: error: unknown argument: '-fno-printf-return-value'

So that's a lot less errors than before! Commit of main I have after fetching is zephyrproject-rtos/picolibc@a8e2e1f.

[keith-packard]

-fno-printf-return-value comes from Zephyr, and I've pushed a PR (#54345), but the TLS model flag is a problem unless you aren't using thread local storage (TLS) on this target? I've got a fix for that for upstream; I'll get that tested and make sure it doesn't regress anything, but feel free to use the cmake-no-tls branch from the Zephyr picollbc repository and see if that helps.

[nashif]

Given that we are in feaure freeze I suggest to apply this for now while we work on adding clang support:

--- a/lib/libc/Kconfig
+++ b/lib/libc/Kconfig
@@ -19,7 +19,7 @@ config SUPPORT_MINIMAL_LIBC
 config PICOLIBC_SUPPORTED
        bool
        depends on !NATIVE_APPLICATION
-       depends on "$(ZEPHYR_TOOLCHAIN_VARIANT)" != "arcmwdt"
+       depends on "$(ZEPHYR_TOOLCHAIN_VARIANT)" != "arcmwdt" || "$(ZEPHYR_TOOLCHAIN_VARIANT)" != "xcc" || "$(ZEPHYR_TOOLCHAIN_VARIANT)" != "xcc-clang"
        depends on !(CPP && "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "zephyr")
        # picolibc text is outside .pinned.text on this board. #54148
        depends on !BOARD_QEMU_X86_TINY

[keith-packard]

Given that we are in feaure freeze I suggest to apply this for now while we work on adding clang support:

It's a bit more subtle than that -- we're not 'adding' clang support anywhere, just fixing some wiring between the existing clang support in picolibc and the clang support in Zephyr. I'd suggest waiting a couple of days and see how the proposed fixes work out and then decide if clang+picolibc should be removed from the release.