[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/

[Richard Smith via cfe-commits]

On 9 February 2017 at 16:15, Hal Finkel via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> 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>
> wrote:
>
>> On Wed, Feb 8, 2017 at 7:21 PM, Chandler Carruth <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).
>

Done in r295139.


>  -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
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170214/220cb4c0/attachment-0001.html>