[pull] master from tensorflow:master - #8803
Merged
Merged
Conversation
NumPy flattens every input before concatenating when axis is None, but the value was passed straight to array_ops.concat and failed with a cryptic conversion error. Flatten the inputs and concatenate along axis 0 instead.
Reshaping a 1-D array to [-1] is a no-op, so skip the extra op dispatch for inputs that are already flat.
The `TF_SYSTEMLIBS` for those 2 broke: - The LICENSE filegroup should not have an extension. - Duplicate `xla` in project reference - Missing config-setting referenced by other targets.
Allow them to be recognized as build extensions.
Refactor accelerator detection and JSON summary generation in tf_env_collect.sh. Improve temporary file handling and streamline pip list checks.
In StagingMap::popitem(), the local key tensor was passed to copy_or_move_tensors() before being assigned the actual key from the map iterator. When an out-of-range index is supplied, the downstream check_index() helper formats its InvalidArgument message via key.scalar<int64_t>()() on the still-empty (0-element) key tensor. Tensor::scalar() then invokes CheckIsAlignedAndSingleElement() which CHECK_EQ(1, NumElements()) fails (1 vs. 0) and aborts the process with SIGABRT (exit 134), turning a recoverable input error into a fatal CHECK. Move the assignment of *key = it->first above the call to copy_or_move_tensors() so that check_index() always sees a fully constructed scalar key when formatting its error message. The existing bounds-check and InvalidArgument semantics are unchanged. Fixes #112757
Adds testMapUnstageNoKeyOutOfRangeIndex and testOrderedMapUnstageNoKeyOutOfRangeIndex to MapStageTest. Each test stages one float32 value at index 0 with int64 key 1, then calls the corresponding *MapUnstageNoKey op with index 1 and asserts that the call raises tf.errors.InvalidArgumentError matching "out of bounds" instead of aborting with a fatal CHECK in Tensor::CheckIsAlignedAndSingleElement. The ordered variant covers OrderedMapUnstageNoKeyOp<true>, which shares StagingMap::popitem() with the unordered MapUnstageNoKeyOp<false> through the StagingMap<bool Ordered> template, so both variants exhibit the same out-of-range-index bug and need explicit coverage. Without the popitem() reorder fix in the previous commit, both tests crash the Python process with SIGABRT (exit 134) and the tensor.cc:904 "Check failed: 1 == NumElements() (1 vs. 0)" signature. With the fix, copy_or_move_tensors() sees a 1-element scalar key and check_index() returns the expected InvalidArgumentError.
…ang. Change-Id: Idf4224600b1fcdc29bd708f9b89d3ac4ab14b72d
cudnn doesn't accept f64 data types, so we should reject it in IsCudnnSupportedFusion. This was discovered in the test from DoNotExecuteGemmFusionWithCuDnnWhenNotSupported when enabling gemm fusion V2. I believe this test was never testing what it was intending to. Previously in V1, gemm fusion didn't support f64, so it created a fusion around the dot and another around the negate. Since cudnn rejected the _loop_ fusion around the negate, it returned "No supported configs", but this was unrelated to the dot/f64 fusion it was trying to test. I have updated the HLO to be a premade fusion to ensure it's testing the correct fusion. Then I updated IsCudnnSupportedFusion to successfully reject it (and added relevant test there). PiperOrigin-RevId: 975071652
- Bump rules_cc to 0.2.20 in MODULE.bazel and workspace3.bzl. - Bump bazel_skylib to 1.9.0 in workspace3.bzl to support the 'scope' attribute on bool_flag used by rules_cc 0.2.20. - Remove rules_cc_protobuf.patch from rules_cc in workspace3.bzl since rules_cc 0.2.20 no longer contains cc_proto_library in cc/defs.bzl. - Call compatibility_proxy_repo() early in WORKSPACE to define @cc_compatibility_proxy in WORKSPACE mode. - Revert compiler flag workaround from third_party/llvm/build.patch now that rules_cc 0.2.20 natively provides @rules_cc//cc/compiler:compiler. PiperOrigin-RevId: 975088002
…metic
`ParseAttributes` in dilation_ops.cc checked only that `strides` and `rates`
have 4 entries and that entries 0 and 3 equal 1. It never checked that the
spatial entries are positive, so zero and negative values reached the kernel.
`ParseSizes` then computes, in `int`:
const int filter_rows_eff = filter_rows + (filter_rows - 1) * (rate_rows - 1);
A negative rate makes the effective filter size negative directly, and a large
negative one overflows. `GetWindowedOutputSizeVerbose` rejects `stride <= 0` and
a negative output size, but not a negative filter size: with dilation_rate == 1
the effective filter size is passed straight through, so
`output_size = (input - negative + stride) / stride` is larger than the input
and positive, and the guard passes.
Observed on 2.22.0-dev (input 2x4x4x2, filter 2x2x2, strides 1):
rates=[1,0,0,1] -> accepted, output 2x4x4x2
rates=[1,-1,-1,1] -> accepted, output 2x5x5x2
rates=[1,-100,-100,1]-> accepted, output 2x104x104x2 (larger than the input)
rates=[1,INT32_MIN,INT32_MIN,1] -> aborts the process:
F tensor_shape.cc:204] Check failed: InitDims(dim_sizes) is OK
(INVALID_ARGUMENT: Encountered overflow when multiplying ...)
@ tensorflow::TensorShapeBase<>::TensorShapeBase()
@ tensorflow::DilationOp<>::Compute()
Because the CHECK is inside TensorShape's constructor, callers cannot catch it.
This mirrors what 210e294 ("Fix integer overflow DoS in ExtractImagePatches
and ExtractVolumePatches") did for the sibling ops: that change routed attribute
parsing through `ParseAttributeVec4`, which enforces `(*attr)[1] >= 1 &&
(*attr)[2] >= 1`, and widened the shape arithmetic to int64_t. Dilation2D was
not covered. With the same inputs above, ExtractImagePatches already returns
OutOfRangeError for every non-positive rate.
`ParseAttributes` is shared by Dilation2D, Dilation2DBackpropInput and
Dilation2DBackpropFilter, so all three are covered.
Matches the error type used by the other attribute validation in this file.
This adds bounds checking to cache resizes and updates the cache truncation warning.
PiperOrigin-RevId: 975128947
PiperOrigin-RevId: 975130847
…ty-key-check PiperOrigin-RevId: 975152958
…none PiperOrigin-RevId: 975155339
PiperOrigin-RevId: 975155569
PiperOrigin-RevId: 975174940
Expose the `llvm_linux_aarch64` repository from `@rules_ml_toolchain` in `MODULE.bazel`. XLA registers Linux AArch64 toolchains: - `@rules_ml_toolchain//cc:linux_aarch64_linux_aarch64` - `@rules_ml_toolchain//cc:linux_aarch64_linux_aarch64_cuda` These toolchains depend on `@llvm_linux_aarch64`. Under Bzlmod, repositories generated by module extensions must be explicitly imported via `use_repo`. Otherwise, the toolchain resolution will fail. PiperOrigin-RevId: 975182846
PiperOrigin-RevId: 975183363
…es-rates PiperOrigin-RevId: 975194865
PiperOrigin-RevId: 975212876
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
14 participants
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )