zephyr: Zephyr does not define minimal C++ language standard requirement and does not track it

Describe the bug Zephyr defines C11 as minimal supported standard for C language in C language support - language standards. Similar documentation article: C++ language support does not have “language standard” section. Roadmap #31281 also does not say a word about minimal requirements. Thus, minimal C++ version supported is unknown. This is a serious problem since:

• C++ language standards have much more changes between releases than C language.
• Custom toolchains for embedded systems often concentrate on C language support (due to its popularity) leaving C++ language with old standard (like dreadful C++98).

Concrete problem encountered: SOF project uses Cadence Xtensa toolchain “xt-xcc” that is based on GNU 4.2.0 compiler for Intel Meteorlake audio firmware. Meteorlake board has some C++ code that uses Zephyr #include <zephyr/sys/util.h> that provides C/C++ interropt helpers at the time of writing. “xt-xcc” is obsolete for some time and latest support language is C++98 standard. Everything was working fine in our CI until PR #53405 , where author added constexpr keyword usage in commit deab09d7a6b0c51a52ffd8bd03f17e04cf39c25c . Author @cfriedt in that PR claims (selective quote):

There should be a announcement for this and the code that suddenly requires new C++

As mentioned above, this is all in line with Zephyr’s suggested ISO C and C++ standards (C11, C++11).

Proof of wrong: Fuction template definition __z_log2_impl from include/zephyr/sys/util.h in some conditions returns value A and in other conditions value B. According to C++ standard ISO/IEC 14882:2011 §7.1.5.3:

The definition of a constexpr function shall satisfy the following constraints:

• it shall not be virtual (10.3);
• its return type shall be a literal type;
• each of its parameter types shall be a literal type;
• its function-body shall be = delete, = default, or a compound-statement that contains only
  • null statements,
  • static_assert-declarations
  • typedef declarations and alias-declarations that do not define classes or enumerations,
  • using-declarations,
  • using-directives,
  • and exactly one return statement;
• every constructor call and implicit conversion used in initializing the return value (6.6.3, 8.5) shall be one of those allowed in a constant expression (5.19).

Also, cppreference.com - constexpr confirms this: Quote marked “(until C++14)”:

the function body must be either deleted or defaulted or contain only the following:

• null statements (plain semicolons)
• static_assert declarations
• typedef declarations and alias declarations that do not define classes or enumerations
• using declarations
• using directives
• if the function is not a constructor, exactly one return statement

To Reproduce Steps to reproduce the behavior:

1. Open my minimal reproduction project with Compiler Explorer: https://godbolt.org/z/78sWY65v4
2. Play around with compiler version and C++ standard. Note: compiler x86-64 gcc 12.2 compiles minimal example using C++11 without a warning! Change compiler to: x86-64 gcc 11.3 to receive an error (related to multiple return statements in constexpr function):

header.h:17:1: error: body of ‘constexpr’ function ‘constexpr int __z_log2_impl(T) [with T = int]’ not a return-statement 17 | } | ^

1. Change CMake line: set_property(TARGET output.s PROPERTY CXX_STANDARD 11) to set_property(TARGET output.s PROPERTY CXX_STANDARD 14) and watch how everything compiles successfully.

Expected behavior

1. Zephyr defines minimal C++ language standard in the official documentation. Right now it is C++14 if we do not roll back PR #53405 (probably - remaining C++ code needs verification too!)
2. Developers know, and check the C++ standard of the code they wright! Please note, that modern compilers GCC, Clang, MSVC tend to provide “backward compatibility” to old C++ standards what results in non-conforming code being compiled without an issue! If the compiler supports C++17 or C++20 it is possible that it will compile the code marked -std=c++11 that should not compile with that standard due to compiler extensions they provide! We need to watch the conformance carefully, maybe some static analysis tools?

Impact SOF project has to urgently upgrade toolchain to new Cadence Xtensa “xt-clang” based on clang, that allows to use up to C++17 standard. If we do not do this, we are unable upgrade Zephyr revisions since our code will not build! Luckily, we had been preparing for toolchain change in https://github.com/thesofproject/sof/pull/7027 for some time and have only 2 .cpp source files at the time of writing.

Logs and console output Compiling with xt-xcc: xt-xcc.log Compiling with xt-clang -std=c++11: xt-clang C++11.log

Environment (please complete the following information):

• OS: Windows, Linux

Additional context N/A