🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/169126

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki

Note: Links to docs will display an error until the docs builds have been completed.

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• Run pull request jobs on OSDC runners in shadow mode

❌ You can merge normally! (2 Unrelated Failures), 1 Unclassified Failure

As of commit 35c7ad0 with merge base da74fec ():

This comment was automatically generated by Dr. CI and updates every 15 minutes.

The committers listed above are authorized under a signed CLA.

• ✅ login: dumko2001 / name: dumko2001 (80aef0d, a62caed, 2128cf7, 9142b21, cc60667, db0c8da, e5579b5)

@pytorchbot label "release notes: bug fix (inductor)"

Didn't find following labels among repository labels: release notes: bug fix (inductor)

@pytorchbot label "release notes: inductor"

Could you add a test for what this is fixing?

Hey I have pushed a commit

@jansel I have added a regression test test_functional_batch_norm_defaults in test/inductor/test_efficient_conv_bn_eval.py that specifically targets the 3-argument F.batch_norm case.

Looks like lints are failing

@jansel fixed lint issues, could u run checks again

@pytorchbot rebase

@pytorchbot started a rebase job onto refs/remotes/origin/viable/strict. Check the current status here

Successfully rebased fix/issue-169011 onto refs/remotes/origin/viable/strict, please pull locally before adding more changes (for example, via git checkout fix/issue-169011 && git pull --rebase)

Workflows were awaiting approval. CI has now been triggered for the ciflow labels on this PR.

@claude explain those CI failures, are they related?

Claude finished @jansel's task in 1m 56s —— View job

Investigating CI Failures

• Check current CI status
• Read the changed files to understand the PR scope
• Analyze failing tests for relevance to this PR
• Provide diagnosis

Diagnosis

Neither of the CI failures is related to this PR. This PR only modifies torch/_inductor/fx_passes/efficient_conv_bn_eval.py and test/inductor/test_efficient_conv_bn_eval.py. Here's the breakdown:

1. trunk / linux-jammy-rocm-py3.10-mi355 / test (distributed, 1, 4) — test_isend timeout

This is a distributed test (test/distributed/test_distributed_spawn.py::TestDistBackendWithSpawn::test_isend) that timed out after 300 seconds on the ROCm/MI355 gloo backend. The error:

RuntimeError: Process 0 terminated or timed out after 310.07577753067017 seconds

The test was retried and timed out again identically. This is a gloo isend hang on the ROCm platform — completely unrelated to the inductor conv-bn fusion pass. No convolutions, batch normalization, or inductor code paths are involved.

2. trunk / linux-jammy-cuda13.0-py3.10-gcc11 / test (default, 5, 5) — test_mkldnn_rnn_backward_dtype (FLAKY)

The bot already identified this as flaky with a similar failure on trunk (link). This is a meta kernel registration test for MKLDNN RNN, also completely unrelated to the inductor conv-bn eval pass.

Summary: Both failures are unrelated infrastructure/flaky issues affecting distributed (ROCm gloo test_isend timeout) and MKLDNN (meta kernel test). The PR's own tests are not shown as failing. Safe to merge.

@pytorchbot rebase

@pytorchbot started a rebase job onto refs/remotes/origin/viable/strict. Check the current status here

Successfully rebased fix/issue-169011 onto refs/remotes/origin/viable/strict, please pull locally before adding more changes (for example, via git checkout fix/issue-169011 && git pull --rebase)

@claude explain those CI failures, are they related?

Claude finished @jansel's task in 2m 7s —— View job

Investigating CI Failures

• Check current CI status
• Analyze failing tests for relevance to this PR
• Provide diagnosis

Diagnosis

Neither of the 2 flagged CI issues is related to this PR. This PR only modifies torch/_inductor/fx_passes/efficient_conv_bn_eval.py and test/inductor/test_efficient_conv_bn_eval.py. Here's the breakdown:

1. pull / linux-docs / build-docs-python-false — "Process completed with exit code 1"

This is a docs build job. Reviewing the full log shows that Sphinx successfully built and committed all Python docs (5405 files changed, committed as "Generate Python docs from 78c5c55..."). The exit code 1 appears to come from a post-build infrastructure step, not from any documentation error related to this PR's changes. No convolution or batch norm documentation is involved.

2. pull / linux-jammy-py3.14t-clang18 / test (dynamo_wrapped, 1, 3) — "ValueError: too many values to unpack (expected 2, got 3)"

This is a free-threaded Python 3.14t dynamo_wrapped test job. The bot explicitly notes: "this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing." Reviewing the actual test log shows the test_nn.py tests are running and passing normally. The ValueError is from a different subsystem — the dynamo_wrapped testing infrastructure on the experimental py3.14t build. No inductor conv-bn eval code is exercised in these test_nn.py tests.

Summary: Both issues are unrelated infrastructure/platform problems. The efficient conv-bn eval tests themselves are not shown as failing. Safe to merge.

@pytorchbot rebase

@pytorchbot started a rebase job onto refs/remotes/origin/viable/strict. Check the current status here

Successfully rebased fix/issue-169011 onto refs/remotes/origin/viable/strict, please pull locally before adding more changes (for example, via git checkout fix/issue-169011 && git pull --rebase)

@claude explain those CI failures, are they related?

Claude finished @jansel's task in 2m 18s —— View job

Investigating CI Failures

• Check current CI status
• Analyze failing tests for relevance to this PR
• Provide diagnosis

Diagnosis

Neither of the 2 CI failures is related to this PR. This PR only modifies torch/_inductor/fx_passes/efficient_conv_bn_eval.py and test/inductor/test_efficient_conv_bn_eval.py. Here's the breakdown:

1. trunk / linux-jammy-rocm-py3.10-mi355 / test (distributed, 2, 4) — test_broadcast_basics

This is a distributed gloo test (test/distributed/test_c10d_gloo.py::ProcessGroupGlooTest::test_broadcast_basics) on the ROCm/MI355 platform. The log shows all other gloo tests (allgather, allreduce, alltoall, broadcast_stress, etc.) passing normally in the same job. The test_broadcast_basics failure is a gloo process group test — completely unrelated to the inductor conv-bn fusion pass. No convolutions, batch normalization, or inductor code paths are involved.

2. pull / linux-jammy-py3.10-clang18 / test (onnx, 1, 1) — test_rotary_embedding_opcheck

This is an ONNX operator test that fails with a stride mismatch in onnx.RotaryEmbedding.opset23:

MetadataMismatchError: Stride mismatch! Strides are (96, 8, 24, 1) and (96, 32, 8, 1) (mismatched at 1)!

The test verifies that the ONNX RotaryEmbedding custom op's FakeTensor implementation matches its concrete implementation's tensor metadata. This is an ONNX-specific issue with rotary embedding stride computation — completely unrelated to the inductor conv-bn eval pass. The bot notes this job "did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing."

Summary: Both failures are unrelated to this PR. The first is a ROCm distributed gloo flake, and the second is a pre-existing ONNX rotary embedding opcheck bug. The PR's own efficient conv-bn eval tests are not shown as failing. Safe to merge.

@pytorchbot rebase

@pytorchbot started a rebase job onto refs/remotes/origin/viable/strict. Check the current status here

Successfully rebased fix/issue-169011 onto refs/remotes/origin/viable/strict, please pull locally before adding more changes (for example, via git checkout fix/issue-169011 && git pull --rebase)

@claude are those failures related?

Claude finished @jansel's task in 1m 52s —— View job

Investigating CI Failures

• Check current CI status
• Analyze failing tests for relevance to this PR
• Provide diagnosis

Diagnosis

Neither of the 2 CI failures is related to this PR. This PR only modifies torch/_inductor/fx_passes/efficient_conv_bn_eval.py and test/inductor/test_efficient_conv_bn_eval.py. Here's the breakdown:

1. trunk / linux-jammy-aarch64-py3.10 / test (default, 2, 5) — test_sdpa_rewriter_14_cpu

This is a fused attention SDPA pattern rewriter test (test/inductor/test_fused_attention.py::SDPAPatternRewriterCpuTests::test_sdpa_rewriter_14_cpu) that fails with "Unexpected success". This means the test was decorated with @expectedFailure (or similar skip-on-failure marker) on aarch64, but is now passing — so the framework reports it as a failure. This is completely unrelated to the conv-bn eval pass. It's an SDPA attention rewriter test, not a conv-BN fusion test. The DrCI bot also flags this as unclassifiable because "this job did not run on the merge base."

2. pull / linux-jammy-py3.10-clang18 / test (onnx, 1, 1) — test_rotary_embedding_opcheck

This is an ONNX operator test (test/onnx/ops/test_ops.py::NativeOnnxOpsTest::test_rotary_embedding_opcheck) that tests the onnx.RotaryEmbedding custom op. This has appeared as an unclassified failure in previous CI runs on this PR as well (same failure was noted in the May 10th CI run). It has no connection to the inductor conv-bn eval pass.

Summary: Both failures are unrelated. The first is an expectedFailure test that now passes on aarch64 (a trunk-level issue), and the second is a pre-existing ONNX rotary embedding opcheck failure. The PR's own efficient conv-bn eval tests are not shown as failing. Safe to merge.

@pytorchbot merge -i

Merge started

Your change will be merged while ignoring the following 3 checks: pull / linux-jammy-py3.10-clang18 / test (onnx, 1, 1, linux.4xlarge), trunk / linux-jammy-aarch64-py3.10 / test (default, 2, 5, linux.arm64.m7g.4xlarge), trunk / linux-jammy-rocm-py3.10-mi355 / test (default, 8, 10, linux.rocm.gpu.gfx950.1)

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team