__INT16_C, __UINT16_C, __INT8_C and __UINT8_C are not defined in
zephyr_stdint.h and have to be defined in llvm.h when
CONFIG_MINIMAL_LIBC is enabled.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
When CONFIG_MINIMAL_LIBC is enabled, __INTMAX_C and __UINTMAX_C
depend on int_c. Move the build guard to ensure that it is defined
when CONFIG_MINIMAL_LIBC is enabled.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Currently __INT64_C() doesn't add any suffix to provided constant which
causes the constant to have 'int' type. On the other side, __UINT64_C()
adds ULL suffix which makes the constant 'unsigned long long'.
Of course, __INT64_C() is wrong here because 'int' type, in most cases,
has 32 bit width.
According to the C standard, these macros are for minimum-width integer
constants. For example, it means that using INT16_C() macro will give
you constant with type the same as 'int_least16_t' type.
Clang doesn't provide defines like __INT_LEAST16_C_SUFFIX__, which makes
implementation difficult, because we need to determine appropriate type
first.
Signed-off-by: Patryk Duda <patrykd@google.com>
Using '#ifndef' before defining a macro is a good way to provide default
version of the macro if not defined elsewhere. But it has some
disadvantages:
- It hides information about the users of these macros. It's hard to
determine when this implementation is used.
- Correctness depends on file including order.
It looks like these macros are used only by minimal libc and only if
ENFORCE_ZEPHYR_STDINT is not selected. We expect other libc to provide
their own implementation.
Signed-off-by: Patryk Duda <patrykd@google.com>
Zephyr minimal libc implements integer constant macros using internal
headers provided by GCC, for example INT64_C(x) is just a __INT64_C(x)
which is implemented by the GCC.
Clang compiler doesn't provide these definitions, so we define them
(__INT64_C() and INT64_C()) in zephyr/toolchain/llvm.h, but it looks
like INT64_C() definition doesn't come from llvm.h, but from stdlib.h
despite of checking if __GNUC__ is defined.
This is because Clang sometimes pretends to be GNU compiler:
$ x86_64-pc-linux-gnu-clang -dM -E - < /dev/null | grep "GNU"
#define __GNUC_MINOR__ 2
#define __GNUC_PATCHLEVEL__ 1
#define __GNUC_STDC_INLINE__ 1
#define __GNUC__ 4
Let's keep the integer constant macros in stdlib.h and their
actual implementation in llvm.h. Also define these macros if __clang__
is defined, just in case.
Signed-off-by: Patryk Duda <patrykd@google.com>
Toolchain utilities need to be used through the <zephyr/toolchain.h>
parent header, where the right header is chosen.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
llvm based toolchains need the same fix as exists for xcc that was
introduced with commit:
commit 5ef8db8ac9
Author: Daniel Leung <daniel.leung@intel.com>
Date: Wed Feb 3 14:23:51 2021 -0800
xcc: define __INT*_C() and __UINT*_C()
Since llvm based toolchains don't define these macros either.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
GCC_VERSION is defined in a few modules, and those headers are often
included first, so replace the one used in zephyr with
TOOLCHAIN_GCC_VERSION. Do the same with CLANG_VERSION, replacing it with
TOOLCHAIN_CLANG_VERSION.
BUILD_ASSERT is also defined in include/toolchain/common.h, which might
get included before gcc.h. We want to use the gcc-specific one instead
of the general one.
Signed-off-by: Keith Packard <keithp@keithp.com>
In order to bring consistency in-tree, migrate all includes within
include directory to the new prefix <zephyr/...>. Note that the
conversion has been scripted, refer to zephyrproject-rtos#45388 for more
details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Move include paths and add new target_include_directories to support
backwards compatibility:
* /include -> /include/zephyr
example: <irq.h> -> <zephyr/irq.h>
Issue #41543
Signed-off-by: Yuval Peress <peress@google.com>
