)]}'
{
  "commit": "2b4820bd523c7ee7406537bfad1bde9bb29673bb",
  "tree": "0ea2c5191e17d7cb9f1903ae62e3e81ad7799d6c",
  "parents": [
    "9478f321753fcb9b1f495abab4e57aa8f6bfce15"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Wed Apr 27 18:27:11 2016 -0400"
  },
  "committer": {
    "name": "Adam Langley",
    "email": "agl@google.com",
    "time": "Wed Apr 27 23:59:24 2016 +0000"
  },
  "message": "Don\u0027t set a default armcap state in dynamic armcap modes.\n\nThe getauxval (and friends) code would be filling that in anyway. The default\nonly serves to enable NEON even if the OS is old enough to be missing getauxval\n(and everything else).\n\nNotably, this unbreaks the has_buggy_neon code when __ARM_NEON__ is set, as is\nthe case in Chrome for Android, as of M50.  Before, the default\nOPENSSL_armcap_P value was getting in the way.\n\nArguably, this doesn\u0027t make a whole lot of sense. We\u0027re saying we\u0027ll let the\nCPU run compiler-generated NEON code, but not our hand-crafted stuff. But, so\nfar, we only have evidence of the hand-written NEON tickling the bug and not\nthe compiler-generated stuff, so avoid the unintentional regression. (Naively,\nI would expect the hand-crafted NEON is better at making full use of the\npipeline and is thus more likely to tickle the CPU bug.)\n\nThis is not the fix for M50, as in the associated Chromium bug, but it will fix\nmaster and M51. M50 will instead want to revert\nhttps://codereview.chromium.org/1730823002.\n\nBUG\u003dchromium:606629\n\nChange-Id: I394f97fea2f09891dd8fa30e0ec6fc6b1adfab7a\nReviewed-on: https://boringssl-review.googlesource.com/7794\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "dc5c584dc8c66e1fcdbeaa3f51040fc2918acdc2",
      "old_mode": 33188,
      "old_path": "crypto/crypto.c",
      "new_id": "89b0bd14ed6fb55bb2ac676a5be08ef40795cbb7",
      "new_mode": 33188,
      "new_path": "crypto/crypto.c"
    }
  ]
}