)]}'
{
  "commit": "9bed47613c2cc5a42ea060ef5b69ee174571206e",
  "tree": "081602f12025803d3159d59ef6c33076253530d9",
  "parents": [
    "b7254f7c0b65f13f9d4c45031492769b394e2776"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Tue Mar 11 17:02:14 2025 -0400"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Tue Mar 11 14:19:47 2025 -0700"
  },
  "message": "Remove unused \"endbranch\" x86-64 encoder\n\nThere is no such instruction as endbranch. It\u0027s endbr64. That was added\nto binutils in 2.29. That is past our five year policy anyway, though I\nthink we\u0027ve only exercised that recently with VPCLMULQDQ.\n\nBut this is moot because we do CET differently from OpenSSL anyway and\nuse the _CET_ENDBR macro from \u003ccet.h\u003e. I think we can reasonably assume\nthat anyone building with __CET__ has a new enough assembler that\nsupports endbr64.\n\nIf we ever decide to do CET by always encoding the special NOP, as\nOpenSSL does, we may need to go back and reencode things, but by then it\nwill be even less likely that we need to help the assembler out.\n\nChange-Id: I3c9890810c5621f317cb5ecca5cbd8537cca0fe7\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77389\nReviewed-by: Bob Beck \u003cbbe@google.com\u003e\nCommit-Queue: Bob Beck \u003cbbe@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nAuto-Submit: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "2045529191b83c06176632fbb0e69eb160131c17",
      "old_mode": 33261,
      "old_path": "crypto/perlasm/x86_64-xlate.pl",
      "new_id": "0955c866ee1a235f0dbe1c6025069e790e1fc3b1",
      "new_mode": 33261,
      "new_path": "crypto/perlasm/x86_64-xlate.pl"
    }
  ]
}