Fuse the two halves of the GCC installation detection. This is

significantly cleaner (IMO) and more principled. We now walk down each
layer of the directory hierarchy searching for the GCC install. This
change does in fact introduce a significant behavior change in theory,
although in practice I don't know of any distro that will be impacted by
it negatively, and Debian may (untested) get slightly better through it.

Specifically, the logic now looks exhaustively for patterns such as:

  /usr/lib/<triple>/gcc/<triple>

Previously, this would only be selected if there was *also*
a '/usr/lib/gcc/<triple>' directory, or if '<triple>' were the excat
DefaultHostTriple in the driver.

There is a 4-deep nested loop here, but it doesn't do terribly many
filesystem operations, as we skip at each layer of that layer's
directory doesn't exist.

There remains a significant FIXME in this logic: it would be much better
to first build up a set of candidate components for each of the four
layers with a bottom-up pruning such as this, but then select the final
installation using a top-down algorithm in order to find the newest GCC
installation available, regardless of which particular path leads to it.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141071 91177308-0d34-0410-b5e6-96231b3b80d8

0 files changed, 0 insertions, 0 deletions