Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tests/kernel/common fails to build on xtensa / ESP32 #8093

Closed
inakypg opened this issue Jun 1, 2018 · 1 comment
Closed

tests/kernel/common fails to build on xtensa / ESP32 #8093

inakypg opened this issue Jun 1, 2018 · 1 comment
Assignees
Labels
area: Xtensa Xtensa Architecture bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug

Comments

@inakypg
Copy link
Contributor

inakypg commented Jun 1, 2018

commit 43553da

Toolchain: ZEPHYR_GCC_VARIANT=espressif

...
[ 63%] Building C object zephyr/CMakeFiles/zephyr.dir/drivers/pinmux/pinmux_esp32.c.obj
[ 64%] Building C object zephyr/CMakeFiles/zephyr.dir/drivers/timer/sys_clock_init.c.obj
zephyr.git/tests/kernel/common/src/intmath.c:50:30: error: enumerator value for '__build_assert37' is not an integer constant
zephyr.git/tests/kernel/common/src/intmath.c:52:30: error: enumerator value for '__build_assert41' is not an integer constant
 ROLLOVER_CHECK(int, 2147483647, -2147483648);
                              ^
@inakypg inakypg added bug The issue is a bug, or the PR is fixing a bug area: Xtensa Xtensa Architecture labels Jun 1, 2018
@MaureenHelm MaureenHelm added the priority: medium Medium impact/importance bug label Jun 1, 2018
@andyross
Copy link
Contributor

andyross commented Jun 4, 2018

What's happening is that the we have a test where on GCC 4.x+, we use the C99 _Static_assert() feature instead of our own preprocessor hack. But on ESP32, something in the toolchain headers is redefining STDC to say that it's C90, not C99 (I checked: the compiler emits C99 by deafault, so we don't use the builtin.

And of course our own macro is bitrotten and broken and produces that error.

andyross pushed a commit to andyross/zephyr that referenced this issue Jun 4, 2018
The logic for using _Static_assert() was a little broken.  We were
using it when on GCC 4.6+ AND when __STDC_VERSION__ said we were on
C99 or better.  But it's not a C99 feature, it's a C11 feature.  And
if GCC provides it as an extension, that's unrelated to a particular
language version.  This should have been "GCC 4.6+ OR C11+".

This actually broke on the ESP-32 IDF toolchain, where (when using
-std=c99) the compiler was actually defining a C99 macro instead of
the C11 one, and choosing to use the wrong (and independently broken)
handling incorrectly.  Fixes zephyrproject-rtos#8093.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
nashif pushed a commit that referenced this issue Jun 4, 2018
The logic for using _Static_assert() was a little broken.  We were
using it when on GCC 4.6+ AND when __STDC_VERSION__ said we were on
C99 or better.  But it's not a C99 feature, it's a C11 feature.  And
if GCC provides it as an extension, that's unrelated to a particular
language version.  This should have been "GCC 4.6+ OR C11+".

This actually broke on the ESP-32 IDF toolchain, where (when using
-std=c99) the compiler was actually defining a C99 macro instead of
the C11 one, and choosing to use the wrong (and independently broken)
handling incorrectly.  Fixes #8093.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Xtensa Xtensa Architecture bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug
Projects
None yet
Development

No branches or pull requests

3 participants