picolibc is incompatible with xcc / xcc-clang toolchains #54336

laurenmurphyx64 · 2023-02-01T23:05:23Z

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

The text was updated successfully, but these errors were encountered:

nashif · 2023-02-02T01:10:53Z

@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 · 2023-02-02T02:10:05Z

@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 · 2023-02-02T02:52:49Z

@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 · 2023-02-02T05:18:39Z

-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 · 2023-02-02T10:03:38Z

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 · 2023-02-02T18:18:56Z

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.

keith-packard · 2023-02-03T00:39:52Z

I think merging #54391 and #54345 will resolve this issue, but I have no way to test. Looks like xcc (not clang based) needs #54392 as well.

laurenmurphyx64 · 2023-02-03T03:47:32Z

@keith-packard @stephanosio @teburd See #54345 (comment)

@nashif Seems like the xcc-clang + MTL stuff works, the xt-xcc + CAVS stuff is what we need now

keith-packard · 2023-02-03T04:08:15Z

@keith-packard @stephanosio @teburd See #54345 (comment)

@nashif Seems like the xcc-clang + MTL stuff works, the xt-xcc + CAVS stuff is what we need now

Check out #54392 and #54394

keith-packard · 2023-02-03T04:52:54Z

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

Having discovered that 'xcc' is based off a 'mature' version of gcc (pre 4.5), I think half of your patch should be applied, that which disables picolibc support for the xcc compiler, until picolibc has support for that compiler integrated, and perhaps past the current Zephyr release process to see if we can't get some testing of picolibc using that compiler first.

nashif · 2023-02-03T15:54:28Z

hmm, still getting:

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

galak · 2023-02-03T15:59:30Z

I wonder if something like @nashif proposed patches makes sense, in that we should have config PICOLIBC_SUPPORTED depend on toolchains its actually been tested with.

The assumption in the current depends on assumes all toolchains work w/picolibc which I don't think is reasonable. For example, have we tested this with arm-clang? Does this work with Oticon's toolchain (I doubt it)?

keith-packard · 2023-02-03T18:30:42Z

I wonder if something like @nashif proposed patches makes sense, in that we should have config PICOLIBC_SUPPORTED depend on toolchains its actually been tested with.

I guess the question is 'tested how?' Zephyr doesn't have comprehensive C library tests integrated, so even the minimal C library is only lightly tested today. Picolibc gets comprehensive testing in CI, but only on a subset of platforms as that testing relies on qemu support. It would be great to extend that testing to more platforms through the Zephyr testing ecosystem; the requirements for picolibc tests are intentionally very light on the OS.

The recent clang issues relate only to the cmake build system added to picolibc for Zephyr support; normally picolibc is built with meson (as with the Zephyr SDK). If Zephyr were to permit the use of meson within a module, there should have been no issues with clang.

The assumption in the current depends on assumes all toolchains work w/picolibc which I don't think is reasonable. For example, have we tested this with arm-clang? Does this work with Oticon's toolchain (I doubt it)?

#54391 addresses the cmake issues within picolibc when using clang; the code in picolibc has been tested on arm using clang for several years, but using meson instead of cmake. I'm not aware of the Oticon toolchain, but if it's gcc or clang based (and not 13 years old), I'm confident it will work at least as well as the minimal C library.

keith-packard · 2023-02-03T18:31:46Z

hmm, still getting:

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

that's odd -- care to debug why #54345 didn't eliminate this?

nashif · 2023-02-07T02:16:09Z

is this really closed?

keith-packard · 2023-02-07T02:47:20Z

I'm not sure -- I think the clang issues are resolved now (except for your mystic problem?) -- the xcc issue relates to the GCC-based toolchain, which we do need to remove from the list of supported toolchains until support for that version of gcc (pre 4.5) is added to picolibc.

nashif · 2023-02-07T02:58:05Z

I'm not sure -- I think the clang issues are resolved now (except for your mystic problem?) -- the xcc issue relates to the GCC-based toolchain, which we do need to remove from the list of supported toolchains until support for that version of gcc (pre 4.5) is added to picolibc.

I am not sure as well tbh, @laurenmurphyx64 are you sure the issues were resolved? I still get the same build problems with current main branch. Please retry.

nashif · 2023-02-07T03:05:53Z

ok, we need to keep this open because #54391 was not merged yet.

and I am getting this now with #54391 checked out:

west  build -p -b intel_adsp_ace15_mtpm tests/kernel/common/ -T kernel.common.picolibc
..
..
..

clang-10: warning: optimization flag '-fsignaling-nans' is not supported [-Wignored-optimization-argument]
[815/957] Building C object modules/picolibc/CMakeFiles/c.dir/newlib/libc/posix/regexec.c.obj
clang-10: warning: optimization flag '-fsignaling-nans' is not supported [-Wignored-optimization-argument]
[816/957] Building C object modules/picolibc/CMakeFiles/c.dir/newlib/libc/posix/regcomp.c.obj
clang-10: warning: optimization flag '-fsignaling-nans' is not supported [-Wignored-optimization-argument]
[940/957] Building C object zephyr/kernel/CMakeFiles/kernel.dir/main_weak.c.obj
FAILED: zephyr/kernel/CMakeFiles/kernel.dir/main_weak.c.obj
ccache /home/nashif/xtensa/XtDevTools/install/tools/RI-2022.10-linux/XtensaTools/bin/xt-clang -DKERNEL -D__LINUX_ERRNO_EXTENSIONS__ -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -I/home/nashif/zephyrproject/zephyr/kernel/include -I/home/nashif/zephyrproject/zephyr/arch/xtensa/include -I/home/nashif/zephyrproject/zephyr/include -I/home/nashif/zephyrproject/zephyr/build/zephyr/include/generated -I/home/nashif/zephyrproject/zephyr/soc/xtensa/intel_adsp/ace -I/home/nashif/zephyrproject/zephyr/soc/xtensa/intel_adsp/ace/include -I/home/nashif/zephyrproject/zephyr/soc/xtensa/intel_adsp/ace/include/intel_ace15_mtpm -I/home/nashif/zephyrproject/zephyr/soc/xtensa/intel_adsp/common/include -I/home/nashif/zephyrproject/zephyr/subsys/testsuite/include -I/home/nashif/zephyrproject/zephyr/subsys/testsuite/ztest/include -I/home/nashif/zephyrproject/zephyr/drivers -isystem /home/nashif/zephyrproject/zephyr/build/modules/picolibc/picolibc/include -fno-strict-aliasing -Os -imacros /home/nashif/zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h -fno-common -g -gdwarf-4 -fcolor-diagnostics -fms-extensions -imacros /home/nashif/zephyrproject/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-typedef-redefinition -Wno-pointer-sign -Wpointer-arith -Wno-sometimes-uninitialized -Wno-shift-overflow -Wno-missing-braces -Wno-self-assign -Wno-address-of-packed-member -Wno-unused-function -Wno-initializer-overrides -Wno-section -Wno-unknown-warning-option -Wno-unused-variable -Wno-format-invalid-specifier -Wno-gnu -Wno-tautological-compare -Werror=implicit-int -fno-asynchronous-unwind-tables -Wno-vla -fmacro-prefix-map=/home/nashif/zephyrproject/zephyr/tests/kernel/common=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/nashif/zephyrproject/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/nashif/zephyrproject=WEST_TOPDIR -ffunction-sections -fdata-sections -mlongcalls -D_POSIX_C_SOURCE=200809 -std=c99 -MD -MT zephyr/kernel/CMakeFiles/kernel.dir/main_weak.c.obj -MF zephyr/kernel/CMakeFiles/kernel.dir/main_weak.c.obj.d -o zephyr/kernel/CMakeFiles/kernel.dir/main_weak.c.obj -c /home/nashif/zephyrproject/zephyr/kernel/main_weak.c
/home/nashif/zephyrproject/zephyr/kernel/main_weak.c:27:1: error: 'main' must return 'int'
void __weak main(void)
^~~~
int
1 error generated.

hmmm, did not see all of that last week. Will have to continue debugging tomorrow..

nashif · 2023-02-07T03:08:57Z

btw, another issues I have seen is due to this:

choice LIBC_IMPLEMENTATION
        prompt "C Library Implementation"
        default EXTERNAL_LIBC if NATIVE_APPLICATION
        default NEWLIB_LIBC if REQUIRES_FULL_LIBC
        default MINIMAL_LIBC

PICOLIBC_SUPPORTED now triggers this to be enabled but then we select newlibc instead of picolibc, i.e. see tests/subsys/logging/log_switch_format/testcase.yaml where it has:
filter: (TOOLCHAIN_HAS_NEWLIB == 1) or CONFIG_PICOLIBC_SUPPORTED

This generate build failures in tests because the filter becomes true, but newlib is selected and if it is not supported, the test fails to build.

keith-packard · 2023-02-07T05:15:47Z

clang-10: warning: optimization flag '-fsignaling-nans' is not supported [-Wignored-optimization-argument]
[815/957] Building C object modules/picolibc/CMakeFiles/c.dir/newlib/libc/posix/regexec.c.obj
clang-10: warning: optimization flag '-fsignaling-nans' is not supported [-Wignored-optimization-argument]
[816/957] Building C object modules/picolibc/CMakeFiles/c.dir/newlib/libc/posix/regcomp.c.obj
clang-10: warning: optimization flag '-fsignaling-nans' is not supported [-Wignored-optimization-argument]

Hrm. There's code in #54391 which should be filtering this flag out but it doesn't appear to be working in your configuration.

/home/nashif/zephyrproject/zephyr/kernel/main_weak.c:27:1: error: 'main' must return 'int'
void __weak main(void)
^~~~
int

clang splits out warnings about main return type from other main related warnings. We need to add -Wno-main-return-type. #54525 has a proposed fix.

This isn't directly picolibc related, rather it's caused by removing the -ffreestanding compiler flag while building with picolibc. It's somewhat tempting to back out that change, but given the tremendous benefits in safety and performance available from having the compiler know that the C library is standards compliant, I really hope that isn't necessary.

keith-packard · 2023-02-07T05:34:14Z

see tests/subsys/logging/log_switch_format/testcase.yaml where it has: filter: (TOOLCHAIN_HAS_NEWLIB == 1) or CONFIG_PICOLIBC_SUPPORTED

Looks like that pattern occurs in a handful of test configuration files. What solution would you like here? Do you want to skip the test? Or do you want to use picolibc instead? And, do you want to continue to use newlib on platforms that support it? Or switch to picolibc everywhere?

laurenmurphyx64 · 2023-02-07T08:16:36Z

@nashif @keith-packard I cherrypicked both of those PRs and can replicate that the fix #54525 isn't working for us for some reason

$ west build -p -b intel_adsp_ace15_mtpm_sim -T tests/kernel/common/kernel.common.picolibc
...
[332/1047] Building C object modules/picolibc/CMakeFiles/c.dir/newlib/libc/string/memmove.c.obj
/home/laurenmu/zephyrproject/modules/lib/picolibc/newlib/libc/string/memmove.c:71:1: warning: malformed 'optimize' attribute '-fno-tree-loop-distribute-patterns' [-Wattribute-optimize]
__inhibit_loop_to_libcall
^
/home/laurenmu/zephyrproject/zephyr/build/modules/picolibc/picolibc/include/sys/cdefs.h:548:33: note: expanded from macro '__inhibit_loop_to_libcall'
  __attribute__ ((__optimize__ ("-fno-tree-loop-distribute-patterns")))
                                ^
1 warning generated.
[746/1047] Building C object modules/picolibc/CMakeFiles/c.dir/newlib/libm/math/sf_erf.c.obj
/tmp/sf_erf-35159d.s: Assembler messages:
/tmp/sf_erf-35159d.s:1185: Warning: value 0x4f80000000000000 truncated to 0x0
...
/home/laurenmu/zephyrproject/zephyr/subsys/testsuite/ztest/src/ztest_new.c:1029:1: error: 'main' must return 'int'
void main(void)
^~~~
int

nashif · 2023-02-07T12:13:16Z

even with -Wno-main-return-type

ccache /home/nashif/xtensa/XtDevTools/install/tools/RI-2022.10-linux/XtensaTools/bin/xt-clang -DKERNEL -D__LINUX_ERRNO_EXTENSIONS__ -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -I/home/nashif/zephyrproject/zephyr/kernel/include -I/home/nashif/zephyrproject/zephyr/arch/xtensa/include -I/home/nashif/zephyrproject/zephyr/include -I/home/nashif/zephyrproject/zephyr/build/zephyr/include/generated -I/home/nashif/zephyrproject/zephyr/soc/xtensa/intel_adsp/ace -I/home/nashif/zephyrproject/zephyr/soc/xtensa/intel_adsp/ace/include -I/home/nashif/zephyrproject/zephyr/soc/xtensa/intel_adsp/ace/include/intel_ace15_mtpm -I/home/nashif/zephyrproject/zephyr/soc/xtensa/intel_adsp/common/include -I/home/nashif/zephyrproject/zephyr/subsys/testsuite/include -I/home/nashif/zephyrproject/zephyr/subsys/testsuite/ztest/include -I/home/nashif/zephyrproject/zephyr/drivers -isystem /home/nashif/zephyrproject/zephyr/build/modules/picolibc/picolibc/include -fno-strict-aliasing -Os -imacros /home/nashif/zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h -fno-common -g -gdwarf-4 -fcolor-diagnostics -fms-extensions -imacros /home/nashif/zephyrproject/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-main-return-type -Wno-typedef-redefinition -Wno-pointer-sign -Wpointer-arith -Wno-sometimes-uninitialized -Wno-shift-overflow -Wno-missing-braces -Wno-self-assign -Wno-address-of-packed-member -Wno-unused-function -Wno-initializer-overrides -Wno-section -Wno-unknown-warning-option -Wno-unused-variable -Wno-format-invalid-specifier -Wno-gnu -Wno-tautological-compare -Werror=implicit-int -fno-asynchronous-unwind-tables -Wno-vla -fmacro-prefix-map=/home/nashif/zephyrproject/zephyr/tests/kernel/common=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/nashif/zephyrproject/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/nashif/zephyrproject=WEST_TOPDIR -ffunction-sections -fdata-sections -mlongcalls -D_POSIX_C_SOURCE=200809 -std=c99 -MD -MT zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj -MF zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj.d -o zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj -c /home/nashif/zephyrproject/zephyr/kernel/init.c
/home/nashif/zephyrproject/zephyr/kernel/init.c:327:9: error: 'main' must return 'int'
        extern void main(void);
               ^~~~
               int
1 error generated.

nashif · 2023-02-07T12:21:59Z

Looks like that pattern occurs in a handful of test configuration files. What solution would you like here? Do you want to skip the test? Or do you want to use picolibc instead? And, do you want to continue to use newlib on platforms that support it? Or switch to picolibc everywhere?

We need to fix that logic. It does not need to be newlib, we need to enable whatever is supported and needed, right now it is hardcoded to newlib which is wrong.

keith-packard · 2023-02-07T22:10:15Z

even with -Wno-main-return-type

ccache /home/nashif/xtensa/XtDevTools/install/tools/RI-2022.10-linux/XtensaTools/bin/xt-clang -DKERNEL -D__LINUX_ERRNO_EXTENSIONS__ -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -I/home/nashif/zephyrproject/zephyr/kernel/include -I/home/nashif/zephyrproject/zephyr/arch/xtensa/include -I/home/nashif/zephyrproject/zephyr/include -I/home/nashif/zephyrproject/zephyr/build/zephyr/include/generated -I/home/nashif/zephyrproject/zephyr/soc/xtensa/intel_adsp/ace -I/home/nashif/zephyrproject/zephyr/soc/xtensa/intel_adsp/ace/include -I/home/nashif/zephyrproject/zephyr/soc/xtensa/intel_adsp/ace/include/intel_ace15_mtpm -I/home/nashif/zephyrproject/zephyr/soc/xtensa/intel_adsp/common/include -I/home/nashif/zephyrproject/zephyr/subsys/testsuite/include -I/home/nashif/zephyrproject/zephyr/subsys/testsuite/ztest/include -I/home/nashif/zephyrproject/zephyr/drivers -isystem /home/nashif/zephyrproject/zephyr/build/modules/picolibc/picolibc/include -fno-strict-aliasing -Os -imacros /home/nashif/zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h -fno-common -g -gdwarf-4 -fcolor-diagnostics -fms-extensions -imacros /home/nashif/zephyrproject/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-main-return-type -Wno-typedef-redefinition -Wno-pointer-sign -Wpointer-arith -Wno-sometimes-uninitialized -Wno-shift-overflow -Wno-missing-braces -Wno-self-assign -Wno-address-of-packed-member -Wno-unused-function -Wno-initializer-overrides -Wno-section -Wno-unknown-warning-option -Wno-unused-variable -Wno-format-invalid-specifier -Wno-gnu -Wno-tautological-compare -Werror=implicit-int -fno-asynchronous-unwind-tables -Wno-vla -fmacro-prefix-map=/home/nashif/zephyrproject/zephyr/tests/kernel/common=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/nashif/zephyrproject/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/nashif/zephyrproject=WEST_TOPDIR -ffunction-sections -fdata-sections -mlongcalls -D_POSIX_C_SOURCE=200809 -std=c99 -MD -MT zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj -MF zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj.d -o zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj -c /home/nashif/zephyrproject/zephyr/kernel/init.c
/home/nashif/zephyrproject/zephyr/kernel/init.c:327:9: error: 'main' must return 'int'
        extern void main(void);
               ^~~~
               int
1 error generated.

I finally went and dug through the clang source code to figure this out. When building in -std=c99 mode, clang does not allow main to have anything other than int return type. -Wno-main-return-type only works in GCC compatibility modes.

This isn't related to picolibc itself, but to the removal of the -ffreestanding flag (which picolibc enables). Would a patch which changes the return type of all main instances to int be acceptable? I don't see alternatives to make clang happy. It does add an instruction to the function (to clear the return value register).

Is there general understanding of the benefits of removing -ffreestanding? Or is this still something that people don't believe should happen?

stephanosio · 2023-02-08T07:50:28Z

Is there general understanding of the benefits of removing -ffreestanding? Or is this still something that people don't believe should happen?

IMO, removing -ffreestanding when using a full libc implementation such as picolibc is the right thing to do because we then have access to the C standard library functions and the program startup is already handled by the underlying system (i.e. Zephyr kernel) regardless of which libc is used, which matches the description of a "hosted environment" (i.e. not 'freestanding enviroment").

The only time -ffreestanding should be specified is when using an incomplete C standard library implementation such as the minimal libc.

This isn't related to picolibc itself, but to the removal of the -ffreestanding flag (which picolibc enables). Would a patch which changes the return type of all main instances to int be acceptable?

I think that is sensible. After all, both C and C++ standards require the main function to have the return type of int in case of a "hosted environment," which Zephyr should be and currently is with the picolibc.

The Zephyr main function having the return type of void has caused various problems in the past; notably in case of C++ applications for which the main function must return int and, in fact, the Zephyr main function already returns int in case of C++ because of this.

So, I am all for changing the Zephyr main function to return int instead of void.

It does add an instruction to the function (to clear the return value register).

That one instruction in the main function is a one-time deal -- main is not an inline function nor is it called over and over again. Adding one extra instruction to main, for all practical purposes, should not matter.

keith-packard · 2023-02-08T22:48:36Z

Looks like that pattern occurs in a handful of test configuration files. What solution would you like here? Do you want to skip the test? Or do you want to use picolibc instead? And, do you want to continue to use newlib on platforms that support it? Or switch to picolibc everywhere?

We need to fix that logic. It does not need to be newlib, we need to enable whatever is supported and needed, right now it is hardcoded to newlib which is wrong.

How about #54637 ? Happy to adjust to suit.

Adds picolibc to XCC Twister quarantine file as compilation of picolibc module fails with XCC on ADSP platforms. Bug zephyrproject-rtos#54336 filed upstream. Signed-off-by: Lauren Murphy <[email protected]>

laurenmurphyx64 added bug The issue is a bug, or the PR is fixing a bug platform: Intel ADSP Intel Audio platforms area: picolibc Picolibc C Standard Library labels Feb 1, 2023

laurenmurphyx64 added the priority: low Low impact/importance bug label Feb 2, 2023

laurenmurphyx64 self-assigned this Feb 2, 2023

stephanosio mentioned this issue Feb 2, 2023

compiler/clang: Erase 'no_printf_return_value' prop for clang #54345

Merged

nashif changed the title ~~intel_adsp: xcc incompatible with picolibc~~ picolibc is incompatible with clang toolchains Feb 2, 2023

nashif assigned keith-packard and unassigned laurenmurphyx64 Feb 2, 2023

keith-packard mentioned this issue Feb 3, 2023

modules/picolibc: Include picolibc with clang+cmake build fixes #54391

Merged

stephanosio mentioned this issue Feb 3, 2023

modules/picolibc: Include clang+cmake and old GCC changes #54394

Merged

carlescufi closed this as completed in #54345 Feb 6, 2023

nashif reopened this Feb 7, 2023

laurenmurphyx64 changed the title ~~picolibc is incompatible with clang toolchains~~ picolibc is incompatible with xcc / xcc-clang toolchains Feb 7, 2023

laurenmurphyx64 mentioned this issue Feb 7, 2023

picolibc: picolibc still not fully supported with many toolchains variants #54523

Merged

laurenmurphyx64 linked a pull request Feb 7, 2023 that will close this issue

compilers/xcc: Disable -fno-printf-return-value property #54392

Closed

stephanosio mentioned this issue Feb 7, 2023

compiler/clang: ignore main-return-type warning for clang #54525

Merged

stephanosio mentioned this issue Feb 8, 2023

Switch return type of main from 'void' to 'int' #54628

Merged

keith-packard mentioned this issue Feb 8, 2023

Only use -ffreestanding with minimal C library #54638

Merged

fabiobaltieri closed this as completed in #54525 Feb 20, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

picolibc is incompatible with xcc / xcc-clang toolchains #54336

picolibc is incompatible with xcc / xcc-clang toolchains #54336

laurenmurphyx64 commented Feb 1, 2023 •

edited by nashif

Loading

nashif commented Feb 2, 2023

keith-packard commented Feb 2, 2023 •

edited

Loading

laurenmurphyx64 commented Feb 2, 2023 •

edited

Loading

keith-packard commented Feb 2, 2023 •

edited

Loading

nashif commented Feb 2, 2023 •

edited

Loading

keith-packard commented Feb 2, 2023

keith-packard commented Feb 3, 2023 •

edited

Loading

laurenmurphyx64 commented Feb 3, 2023 •

edited

Loading

keith-packard commented Feb 3, 2023 •

edited

Loading

keith-packard commented Feb 3, 2023 •

edited

Loading

nashif commented Feb 3, 2023

galak commented Feb 3, 2023

keith-packard commented Feb 3, 2023

keith-packard commented Feb 3, 2023

nashif commented Feb 7, 2023

keith-packard commented Feb 7, 2023

nashif commented Feb 7, 2023

nashif commented Feb 7, 2023 •

edited

Loading

nashif commented Feb 7, 2023 •

edited

Loading

keith-packard commented Feb 7, 2023 •

edited

Loading

keith-packard commented Feb 7, 2023

laurenmurphyx64 commented Feb 7, 2023

nashif commented Feb 7, 2023

nashif commented Feb 7, 2023

keith-packard commented Feb 7, 2023

stephanosio commented Feb 8, 2023

keith-packard commented Feb 8, 2023 •

edited

Loading

picolibc is incompatible with xcc / xcc-clang toolchains #54336

picolibc is incompatible with xcc / xcc-clang toolchains #54336

Comments

laurenmurphyx64 commented Feb 1, 2023 • edited by nashif Loading

nashif commented Feb 2, 2023

keith-packard commented Feb 2, 2023 • edited Loading

laurenmurphyx64 commented Feb 2, 2023 • edited Loading

keith-packard commented Feb 2, 2023 • edited Loading

nashif commented Feb 2, 2023 • edited Loading

keith-packard commented Feb 2, 2023

keith-packard commented Feb 3, 2023 • edited Loading

laurenmurphyx64 commented Feb 3, 2023 • edited Loading

keith-packard commented Feb 3, 2023 • edited Loading

keith-packard commented Feb 3, 2023 • edited Loading

nashif commented Feb 3, 2023

galak commented Feb 3, 2023

keith-packard commented Feb 3, 2023

keith-packard commented Feb 3, 2023

nashif commented Feb 7, 2023

keith-packard commented Feb 7, 2023

nashif commented Feb 7, 2023

nashif commented Feb 7, 2023 • edited Loading

nashif commented Feb 7, 2023 • edited Loading

keith-packard commented Feb 7, 2023 • edited Loading

keith-packard commented Feb 7, 2023

laurenmurphyx64 commented Feb 7, 2023

nashif commented Feb 7, 2023

nashif commented Feb 7, 2023

keith-packard commented Feb 7, 2023

stephanosio commented Feb 8, 2023

keith-packard commented Feb 8, 2023 • edited Loading

laurenmurphyx64 commented Feb 1, 2023 •

edited by nashif

Loading

keith-packard commented Feb 2, 2023 •

edited

Loading

laurenmurphyx64 commented Feb 2, 2023 •

edited

Loading

keith-packard commented Feb 2, 2023 •

edited

Loading

nashif commented Feb 2, 2023 •

edited

Loading

keith-packard commented Feb 3, 2023 •

edited

Loading

laurenmurphyx64 commented Feb 3, 2023 •

edited

Loading

keith-packard commented Feb 3, 2023 •

edited

Loading

keith-packard commented Feb 3, 2023 •

edited

Loading

nashif commented Feb 7, 2023 •

edited

Loading

nashif commented Feb 7, 2023 •

edited

Loading

keith-packard commented Feb 7, 2023 •

edited

Loading

keith-packard commented Feb 8, 2023 •

edited

Loading