[cfe-commits] r164177 - in /cfe/trunk: lib/Driver/ test/Driver/ test/Driver/Inputs/freescale_ppc_tree/ test/Driver/Inputs/freescale_ppc_tree/lib/ test/Driver/Inputs/freescale_ppc_tree/usr/ test/Driver/Inputs/freescale_ppc_tree/usr/lib/ test/Driver/Inputs/freescale_ppc_tree/usr/lib/powerpc-fsl-linux/ test/Driver/Inputs/freescale_ppc_tree/usr/lib/powerpc-fsl-linux/4.6.2/

[Hal Finkel via cfe-commits]

On 02/09/2017 04:58 PM, Chandler Carruth wrote:
> On Thu, Feb 9, 2017 at 2:46 PM Tobias von Koch 
> <tobias.von.koch at gmail.com <mailto:tobias.von.koch at gmail.com>> wrote:
>
>     On Wed, Feb 8, 2017 at 7:21 PM, Chandler Carruth
>     <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote:
>
>
>             +    // The Freescale PPC SDK has the gcc libraries in
>             +    // <sysroot>/usr/lib/<triple>/x.y.z so have a look
>             there as well.
>             +    "/" + CandidateTriple.str(),
>
>
>         So, this is really bad it turns out.
>
>         We use this directory to walk every installed GCC version. But
>         because this is just a normal lib directory on many systems
>         (ever Debian and Ubuntu system for example) this goes very
>         badly. It goes even more badly because of the (questionable)
>         design of LLVM's directory iterator:
>
>
>     Wow, this is pretty bad, but it really sounds like the iterator
>     should be fixed rather than trying to hack around it.
>
>
> I mean, we should.
>
> But even then, walking the entire directory seems bad too... See below.

Agreed. FWIW, it looks like LLVM's directory iterators stat lazily 
(although doing an equality comparison will cause them to stat). Is 
going through Clang's VFS layer causing the eager stating somehow?

>     Doesn't this happen for the other directories as well (which,
>     admittedly, will have less entries)?
>
>
> The *only* entries in the other directories are the actual installed 
> GCC toolchains though, so walking them makes a lot of sense. The 
> tricky thing is that this isn't a gcc-specific directory.
>
> I suspect the fix should be to not use this base path as part of the 
> walk to discover GCC toolchains, and instead to hard code the specific 
> toolchain patterns on this specific platform.
>
> Or we could do the walk, but only when actually on the NXP/Freescale 
> Power platform where this is necessary to find GCC installations.

Given that we don't have a platform on which to test right now, I think 
that this second option sounds best. Only add those directories to the 
search path when -fsl- is in the triple (or something like that).

  -Hal

>
> Both of those would seem reasonable. Fixing the directory iterator 
> would be icing on the cake IMO. =D

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170209/ac8dc1f0/attachment.html>