-
Notifications
You must be signed in to change notification settings - Fork 6.1k
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
zassert_equal fails for float comparisons on native_posix #61345
Comments
Given the GCC discussion linked above, it seems clear that this wouldn't be considered a bug and so is unlikely to get changed. If possible, switching to |
When building the 32bit native board targets variants for x86(-64) hosts, gcc will promote float literals to double (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 ) This can result in unexpected comparison differences. This is due to the compiler using the 8087 float mode by default. Instead let's tell the compiler to use the SSE float path, which is the default for 64 bit x86-64 builds. The assumption that any x86 host used for development will have SSE support should be safe enough. For more background see zephyrproject-rtos#61345 Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
@keith-packard @martinjaeger Thanks for the very detailed analysis :) |
I agree -- it makes the native_posix port work more like other environments and improves performance. Probably need the TCS to read on that? |
@keith-packard You think any of this will be controversial? |
It changes the base platform requirements for the |
When building the 32bit native board targets variants for x86(-64) hosts, gcc will promote float literals to double (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 ) This can result in unexpected comparison differences. This is due to the compiler using the 8087 float mode by default. Instead let's tell the compiler to use the SSE float path, which is the default for 64 bit x86-64 builds. The assumption that any x86 host used for development will have SSE support should be safe enough. For more background see zephyrproject-rtos#61345 Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
@keith-packard Given that the native boards are development/test targets, I think that is ok. If some developer finds it a problem, they can file an issue and is so we add a kconfig choice to disable this switch. |
When building the 32bit native board targets variants for x86(-64) hosts, gcc will promote float literals to double (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 ) This can result in unexpected comparison differences. This is due to the compiler using the 8087 float mode by default. Instead let's tell the compiler to use the SSE float path, which is the default for 64 bit x86-64 builds. The assumption that any x86 host used for development will have SSE support should be safe enough. For more background see #61345 Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
When building the 32bit native board targets variants for x86(-64) hosts, gcc will promote float literals to double (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 ) This can result in unexpected comparison differences. This is due to the compiler using the 8087 float mode by default. Instead let's tell the compiler to use the SSE float path, which is the default for 64 bit x86-64 builds. The assumption that any x86 host used for development will have SSE support should be safe enough. For more background see zephyrproject-rtos#61345 Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no> (cherry picked from commit d4e48d5)
When building the 32bit native board targets variants for x86(-64) hosts, gcc will promote float literals to double (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 ) This can result in unexpected comparison differences. This is due to the compiler using the 8087 float mode by default. Instead let's tell the compiler to use the SSE float path, which is the default for 64 bit x86-64 builds. The assumption that any x86 host used for development will have SSE support should be safe enough. For more background see zephyrproject-rtos#61345 Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
When building the 32bit native board targets variants for x86(-64) hosts, gcc will promote float literals to double (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 ) This can result in unexpected comparison differences. This is due to the compiler using the 8087 float mode by default. Instead let's tell the compiler to use the SSE float path, which is the default for 64 bit x86-64 builds. The assumption that any x86 host used for development will have SSE support should be safe enough. For more background see zephyrproject-rtos/zephyr#61345 (cherry picked from commit d4e48d5) Original-Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no> GitOrigin-RevId: d4e48d5 Change-Id: I7a20c74f4bbcabbf98d56be670417aa8b882b63c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/zephyr/+/4780807 Commit-Queue: Al Semjonovs <asemjonovs@google.com> Reviewed-by: Al Semjonovs <asemjonovs@google.com> Tested-by: Al Semjonovs <asemjonovs@google.com> Tested-by: ChromeOS Prod (Robot) <chromeos-ci-prod@chromeos-bot.iam.gserviceaccount.com>
When building the 32bit native board targets variants for x86(-64) hosts, gcc will promote float literals to double (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 ) This can result in unexpected comparison differences. This is due to the compiler using the 8087 float mode by default. Instead let's tell the compiler to use the SSE float path, which is the default for 64 bit x86-64 builds. The assumption that any x86 host used for development will have SSE support should be safe enough. For more background see zephyrproject-rtos#61345 Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
When building the 32bit native board targets variants for x86(-64) hosts, gcc will promote float literals to double (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 ) This can result in unexpected comparison differences. This is due to the compiler using the 8087 float mode by default. Instead let's tell the compiler to use the SSE float path, which is the default for 64 bit x86-64 builds. The assumption that any x86 host used for development will have SSE support should be safe enough. For more background see zephyrproject-rtos#61345 Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
When building the 32bit native board targets variants for x86(-64) hosts, gcc will promote float literals to double (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 ) This can result in unexpected comparison differences. This is due to the compiler using the 8087 float mode by default. Instead let's tell the compiler to use the SSE float path, which is the default for 64 bit x86-64 builds. The assumption that any x86 host used for development will have SSE support should be safe enough. For more background see #61345 Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no> (cherry picked from commit d4e48d5)
Describe the bug
Below code snippet fails if run on
native_posix
:To Reproduce
Steps to reproduce the behavior:
tests/ztest/base/src/main.c
west build -b native_posix tests/ztest/base -t run
Expected behavior
The variable and the floating constant should be equal.
Impact
Hard to reproduce and unexpected bugs (in unit tests or even somewhere else).
Logs and console output
GCC options:
Environment:
Additional context
After investigation by @keith-packard the old 8087 FPU seems to be the root cause of the issue. Compiler flags
-msse -mfpmath=sse
or-std=gnu11
fix the issue.We need to decide which compiler flags we should use for
native_posix
in Zephyr.Related Discord discussion:
https://discord.com/channels/720317445772017664/883404732423606303/1138773080198627408
Related GCC bug / discussion:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875
CC @aescolar @stephanosio @nashif
The text was updated successfully, but these errors were encountered: