search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.53k stars 6.45k forks source link

RFC: C11 (or C17) requirement #30105

Open carlescufi opened 3 years ago

carlescufi commented 3 years ago

With the C language evolving, there are a few features in ISO/IEC 9899:2011 (aka C11) that would be useful to Zephyr developers. Given that compiler support for it seems to be already widespread, I'd like to start the conversation to discuss whether switching to it as a requirement to build Zephyr is something we would like to consider. We could instead require C17, given that it is functionally equivalent to C11 but with some issues addressed.

Please use this issue to describe both features from C11 that you'd like to use and objections or showstoppers that you can foresee if we moved forward with the transition.

nordic-krch commented 3 years ago

It seems that logger would benefit greatly from _Generic feature added in C11. It allows to evaluate at compile time type of the parameter allowing to detect at compile time:

pabigot commented 3 years ago

Detecting multi-word arguments should already be handled in cbprintf, but log_strdup() is a problem. Though I'm not clear how _Generic could help with a varargs API like logging.

Browsing the C11 additions:

A consideration is that MISRA is not yet past C99.

carlescufi commented 3 years ago

@tejlmand could you comment on the full list of toolchains to check support for? My assumption here is that the list is currently restricted to:

tejlmand commented 3 years ago

My assumption here is that the list is currently restricted to:

Looks precise enough to me. Unsure how this would impact custom toolchains, @daor-oti comments ?

For the versions, I think: gcc

clang

pabigot commented 3 years ago

The current ESP32 (xtensa) toolchain is:

xtensa-esp32-elf-cc (crosstool-NG esp-2020r3) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
manoj153 commented 3 years ago

My assumption here is that the list is currently restricted to:

Looks precise enough to me. Unsure how this would impact custom toolchains, @daor-oti comments ?

For the versions, I think: gcc

  • 9.x.x, Zephyr SDK 0.12 is using 10, but gnuarmemb is GCC 9 based.

clang

  • 10.0.0 as that is what has recently been introduced.

issuing command :

./arm-zephyr-eabi-gcc -v

returns : 

gcc version 10.2.0 (crosstool-NG 1.24.0.212_d7da3a9)

Development environment:

  1. zephyr-sdk-0.12.0
  2. STM32H7xx

from reading from devdocs seems GCC v10 supports C17, I can write my app code successfully with C17?

daor-oti commented 3 years ago

@tejlmand Thanks for asking. Our toolchain uses clang 9.0.0 as frontend and as such it supports both C11 and C17. We actually set -std=c11 for clang today and have done for a long time. For our custom backend, is a little more difficult to determine whether there will be some corner C11/C17 unsupported areas, but I suspect there will be very few, if any. So, for our toolchain point of view, I see no immediate problem with Zephyr requiring either C11 or C17.

pabigot commented 3 years ago

A propósito, somebody should verify or update the recommended toolchain for Vega, which is currently GCC 7.1.1. @MaureenHelm

I'm unable to make it work with west with the following commands:

export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/usr/local/openisa/bin/riscv32-unknown-elf-

which does work with cmake/ninja directly.

evgeniy-paltsev commented 3 years ago

Latest ARC GNU toolchain is GCC 10.2.0 based (both toolchain from Zephyr SDK 0.12 and standalone prebuilt one) Latest ARC MWDT toolchain is LLVM 10.0.1 based.

pabigot commented 3 years ago

Here are version numbers that can be used to determine C standard versions at compile-time with code like:

#if ((__STDC__VERSION__ - 0) >= 201112L)
/* at least C11 */
#endif
Version __STDC__VERSION__
C90 not defined
C95 (C90 + AMD 1) 199409L
C99 199901L
C11 201112L
C17 201710L
C20 202000L
galak commented 3 years ago

@nashif can you add details on cadence compiler here.

nashif commented 3 years ago

cadence compiler does not support C11

dleach02 commented 3 years ago

cadence compiler does not support C11

What is the version it does support?

evgeniy-paltsev commented 3 years ago

As for ARC MWDT - this is the list of standards supported:

-std={c89|gnu89|c90|c99|gnu99|c11|gnu11|c++98|gnu++98|c++11|gnu++11|c++14|gnu++14|c++17|gnu++17}
dleach02 commented 3 years ago

Just a note, MISRA C:2012 - Amendment 2: Updates for ISO/IEC 9899:2011 core functionality, ISBN 978-906400-25-5 (PDF), February 2020.

This document amends MISRA C:2012 as required to introduce support for ISO/IEC 9899:2011. Subsequent amendments will be used to introduce specific guidance for the features introduced by ISO/IEC 9899:2011

galak commented 3 years ago

We should look to add something in the docs about the fact that we support C99 and why we don't support something newer.

yashi commented 3 years ago

Just to add a yet another compiler, TI's CGT for ARM (#10182) seems to support C11 but not C17 with v20.2.0.LTS. https://www.ti.com/lit/pdf/SPNU151V

cfriedt commented 2 years ago

C11 stdatomic.h would be pretty awesome to pull in

cfriedt commented 2 years ago

Whoa.. I just used C11 generics to implement a certain ISO C library function. Same code size, but 166x performance improvement.

teburd commented 2 years ago

C11 could potentially allow for a static call path for drivers using _Generic over a device class API

cfriedt commented 2 years ago

cadence compiler does not support C11

What is the version it does support?

That's a good question - is anyone able to grok the output of xt-xcc --help and xt-clang --help and paste the relevant output here?

If xcc is the only toolchain that's holding up switching to C11, it would be good to know.

SebastianBoe commented 2 years ago

C11 gives us memset_s.

Useful for securely clearing RAM.

stephanosio commented 2 years ago

C11 gives us memset_s.

Unfortunately, memset_s is part of the Annex K, which is an optional feature (hated by many OSS developers, especially the GNU/Linux people ...).

In fact, none of the standard C libraries we support currently implement memset_s (or any other Annex K functions).

aborisovich commented 2 years ago

cadence compiler does not support C11

I'm quite sure this is not true. Cadence is obsoleting xt-xcc and moving to xt-clang. As far as I know there is even C++17 support with xt-clang RI-2021.7. I doubt there would be no C17 support. I'll check in a moment.

aborisovich commented 2 years ago

Can't really copy content of the Xtensa guides here as they are copyright protected... From what they say for 2021.7 toolchain docs is basically:

Toolchain: RI-2021.7-linux Short test - C++17: I've made following main.cpp: image and executed command: ./xt-clang -std=c++17 main.cpp -o test Got linking errors: image so it looks like C++17 is supported.

Short test - C17: Created following main.c: image and executed command: ./xt-clang -std=c17 main.c -o test . Successfully created executable.

So I think we can confirm C17 and C++17 support for this toolchain. We should just make an efford (probably a big one) to move from xt-xcc to xt-clang and also upgrade the toolchain. Maybe somebody should check state for 2020.5 which we currently use I believe. I don't really want to push my luck with copyright laws ;-)

zephyrbot commented 7 months ago

Hi @abrodkin, @galak, @tejlmand, @evgeniy-paltsev, @carlescufi, @daor-oti, @MaureenHelm, @nashif,

This issue, marked as an RFC, was opened a while ago and did not get any traction. Please confirm the issue is correctly assigned and re-assign it otherwise.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

Thanks!