)]}'
{
  "commit": "56d3ad9d23bc130aa9404bfdd1957fe81b3ba498",
  "tree": "d3789bab037f50e48e63ab069152faee6d418366",
  "parents": [
    "6855f30b94ddfd2970a7aa3d904a356dea5ec443"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Sat Jan 27 12:23:29 2024 -0500"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Wed Jan 31 22:13:17 2024 +0000"
  },
  "message": "Require SSE2 when targetting 32-bit x86\n\nUpdate-Note: Building for 32-bit x86 may require fixing your builds to\npass -msse2 to the compiler. This will also speed up the rest of the\ncode in your project. If your project needs to support the Pentium III,\nplease contact BoringSSL maintainers.\n\nAs far as I know, all our supported 32-bit x86 consumers require SSE2.\nI think, in the past, I\u0027ve asserted that our assembly skips SSE2\ncapability detection. Looking at it again, I don\u0027t think that\u0027s true.\nOPENSSL_IA32_SSE2 means to enable runtime detection of SSE2, not\ncompile-time.\n\nAdditionally, I don\u0027t believe we have *ever* tested the non-SSE2\nassembly codepaths. Also, now that we want to take the OPENSSL_ia32cap_P\naccesses out of assembly, those runtime checks are problematic, as we\u0027d\nneed to bifurcafe functions all the way down to bn_mul_words.\n\nUnfortunately, the situation with compilers is... complicated. Ideally,\neveryone would build with the equivalent of -msse2. 32-bit x86 is so\nregister-poor that running without SSE2 statically available seems\nespecially foolish. However, per\nhttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9868, while\nClang defaults to enabling SSE2, GCC does not.\n\nWe once broke gRPC\u0027s build, in\nhttps://github.com/grpc/grpc/issues/17540, by inadvertently assuming\nSSE2. In that discussion, gRPC maintainers were okay requiring Pentium 4\nas the minimum CPU, but it\u0027s unclear if they actually changed their\nbuild. That discussion also said GCC 8 assumes SSE2, but I\u0027m not able to\nreproduce this.\n\nLLVM does indeed interpret \"i686\" as implying SSE2:\nhttps://github.com/llvm/llvm-project/issues/61347\nhttps://github.com/rust-lang/rust/issues/82435\n\nHowever, Debian LLVM does *not*. Debian carries a patch to turn this\noff!\nhttps://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/blob/snapshot/debian/patches/disable-sse2-old-x86.diff?ref_type\u003dheads\n\nMeanwhile, Fedora fixed their baseline back in 2018.\nhttps://fedoraproject.org/wiki/Changes/Update_i686_architectural_baseline_to_include_SSE2\n\nSo let\u0027s start by detecting builds that forgot to pass -msse2 and see if\nwe can get them fixed. If this sticks, I\u0027ll follow up by unwinding all\nthe SSE2 branches.\n\nBug: 673\nChange-Id: I851184b358aaae2926c3e3fe618f3155e71c2f71\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65875\nReviewed-by: Bob Beck \u003cbbe@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "eaa52c4e7aaaf82885dcbe80fce8e023b0fc11f8",
      "old_mode": 33188,
      "old_path": "crypto/internal.h",
      "new_id": "5894d18145b1d67cc49ece2b42d5938fd528f430",
      "new_mode": 33188,
      "new_path": "crypto/internal.h"
    }
  ]
}