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

[keith-packard]

XCC doesn't support the -fno-printf-return-value compiler option

This should fix the issue seen with clang in #54345 but with the xcc compiler.

Signed-off-by: Keith Packard keithp@keithp.com

Fixes #54345

[laurenmurphyx64]

@keith-packard We're getting closer, got this now:

modules/picolibc/picolibc/include/stdlib.h:158: error: wrong number of arguments specified for ‘__deprecated__’ attribute

[keith-packard]

modules/picolibc/picolibc/include/stdlib.h:158: error: wrong number of arguments specified for ‘__deprecated__’ attribute

Ok, sounds like we may want to get picolibc running with xcc sometime later then; the GCC version of XCC seems to be quite different than what picolibc gets regular testing with, so my confidence in it generating working code is not as high. Some level of broader test coverage would be really helpful here; I'm open to suggestions on how to make that work.

Picolibc has an internal test suite designed to run under emulation on 'bare metal' systems which is how the CI system currently works, testing on x86, arm, risc-v, and power that way.

[keith-packard]

From what I can determine, the GCC based xt-xcc compiler uses a version of gcc before 4.5.0 as that version includes support for the deprecated("this is a message") form. We can try adding a version check in the one place which uses the deprecated attribute with a message.

picolibc/picolibc#423 has the proposed change; I've verified that it doesn't break current GCC, but I don't have any GCC 4.4 or earlier compilers around to test with.

You can test this change by using PR #54394, which I've marked DNM at least until it passes picolibc CI and perhaps until after the current Zephyr release is done.

[laurenmurphyx64]

Ok, sounds like we may want to get picolibc running with xcc sometime later then; the GCC version of XCC seems to be quite different than what picolibc gets regular testing with, so my confidence in it generating working code is not as high.

@keith-packard Yeah, that seems like a fair assessment. It's a weird toolchain 😅 (FYI @nashif)

Btw, cherry-picked in your new PR and this was the output (I shortened some paths in this output text to make it easier to read):

[117/1037] Building C object modules/picolibc/CMakeFiles/c.dir/newlib/libc/iconv/ces/euc.c.obj
picolibc/newlib/libc/iconv/ces/euc.c:75: warning: missing initializer
picolibc/newlib/libc/iconv/ces/euc.c:75: warning: (near initialization for ‘euc_jp_cs_desc[3].prefix’)
picolibc/newlib/libc/iconv/ces/euc.c:87: warning: missing initializer
picolibc/newlib/libc/iconv/ces/euc.c:87: warning: (near initialization for ‘euc_tw_cs_desc[3].prefix’)
picolibc/newlib/libc/iconv/ces/euc.c:97: warning: missing initializer
picolibc/newlib/libc/iconv/ces/euc.c:97: warning: (near initialization for ‘euc_kr_cs_desc[1].prefix’)
[195/1037] Building C object modules/picolibc/CMakeFiles/c.dir/newlib/libc/posix/regcomp.c.obj
In file included from picolibc/newlib/libc/posix/regcomp.c:52:
picolibc/newlib/libc/posix/cclass.h:58: warning: missing initializer
picolibc/newlib/libc/posix/cclass.h:58: warning: (near initialization for ‘cclasses[12].fidx’)
[267/1037] Building C object modules/picolibc/CMakeFiles/c.dir/newlib/libc/tinystdio/vfscanf.c.obj
In file included from picolibc/newlib/libc/tinystdio/conv_flt.c:35,
                 from picolibc/newlib/libc/tinystdio/vfscanf.c:246:
picolibc/newlib/libc/tinystdio/../../libm/common/math_config.h: In function ‘issignaling_inline’:
picolibc/newlib/libc/tinystdio/../../libm/common/math_config.h:272: warning: integer constant is too large for ‘long’ type
picolibc/newlib/libc/tinystdio/../../libm/common/math_config.h:272: warning: integer constant is too large for ‘long’ type
picolibc/newlib/libc/tinystdio/../../libm/common/math_config.h:273: warning: integer constant is too large for ‘long’ type
[280/1037] Building C object modules/picolibc/CMakeFiles/c.dir/newlib/libc/stdlib/reallocarray.c.obj
picolibc/newlib/libc/stdlib/reallocarray.c: In function ‘reallocarray’:
picolibc/newlib/libc/stdlib/reallocarray.c:30: warning: implicit declaration of function ‘__builtin_mul_overflow’
[292/1037] Building C object modules/picolibc/CMakeFiles/c.dir/newlib/libc/stdlib/wcstoll.c.obj
FAILED: modules/picolibc/CMakeFiles/c.dir/newlib/libc/stdlib/wcstoll.c.obj 
ccache xtensa/XtDevTools/install/tools/RG-2017.8-linux/XtensaTools/bin/xt-xcc  -Ipicolibc/newlib/libm/common -isystem zephyr/build/modules/picolibc/picolibc/include --include zephyrproject/zephyr/build/modules/picolibc/picolibc/include/picolibc.h -nostdlib -D_LIBC -fno-strict-aliasing -Os -imacros zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h -fno-common -g -fms-extensions -imacroszephyrproject/zephyr/include/zephyr/toolchain/xcc_missing_defs.h -imacros zephyrproject/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -fgnu89-inline -Werror=implicit-int -ffunction-sections -fdata-sections -mlongcalls -Wextra -Werror=implicit-function-declaration -Wold-style-definition -MD -MT modules/picolibc/CMakeFiles/c.dir/newlib/libc/stdlib/wcstoll.c.obj -MF modules/picolibc/CMakeFiles/c.dir/newlib/libc/stdlib/wcstoll.c.obj.d -o modules/picolibc/CMakeFiles/c.dir/newlib/libc/stdlib/wcstoll.c.obj -c picolibc/newlib/libc/stdlib/wcstoll.c
picolibc/newlib/libc/stdlib/wcstoll.c: In function ‘wcstoll_l’:
picolibc/newlib/libc/stdlib/wcstoll.c:180: error: ‘LLONG_MIN’ undeclared (first use in this function)
picolibc/newlib/libc/stdlib/wcstoll.c:180: error: (Each undeclared identifier is reported only once
picolibc/newlib/libc/stdlib/wcstoll.c:180: error: for each function it appears in.)
picolibc/newlib/libc/stdlib/wcstoll.c:180: error: ‘LLONG_MAX’ undeclared (first use in this function)
[301/1037] Building C object modules/picolibc/CMakeFiles/c.dir/newlib/libc/stdlib/wcstoumax.c.obj

[keith-packard]

@keith-packard Yeah, that seems like a fair assessment. It's a weird toolchain (FYI @nashif)

Ok, sounds like a reasonable solution is to just skip xcc for now. Note that if picolibc becomes the default C library, then xcc support would need to be supported, so we're not eliminating any work in the long term, just delaying it.

Btw, cherry-picked in your new PR and this was the output (I shortened some paths in this output text to make it easier to read):

None of these are too surprising, nor are they going to be hard to fix, but we'll need to test those fixes, and Zephyr itself doesn't provide adequate C library test coverage to do that. Before promising support for this toolchain, I'd like see a plan for executing at least the picolibc test suite.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.