)]}'
{
  "commit": "954f90d2f53b22ff8b347ae215d58b6cb1ca1cb3",
  "tree": "10419b00ad1193ee823a131e57e8c8916fefb114",
  "parents": [
    "fbf06b1c5baf527c58fe360aa4e573e58abd6238"
  ],
  "author": {
    "name": "Alex Vasile",
    "email": "48962821+Alex-Vasile@users.noreply.github.com",
    "time": "Mon Jun 29 05:45:55 2026 -0400"
  },
  "committer": {
    "name": "GitHub",
    "email": "noreply@github.com",
    "time": "Mon Jun 29 11:45:55 2026 +0200"
  },
  "message": "[Metal] Fix fill_buffer_1byte edge handling for unaligned offsets (#24639)\n\nfill_buffer_1byte silently corrupted data for any buffer_offset % 4 in\n{1, 3}, and corrupted neighboring bytes for fills contained within a\nsingle 4-byte word. Two independent defects, both in the edge handling:\n\n1. left_mask selected the wrong byte positions. It was computed as ~((1\n\u003c\u003c (8 * (4 - left_byte_count))) - 1), selecting byte positions [4-k, 4)\nof the left word. But the left edge must overwrite the high (4-k) bytes,\ni.e. positions [k, 4), so the mask must be ~((1 \u003c\u003c (8 * k)) - 1). The\nstray \"4 -\" is the asymmetry with the correct right_mask (which uses\nright_byte_count directly). For k in {1, 3} the wrong mask is a\nsymmetric 2-byte misplacement (|4-2k| \u003d\u003d 2):\n- offset % 4 \u003d\u003d 1: under-fill -- the leading 2 in-region bytes are left\nstale.\n- offset % 4 \u003d\u003d 3: underrun -- the 2 bytes immediately preceding the\nregion are clobbered.\n\n2. When the entire fill range fits within one 32-bit word, the left and\nright read-modify-write blocks both attacked that same word with masks\nassuming a complete edge, writing pattern bytes outside [offset, offset\n+ length). Reachable via short 1/2-byte-pattern fills (duplicated to 4\nbytes on the host) whose length lands within one word.\n\nBeyond the k \u003d\u003d 0 case (handled by fill_buffer_4byte), the kernel was\ncorrect only for offset % 4 \u003d\u003d 2 with length \u003e\u003d 2.\n\nFix (kernel-only):\n\n- Correct left_mask: use left_byte_count instead of (4 -\nleft_byte_count).\n- Add a single-word guard: when left_start \u003d\u003d right_start, perform one\nread-modify-write over bytes [left_byte_count, right_byte_count) using\nmask \u003d left_mask \u0026 right_mask; otherwise keep the existing separate\nleft/right blocks. This also makes length \u003d\u003d 0 a safe no-op via mask\ncollapse, where the original corrupted up to 4 neighbor bytes.\n\nNo host-side change: the middle word range [middle_start, right_start)\nand thus the thread-count requirement are unchanged, and the existing\ndispatch sizing in builtin_executables.m already over-dispatches safely.\n\nVerified:\nCTS/CommandBufferFillBufferTest.FillSizeAlignmentAndPatternClasses/metal\nand CTS/QueueTransferTest.FillSizeAlignmentAndPatternClasses/metal now\npass (previously failed with a 2-byte under-fill at offset%4\u003d\u003d1 and a\n2-byte underrun at offset%4\u003d\u003d3); all *Fill* cases pass (22/22 in\ncommand_buffer_tests, 8/8 in queue_tests).\n\nSigned-off-by: Alex Vasile \u003c48962821+Alex-Vasile@users.noreply.github.com\u003e",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "281bd0519202c940b6af40c3a951c5f0b089e835",
      "old_mode": 33188,
      "old_path": "runtime/src/iree/hal/drivers/metal/builtin/fill_buffer_generic.metal",
      "new_id": "09dafec2a4a9164390a5f90cf9e3810982254c1d",
      "new_mode": 33188,
      "new_path": "runtime/src/iree/hal/drivers/metal/builtin/fill_buffer_generic.metal"
    }
  ]
}