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
tf.constant with tf.float16 results in incorrect outputs with Mac M1 chip #57010
Comments
Hi @slyforce, I executed your code with Tensorflow 2.9.2 on Mac.
|
Thanks for looking into this! |
@gadagashwini, I see the same issue as OP, MacBook Pro 2021 with M1 Pro (aarch64), macOS 12.5. TensorFlow is installed via the package The issue may very well be specific to arm64 (Apple Silicon). In that case you won't see it with an Intel CPU. |
What @maxhgerlach described reflects the current situation. (replying to remove the awaiting response tag) |
Thanks for reporting the issue. I was able to reproduce the behavior in Tensorflow 2.9.2 in MaCOS M1 chip. |
@slyforce, Thank you! |
Click to expand!
Issue Type
Bug
Source
binary
Tensorflow Version
2.9.2
Custom Code
No
OS Platform and Distribution
MacOS 12.3 arm64
Mobile device
No response
Python version
3.9.12
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
No response
GPU model and memory
No response
Current Behaviour?
When using the pip wheel for tensorflow_macos==2.9.2 (tensorflow_macos-2.9.2-cp39-cp39-macosx_11_0_arm64.whl), using tf.constant in graph mode, or equivalently in tf.function() decorated functions, with the meta-optimizer enabled leads to incorrect tensor contents. Disabling the meta-optimizer results in correct behavior. Using tf.float32 also leads to correct behavior.
Examination of the output generated with
TF_CPP_MIN_LOG_LEVEL=0 TF_CPP_MAX_VLOG_LEVEL=3
indeed shows that the binary content of the tensor is simply the value passed in, rather than the actual binary representation of float16.This issue #53260 also suffers from the same problem.
Also this seems to be a Mac M1 ARM64 wheel-specific problem. The behaviour is correct for Linux-based systems and wheels.
Standalone code to reproduce the issue
Relevant log output
The text was updated successfully, but these errors were encountered: