build(bazel): always build with TF_LITE_STATIC_MEMORY #2945
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add TF_LITE_STATIC_MEMORY to the defines set globally for TFLM builds in Bazel. TFLM always builds with this set in Make, and it appears to have been an oversight that it wasn't set during Bazel builds. Not having it set in Bazel caused some unit tests to pass under Bazel that failed under Make. At the same time, add -fno-exceptions. This flag is also always set in Make builds. Without it, setting TF_LITE_STATIC_MEMORY breaks the build. TF_LITE_STATIC_MEMORY triggers TF_LITE_REMOVE_VIRTUAL_DELETE in t/l/m/compatibility.h, which makes operator delete private in certain classes. When exceptions are enabled, a placement new with those classes is allowed to throw an exception, and operator delete is implicitly called during the unwind. The build breaks because operator delete can't be called if it's private. Disabling exceptions eliminates the unwind code that calls operator delete implicitly, and thus the build succeeds. In any case, -fno-exceptions should have been used in Bazel builds, matching the flags used in Make and the no-exceptions design requirement of the TFLM project.
rkuester
added a commit
to rkuester/tflite-micro
that referenced
this pull request
Nov 28, 2024
Remove the test that incorrectly asserts the output tensor is initially all zeros. The tensor is allocated from a shared memory arena, and its initial state is not guaranteed to be zero. This test eventually failed due to variations in memory allocation during build and runtime; see the failed checks in tensorflow#2945. BUG=tensorflow#2636
mergify bot
pushed a commit
that referenced
this pull request
Dec 2, 2024
…2946) Remove the test that incorrectly asserts the output tensor is initially all zeros. The tensor is allocated from a shared memory arena, and its initial state is not guaranteed to be zero. This test eventually failed due to variations in memory allocation during build and runtime; see the failed checks in #2945. BUG=#2636
suleshahid
approved these changes
Dec 2, 2024
mergify bot
pushed a commit
that referenced
this pull request
Dec 5, 2024
Fixes unused import and a required dep for hexdump. Also adds docstring for .bzl file. These changes are needed for some internal checks. Additionally, temporarily reverts #2945, to help with internal fix. BUG=quick fix
mergify bot
pushed a commit
that referenced
this pull request
Dec 6, 2024
Re enabling static memory for bazel builds, see #2945. BUG=static mem for bazel
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add TF_LITE_STATIC_MEMORY to the defines set globally for TFLM builds in
Bazel. TFLM always builds with this set in Make, and it appears to have
been an oversight that it wasn't set during Bazel builds. Not having it
set in Bazel caused some unit tests to pass under Bazel that failed
under Make.
At the same time, add -fno-exceptions. This flag is also always set in
Make builds. Without it, setting TF_LITE_STATIC_MEMORY breaks the build.
TF_LITE_STATIC_MEMORY triggers TF_LITE_REMOVE_VIRTUAL_DELETE in
t/l/m/compatibility.h, which makes operator delete private in certain
classes. When exceptions are enabled, a placement new with those classes
is allowed to throw an exception, and operator delete is implicitly
called during the unwind. The build breaks because operator delete can't
be called if it's private. Disabling exceptions eliminates the unwind
code that calls operator delete implicitly, and thus the build succeeds.
In any case, -fno-exceptions should have been used in Bazel builds,
matching the flags used in Make and the no-exceptions design requirement
of the TFLM project.
BUG=#2636