Fix precision loss in TBE test offset construction by spcyppt · Pull Request #5430 · pytorch/FBGEMM

spcyppt · 2026-02-25T11:09:13Z

Summary:
X-link: https://github.com/facebookresearch/FBGEMM/pull/2402

TLDR;

TBE unit tests constructs offsets via

torch.tensor([0] + np.cumsum(lengths).tolist()).long()

in which torch.tensor() infers torch.float32.
Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent .long() preserves the already-corrupted values.

So for large data where offsets values are supposed to be larger than 16,777,216 can cause offsets to be wrong.

The diff ensures correct dtype so there's no precision loss due to conversion.

Problem

We see TBE forward output mismatch errors in unit tests when we set up large T (number of features) and large B (batch size). We can reproduce this error using the test test_backward_adagrad_with_simple_tbe_op
where

T = 230, B = 294,440
T = 57, B = 294,440 (just enough to cause error)
T = 230, B = 184320

Root cause

After debugging, the root cause was due to the test indices construction and not from the kernels.

np.ones() * L produces a float64 numpy array
.tolist() yields Python floats (float64)
torch.tensor() infers torch.float32 (the
default dtype) — narrowing 64-bit doubles to 32-bit floats.

Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent .long() preserves the already-corrupted values.

This caused (T=230, B=184320, total_B=42M) to fail:
the kernel received wrong offsets for b_t >= 2^24, computing wrong bag lengths (e.g., L=0 or L=2 instead
of 1) and looking up wrong embedding rows. Both v1 and v2 TBE
forward kernels were affected identically since they share the same offsets tensor.

Based on the example above:

Offsets for Table 56 (partially below 2^24, and partially above 2^24):
16486400.0 ... 16780796.0 16780798.0 16780800.0
                      ^^^^^^^^^ odd values missing (L becomes 2, as opposed to 1)

Offsets for Table 57 (fully above 2^24)
16780800.0 16780800.0 16780802.0  ...
           ^^^^^^^^^ should be 16780801, duplicated (L becomes 0, where 1 is expected)

Offsets for Table 113 (above 2^25 -- step size increases to 4):
33267200.0 33267200.0 33267202.0 33267204.0 33267204.0 33267204.0 33267206.0 33267208.0 33267208.0 33267208.0
33561592.0 33561592.0 33561592.0 33561592.0 33561592.0 33561596.0 33561596.0 33561596.0 33561600.0 33561600.0
                ^^^^^^^^^ 3 identical values (more L=0)

Offsets for Table 229 (near 2^26 -- step size is 4, massive gaps):
67417600.0 67417600.0 67417600.0 67417600.0 67417600.0 67417608.0 67417608.0 67417608.0 67417608.0 67417608.0
67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67712000.0 67712000.0 67712000.0 67712000.0
                ^^^^^^^^^ 5 identical values (more L=0)

Fix

The fix ensure np.one to use int and specifies dtype=torch.int64 (or dtype=torch.int32) directly in torch.tensor(), eliminating the float32 conversion.

The fix applies to all offsets constructions or similar usage of np and torch.tensor.

Differential Revision: D94345333

meta-codesync · 2026-02-25T11:09:22Z

@spcyppt has exported this pull request. If you are a Meta employee, you can view the originating Diff in D94345333.

Summary: X-link: facebookresearch/FBGEMM#2402 # TLDR; TBE unit tests constructs offsets via ``` torch.tensor([0] + np.cumsum(lengths).tolist()).long() ``` in which `torch.tensor()` infers `torch.float32`. Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent `.long()` preserves the already-corrupted values. So for large data where offsets values are supposed to be larger than 16,777,216 can cause offsets to be wrong. This also affects backward_adagrad_large dim test. The diff - corrects dtype such that there's no precision loss due to conversion. - re-enables backward_adagrad_large_dim test. ---- # Problem We see TBE forward output mismatch errors in unit tests when we set up large T (number of features) and large B (batch size). We can reproduce this error using the test `test_backward_adagrad_with_simple_tbe_op` where - T = 230, B = 294,440 - T = 57, B = 294,440 (just enough to cause error) - T = 230, B = 184320 # Root cause After debugging, the root cause was due to the test indices construction and not from the kernels. - `np.ones() * L` produces a float64 numpy array - `.tolist()` yields Python floats (float64) - `torch.tensor()` infers `torch.float32` (the default dtype) — narrowing 64-bit doubles to 32-bit floats. Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent `.long()` preserves the already-corrupted values. This caused (T=230, B=184320, total_B=42M) to fail: the kernel received wrong offsets for b_t >= 2^24, computing wrong bag lengths (e.g., L=0 or L=2 instead of 1) and looking up wrong embedding rows. Both v1 and v2 TBE forward kernels were affected identically since they share the same offsets tensor. Based on the example above: ``` Offsets for Table 56 (partially below 2^24, and partially above 2^24): 16486400.0 ... 16780796.0 16780798.0 16780800.0 ^^^^^^^^^ odd values missing (L becomes 2, as opposed to 1) Offsets for Table 57 (fully above 2^24) 16780800.0 16780800.0 16780802.0 ... ^^^^^^^^^ should be 16780801, duplicated (L becomes 0, where 1 is expected) Offsets for Table 113 (above 2^25 -- step size increases to 4): 33267200.0 33267200.0 33267202.0 33267204.0 33267204.0 33267204.0 33267206.0 33267208.0 33267208.0 33267208.0 33561592.0 33561592.0 33561592.0 33561592.0 33561592.0 33561596.0 33561596.0 33561596.0 33561600.0 33561600.0 ^^^^^^^^^ 3 identical values (more L=0) Offsets for Table 229 (near 2^26 -- step size is 4, massive gaps): 67417600.0 67417600.0 67417600.0 67417600.0 67417600.0 67417608.0 67417608.0 67417608.0 67417608.0 67417608.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67712000.0 67712000.0 67712000.0 67712000.0 ^^^^^^^^^ 5 identical values (more L=0) ``` # Fix The fix ensure `np.one` to use `int` and specifies `dtype=torch.int64` (or `dtype=torch.int32`) directly in `torch.tensor()`, eliminating the float32 conversion. The fix applies to all offsets constructions or similar usage of np and torch.tensor. Reviewed By: gchalump Differential Revision: D94345333

Summary: X-link: https://github.com/facebookresearch/FBGEMM/pull/2402 Pull Request resolved: pytorch#5430 # TLDR; TBE unit tests constructs offsets via ``` torch.tensor([0] + np.cumsum(lengths).tolist()).long() ``` in which `torch.tensor()` infers `torch.float32`. Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent `.long()` preserves the already-corrupted values. So for large data where offsets values are supposed to be larger than 16,777,216 can cause offsets to be wrong. This also affects backward_adagrad_large dim test. The diff - corrects dtype such that there's no precision loss due to conversion. - re-enables backward_adagrad_large_dim test. ---- # Problem We see TBE forward output mismatch errors in unit tests when we set up large T (number of features) and large B (batch size). We can reproduce this error using the test `test_backward_adagrad_with_simple_tbe_op` where - T = 230, B = 294,440 - T = 57, B = 294,440 (just enough to cause error) - T = 230, B = 184320 # Root cause After debugging, the root cause was due to the test indices construction and not from the kernels. - `np.ones() * L` produces a float64 numpy array - `.tolist()` yields Python floats (float64) - `torch.tensor()` infers `torch.float32` (the default dtype) — narrowing 64-bit doubles to 32-bit floats. Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent `.long()` preserves the already-corrupted values. This caused (T=230, B=184320, total_B=42M) to fail: the kernel received wrong offsets for b_t >= 2^24, computing wrong bag lengths (e.g., L=0 or L=2 instead of 1) and looking up wrong embedding rows. Both v1 and v2 TBE forward kernels were affected identically since they share the same offsets tensor. Based on the example above: ``` Offsets for Table 56 (partially below 2^24, and partially above 2^24): 16486400.0 ... 16780796.0 16780798.0 16780800.0 ^^^^^^^^^ odd values missing (L becomes 2, as opposed to 1) Offsets for Table 57 (fully above 2^24) 16780800.0 16780800.0 16780802.0 ... ^^^^^^^^^ should be 16780801, duplicated (L becomes 0, where 1 is expected) Offsets for Table 113 (above 2^25 -- step size increases to 4): 33267200.0 33267200.0 33267202.0 33267204.0 33267204.0 33267204.0 33267206.0 33267208.0 33267208.0 33267208.0 33561592.0 33561592.0 33561592.0 33561592.0 33561592.0 33561596.0 33561596.0 33561596.0 33561600.0 33561600.0 ^^^^^^^^^ 3 identical values (more L=0) Offsets for Table 229 (near 2^26 -- step size is 4, massive gaps): 67417600.0 67417600.0 67417600.0 67417600.0 67417600.0 67417608.0 67417608.0 67417608.0 67417608.0 67417608.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67712000.0 67712000.0 67712000.0 67712000.0 ^^^^^^^^^ 5 identical values (more L=0) ``` # Fix The fix ensure `np.one` to use `int` and specifies `dtype=torch.int64` (or `dtype=torch.int32`) directly in `torch.tensor()`, eliminating the float32 conversion. The fix applies to all offsets constructions or similar usage of np and torch.tensor. Reviewed By: gchalump Differential Revision: D94345333

Summary: X-link: facebookresearch/FBGEMM#2402 # TLDR; TBE unit tests constructs offsets via ``` torch.tensor([0] + np.cumsum(lengths).tolist()).long() ``` in which `torch.tensor()` infers `torch.float32`. Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent `.long()` preserves the already-corrupted values. So for large data where offsets values are supposed to be larger than 16,777,216 can cause offsets to be wrong. This also affects backward_adagrad_large dim test. The diff - corrects dtype such that there's no precision loss due to conversion. - re-enables backward_adagrad_large_dim test. ---- # Problem We see TBE forward output mismatch errors in unit tests when we set up large T (number of features) and large B (batch size). We can reproduce this error using the test `test_backward_adagrad_with_simple_tbe_op` where - T = 230, B = 294,440 - T = 57, B = 294,440 (just enough to cause error) - T = 230, B = 184320 # Root cause After debugging, the root cause was due to the test indices construction and not from the kernels. - `np.ones() * L` produces a float64 numpy array - `.tolist()` yields Python floats (float64) - `torch.tensor()` infers `torch.float32` (the default dtype) — narrowing 64-bit doubles to 32-bit floats. Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent `.long()` preserves the already-corrupted values. This caused (T=230, B=184320, total_B=42M) to fail: the kernel received wrong offsets for b_t >= 2^24, computing wrong bag lengths (e.g., L=0 or L=2 instead of 1) and looking up wrong embedding rows. Both v1 and v2 TBE forward kernels were affected identically since they share the same offsets tensor. Based on the example above: ``` Offsets for Table 56 (partially below 2^24, and partially above 2^24): 16486400.0 ... 16780796.0 16780798.0 16780800.0 ^^^^^^^^^ odd values missing (L becomes 2, as opposed to 1) Offsets for Table 57 (fully above 2^24) 16780800.0 16780800.0 16780802.0 ... ^^^^^^^^^ should be 16780801, duplicated (L becomes 0, where 1 is expected) Offsets for Table 113 (above 2^25 -- step size increases to 4): 33267200.0 33267200.0 33267202.0 33267204.0 33267204.0 33267204.0 33267206.0 33267208.0 33267208.0 33267208.0 33561592.0 33561592.0 33561592.0 33561592.0 33561592.0 33561596.0 33561596.0 33561596.0 33561600.0 33561600.0 ^^^^^^^^^ 3 identical values (more L=0) Offsets for Table 229 (near 2^26 -- step size is 4, massive gaps): 67417600.0 67417600.0 67417600.0 67417600.0 67417600.0 67417608.0 67417608.0 67417608.0 67417608.0 67417608.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67712000.0 67712000.0 67712000.0 67712000.0 ^^^^^^^^^ 5 identical values (more L=0) ``` # Fix The fix ensure `np.one` to use `int` and specifies `dtype=torch.int64` (or `dtype=torch.int32`) directly in `torch.tensor()`, eliminating the float32 conversion. The fix applies to all offsets constructions or similar usage of np and torch.tensor. Reviewed By: gchalump Differential Revision: D94345333

Summary: X-link: https://github.com/facebookresearch/FBGEMM/pull/2402 Pull Request resolved: pytorch#5430 # TLDR; TBE unit tests constructs offsets via ``` torch.tensor([0] + np.cumsum(lengths).tolist()).long() ``` in which `torch.tensor()` infers `torch.float32`. Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent `.long()` preserves the already-corrupted values. So for large data where offsets values are supposed to be larger than 16,777,216 can cause offsets to be wrong. This also affects backward_adagrad_large dim test. The diff - corrects dtype such that there's no precision loss due to conversion. - re-enables backward_adagrad_large_dim test. ---- # Problem We see TBE forward output mismatch errors in unit tests when we set up large T (number of features) and large B (batch size). We can reproduce this error using the test `test_backward_adagrad_with_simple_tbe_op` where - T = 230, B = 294,440 - T = 57, B = 294,440 (just enough to cause error) - T = 230, B = 184320 # Root cause After debugging, the root cause was due to the test indices construction and not from the kernels. - `np.ones() * L` produces a float64 numpy array - `.tolist()` yields Python floats (float64) - `torch.tensor()` infers `torch.float32` (the default dtype) — narrowing 64-bit doubles to 32-bit floats. Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent `.long()` preserves the already-corrupted values. This caused (T=230, B=184320, total_B=42M) to fail: the kernel received wrong offsets for b_t >= 2^24, computing wrong bag lengths (e.g., L=0 or L=2 instead of 1) and looking up wrong embedding rows. Both v1 and v2 TBE forward kernels were affected identically since they share the same offsets tensor. Based on the example above: ``` Offsets for Table 56 (partially below 2^24, and partially above 2^24): 16486400.0 ... 16780796.0 16780798.0 16780800.0 ^^^^^^^^^ odd values missing (L becomes 2, as opposed to 1) Offsets for Table 57 (fully above 2^24) 16780800.0 16780800.0 16780802.0 ... ^^^^^^^^^ should be 16780801, duplicated (L becomes 0, where 1 is expected) Offsets for Table 113 (above 2^25 -- step size increases to 4): 33267200.0 33267200.0 33267202.0 33267204.0 33267204.0 33267204.0 33267206.0 33267208.0 33267208.0 33267208.0 33561592.0 33561592.0 33561592.0 33561592.0 33561592.0 33561596.0 33561596.0 33561596.0 33561600.0 33561600.0 ^^^^^^^^^ 3 identical values (more L=0) Offsets for Table 229 (near 2^26 -- step size is 4, massive gaps): 67417600.0 67417600.0 67417600.0 67417600.0 67417600.0 67417608.0 67417608.0 67417608.0 67417608.0 67417608.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67712000.0 67712000.0 67712000.0 67712000.0 ^^^^^^^^^ 5 identical values (more L=0) ``` # Fix The fix ensure `np.one` to use `int` and specifies `dtype=torch.int64` (or `dtype=torch.int32`) directly in `torch.tensor()`, eliminating the float32 conversion. The fix applies to all offsets constructions or similar usage of np and torch.tensor. Reviewed By: gchalump Differential Revision: D94345333

Summary: X-link: facebookresearch/FBGEMM#2402 # TLDR; TBE unit tests constructs offsets via ``` torch.tensor([0] + np.cumsum(lengths).tolist()).long() ``` in which `torch.tensor()` infers `torch.float32`. Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent `.long()` preserves the already-corrupted values. So for large data where offsets values are supposed to be larger than 16,777,216 can cause offsets to be wrong. This also affects backward_adagrad_large dim test. The diff - corrects dtype such that there's no precision loss due to conversion. - re-enables backward_adagrad_large_dim test. ---- # Problem We see TBE forward output mismatch errors in unit tests when we set up large T (number of features) and large B (batch size). We can reproduce this error using the test `test_backward_adagrad_with_simple_tbe_op` where - T = 230, B = 294,440 - T = 57, B = 294,440 (just enough to cause error) - T = 230, B = 184320 # Root cause After debugging, the root cause was due to the test indices construction and not from the kernels. - `np.ones() * L` produces a float64 numpy array - `.tolist()` yields Python floats (float64) - `torch.tensor()` infers `torch.float32` (the default dtype) — narrowing 64-bit doubles to 32-bit floats. Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent `.long()` preserves the already-corrupted values. This caused (T=230, B=184320, total_B=42M) to fail: the kernel received wrong offsets for b_t >= 2^24, computing wrong bag lengths (e.g., L=0 or L=2 instead of 1) and looking up wrong embedding rows. Both v1 and v2 TBE forward kernels were affected identically since they share the same offsets tensor. Based on the example above: ``` Offsets for Table 56 (partially below 2^24, and partially above 2^24): 16486400.0 ... 16780796.0 16780798.0 16780800.0 ^^^^^^^^^ odd values missing (L becomes 2, as opposed to 1) Offsets for Table 57 (fully above 2^24) 16780800.0 16780800.0 16780802.0 ... ^^^^^^^^^ should be 16780801, duplicated (L becomes 0, where 1 is expected) Offsets for Table 113 (above 2^25 -- step size increases to 4): 33267200.0 33267200.0 33267202.0 33267204.0 33267204.0 33267204.0 33267206.0 33267208.0 33267208.0 33267208.0 33561592.0 33561592.0 33561592.0 33561592.0 33561592.0 33561596.0 33561596.0 33561596.0 33561600.0 33561600.0 ^^^^^^^^^ 3 identical values (more L=0) Offsets for Table 229 (near 2^26 -- step size is 4, massive gaps): 67417600.0 67417600.0 67417600.0 67417600.0 67417600.0 67417608.0 67417608.0 67417608.0 67417608.0 67417608.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67712000.0 67712000.0 67712000.0 67712000.0 ^^^^^^^^^ 5 identical values (more L=0) ``` # Fix The fix ensure `np.one` to use `int` and specifies `dtype=torch.int64` (or `dtype=torch.int32`) directly in `torch.tensor()`, eliminating the float32 conversion. The fix applies to all offsets constructions or similar usage of np and torch.tensor. Reviewed By: gchalump Differential Revision: D94345333

meta-codesync · 2026-02-27T07:52:02Z

This pull request has been merged in 83ba4fb.

Summary: X-link: https://github.com/facebookresearch/FBGEMM/pull/2402 Pull Request resolved: #5430 # TLDR; TBE unit tests constructs offsets via ``` torch.tensor([0] + np.cumsum(lengths).tolist()).long() ``` in which `torch.tensor()` infers `torch.float32`. Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent `.long()` preserves the already-corrupted values. So for large data where offsets values are supposed to be larger than 16,777,216 can cause offsets to be wrong. This also affects backward_adagrad_large dim test. The diff - corrects dtype such that there's no precision loss due to conversion. - re-enables backward_adagrad_large_dim test. ---- # Problem We see TBE forward output mismatch errors in unit tests when we set up large T (number of features) and large B (batch size). We can reproduce this error using the test `test_backward_adagrad_with_simple_tbe_op` where - T = 230, B = 294,440 - T = 57, B = 294,440 (just enough to cause error) - T = 230, B = 184320 # Root cause After debugging, the root cause was due to the test indices construction and not from the kernels. - `np.ones() * L` produces a float64 numpy array - `.tolist()` yields Python floats (float64) - `torch.tensor()` infers `torch.float32` (the default dtype) — narrowing 64-bit doubles to 32-bit floats. Float32 can only represent consecutive integers up to 2^24 (16,777,216); beyond that, odd values round to even, producing wrong offsets. The subsequent `.long()` preserves the already-corrupted values. This caused (T=230, B=184320, total_B=42M) to fail: the kernel received wrong offsets for b_t >= 2^24, computing wrong bag lengths (e.g., L=0 or L=2 instead of 1) and looking up wrong embedding rows. Both v1 and v2 TBE forward kernels were affected identically since they share the same offsets tensor. Based on the example above: ``` Offsets for Table 56 (partially below 2^24, and partially above 2^24): 16486400.0 ... 16780796.0 16780798.0 16780800.0 ^^^^^^^^^ odd values missing (L becomes 2, as opposed to 1) Offsets for Table 57 (fully above 2^24) 16780800.0 16780800.0 16780802.0 ... ^^^^^^^^^ should be 16780801, duplicated (L becomes 0, where 1 is expected) Offsets for Table 113 (above 2^25 -- step size increases to 4): 33267200.0 33267200.0 33267202.0 33267204.0 33267204.0 33267204.0 33267206.0 33267208.0 33267208.0 33267208.0 33561592.0 33561592.0 33561592.0 33561592.0 33561592.0 33561596.0 33561596.0 33561596.0 33561600.0 33561600.0 ^^^^^^^^^ 3 identical values (more L=0) Offsets for Table 229 (near 2^26 -- step size is 4, massive gaps): 67417600.0 67417600.0 67417600.0 67417600.0 67417600.0 67417608.0 67417608.0 67417608.0 67417608.0 67417608.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67711992.0 67712000.0 67712000.0 67712000.0 67712000.0 ^^^^^^^^^ 5 identical values (more L=0) ``` # Fix The fix ensure `np.one` to use `int` and specifies `dtype=torch.int64` (or `dtype=torch.int32`) directly in `torch.tensor()`, eliminating the float32 conversion. The fix applies to all offsets constructions or similar usage of np and torch.tensor. Reviewed By: gchalump, q10 Differential Revision: D94345333 fbshipit-source-id: 5085ab31f4e9ebb05d269c8708efff454655eaa8

meta-cla bot added the cla signed label Feb 25, 2026

meta-codesync bot added fb-exported meta-exported labels Feb 25, 2026

spcyppt force-pushed the export-D94345333 branch from d817d41 to b3fa4bc Compare February 26, 2026 03:38

spcyppt force-pushed the export-D94345333 branch from b3fa4bc to 9c7cf1a Compare February 26, 2026 03:59

spcyppt force-pushed the export-D94345333 branch from 9c7cf1a to 638594e Compare February 26, 2026 03:59

spcyppt force-pushed the export-D94345333 branch 2 times, most recently from 0784121 to 118df08 Compare February 26, 2026 04:05

spcyppt force-pushed the export-D94345333 branch from 118df08 to 5db3e1b Compare February 26, 2026 12:47

spcyppt force-pushed the export-D94345333 branch from 5db3e1b to eb9a912 Compare February 26, 2026 12:48

spcyppt force-pushed the export-D94345333 branch from eb9a912 to d374e67 Compare February 26, 2026 12:51

spcyppt force-pushed the export-D94345333 branch 2 times, most recently from 770e890 to 3694476 Compare February 26, 2026 23:07

spcyppt force-pushed the export-D94345333 branch from 3694476 to cd9f8ea Compare February 27, 2026 02:15

meta-codesync bot closed this in 83ba4fb Feb 27, 2026

facebook-github-bot added the Merged label Feb 27, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix precision loss in TBE test offset construction#5430

Fix precision loss in TBE test offset construction#5430
spcyppt wants to merge 1 commit intopytorch:mainfrom
spcyppt:export-D94345333

spcyppt commented Feb 25, 2026 •

edited

Loading

Uh oh!

meta-codesync bot commented Feb 25, 2026

Uh oh!

meta-codesync bot commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

spcyppt commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

TLDR;

Problem

Root cause

Fix

Uh oh!

meta-codesync bot commented Feb 25, 2026

Uh oh!

meta-codesync bot commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

spcyppt commented Feb 25, 2026 •

edited

Loading