)]}'
{
  "commit": "a514707ffd7d58b140686036c2dece43ecb7d33c",
  "tree": "92d5a481e3f8671b748263979d6b08402045088e",
  "parents": [
    "f62f68e7c4bde0385fbd2dba3e926586dd2f1281"
  ],
  "author": {
    "name": "Jeff Law",
    "email": "jeffrey.law@oss.qualcomm.com",
    "time": "Sat Jun 13 09:05:32 2026 -0600"
  },
  "committer": {
    "name": "Jeff Law",
    "email": "jeffrey.law@oss.qualcomm.com",
    "time": "Sat Jun 13 09:05:32 2026 -0600"
  },
  "message": "[PATCH v6 4/4] find_a_program: Search with machine prefix in some cases\n\nPrefatory note:\n\nI\u0027ve since learned that this quite similar to\nhttps://inbox.sourceware.org/gcc-patches/20240522095404.1825269-1-syq@gcc.gnu.org/,\npostdating my original patch series, but predating this version. See\nthat thread for additional motivation. That patch updated a few specific\ncallsite for various programs; I instead opted to enhance find_a_program\n(which I myself originally factored out of find_a_file in\n5fee8a0a9223d030c66d53c104fb0a431369248f for this purpose) to catch all\nsuch cases programmatically.\n\nBehavior Change:\n\nToday, GCC will search for:\n\n1. path/$machine/$version/prog\n2. path/$machine/prog\n3. path/prog\n\nThis means, we might search for:\n\n1. path/$machine/$version/prog\n2. path/$machine/prog\n3. path/$machine-prog # new\n4. path/prog\n\nBut it will not search for:\n\n- path/$machine/$version/$machine-prog\n- path/$machine/$machine-prog\n\nI want this change because when cross compiling, users expect prefixed\ntools, like\n\n - $AS \u003d $machine-as\n - $LD \u003d $machine-ld\n\netc. and it would be less confusing if GCC would find those same tools\nin a similar way. GCC instead looking for its own (less widely used than\nprefixing) nested-directory way of disambiguating, and then falling back\nlooking for *unprefixed* tools (which typically are for the wrong\nplatform in cross cases) is quite confusing. In my distro, Nixpkgs, and\nelsewhere, I\u0027ve seen people draw the wrong conclusions because of this,\nwhich is that one must use absolute paths hard-coded at build time in\norder to get the right behavior, and dodge the incorrect unprefixed\ntools.\n\nFor what its worth, Clang/LLVM also look for prefixed tools in this\nmanner, so this isn\u0027t the first time it would be done. The difference is\nthat they will look for prefixed tools in *all* cases --- i.e. also\nwithin the machine-specific locations as I outlined above (as things\nthis patch does *not* do). I think that was done for mere coding\nconvenience, and there is no actual motivation \"doubly disambiguating\"\ntools with machine directories and machine prefixes. So in the interest\nof sticking strictly to the motivation / being conservative in how much\nnew behavior is implemented, I did not implement that part.\n\ngcc/ChangeLog:\n\n\t* gcc.cc (find_a_program): Implement the new behavior described\n\tabove.\n\t(driver::set_up_specs): Initilize variable. It would be nice to\n\thave less spooky-action-at-a-distince using C++ features, but I\n\tjust matched how the corresponding suffix variable worked for\n\tnow for uniformity.\n\nSigned-off-by: John Ericson \u003cgit@JohnEricson.me\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "c2a5abe916eeb24b2b513616b8f24e27f98aa970",
      "old_mode": 33188,
      "old_path": "gcc/gcc.cc",
      "new_id": "9ef2a21745a4b4ec8f5f66d59f180e6955c90505",
      "new_mode": 33188,
      "new_path": "gcc/gcc.cc"
    }
  ]
}