Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup
Hi Bruno,
I had to revert this in r269100 because it was looking like the bot was
going to be left red overnight.
Changes to this VFS code seem to have a trend of breaking on windows. Any
idea why that is? I can understand things breaking on windows when writing
low-level parts of an FS abstraction, but this patch seems fairly
high-level. Is there a missing layering or something?
-- Sean Silva
On Tue, May 10, 2016 at 11:43 AM, Bruno Cardoso Lopes via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: bruno
> Date: Tue May 10 13:43:00 2016
> New Revision: 269100
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269100&view=rev
> Log:
> [VFS] Reconstruct the VFS overlay tree for more accurate lookup
>
> The way we currently build the internal VFS overlay representation leads
> to inefficient path search and might yield wrong answers when asked for
> recursive or regular directory iteration.
>
> Currently, when reading an YAML file, each YAML root entry is placed
> inside a new root in the filesystem overlay. In the crash reproducer, a
> simple "@import Foundation" currently maps to 43 roots, and when looking
> up paths, we traverse a directory tree for each of these different
> roots, until we find a match (or don't). This has two consequences:
>
> - It's slow.
> - Directory iteration gives incomplete results since it only return
> results within one root - since contents of the same directory can be
> declared inside different roots, the result isn't accurate.
>
> This is in part fault of the way we currently write out the YAML file
> when emitting the crash reproducer - we could generate only one root and
> that would make it fast and correct again. However, we should not rely
> on how the client writes the YAML, but provide a good internal
> representation regardless.
>
> This patch builds a proper virtual directory tree out of the YAML
> representation, allowing faster search and proper iteration. Besides the
> crash reproducer, this potentially benefits other VFS clients.
>
> Modified:
> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>
> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=269100&r1=269099&r2=269100&view=diff
>
> ==
> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
> +++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Tue May 10 13:43:00 2016
> @@ -719,7 +719,13 @@ public:
> Status S)
>: Entry(EK_Directory, Name), Contents(std::move(Contents)),
> S(std::move(S)) {}
> + RedirectingDirectoryEntry(StringRef Name, Status S)
> + : Entry(EK_Directory, Name), S(std::move(S)) {}
>Status getStatus() { return S; }
> + void addContent(std::unique_ptr Content) {
> +Contents.push_back(std::move(Content));
> + }
> + Entry *getLastContent() const { return Contents.back().get(); }
>typedef decltype(Contents)::iterator iterator;
>iterator contents_begin() { return Contents.begin(); }
>iterator contents_end() { return Contents.end(); }
> @@ -747,6 +753,7 @@ public:
> return UseName == NK_NotSet ? GlobalUseExternalName
> : (UseName == NK_External);
>}
> + NameKind getUseName() const { return UseName; }
>static bool classof(const Entry *E) { return E->getKind() == EK_File; }
> };
>
> @@ -1023,6 +1030,70 @@ class RedirectingFileSystemParser {
> return true;
>}
>
> + Entry *lookupOrCreateEntry(RedirectingFileSystem *FS, StringRef Name,
> + Entry *ParentEntry = nullptr) {
> +if (!ParentEntry) { // Look for a existent root
> + for (const std::unique_ptr &Root : FS->Roots) {
> +if (Name.equals(Root->getName())) {
> + ParentEntry = Root.get();
> + return ParentEntry;
> +}
> + }
> +} else { // Advance to the next component
> + auto *DE = dyn_cast(ParentEntry);
> + for (std::unique_ptr &Content :
> + llvm::make_range(DE->contents_begin(), DE->contents_end())) {
> +auto *DirContent =
> dyn_cast(Content.get());
> +if (DirContent && Name.equals(Content->getName()))
> + return DirContent;
> + }
> +}
> +
> +// ... or create a new one
> +std::unique_ptr E =
> llvm::make_unique(
> +Name, Status("", getNextVirtualUniqueID(), sys::TimeValue::now(),
> 0, 0,
> + 0, file_type::directory_file, sys::fs::all_all));
> +
> +if (!ParentEntry) { // Add a new root to the overlay
> + FS->Roots.push_back(std::move(E));
> + ParentEntry = FS->Roots.back().get();
> + return ParentEntry;
> +}
> +
> +auto *DE = dyn_cast(ParentEntry);
> +DE->addContent(std::move(E));
> +return DE->getLastContent();
> + }
> +
> + void uniqueOverlayTree(RedirectingFileSystem *FS, Entry *SrcE,
Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup
Thanks Sean,
I was about to ask for help and try a 4th attempt, as you noted after
3 attempts I was not yet able to make this work on windows though...
The new tests I added first failed on windows because looks like a
missing "/" on the dir name forces "\\" to be generated while
appending the filename instead of "/". After fixing that, now seems
like the directory iteration on windows has a different order from
what we are getting on the other platforms, do you know anything about
this? Or can you help me debug it once I land it again? I might
check-in the new tests separately from the rest to make it easier to
revert.
TEST 'Clang-Unit ::
Basic/BasicTests.exe/VFSFromYAMLTest.DirectoryIteration' FAILED
Note: Google Test filter = VFSFromYAMLTest.DirectoryIteration
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from VFSFromYAMLTest
[ RUN ] VFSFromYAMLTest.DirectoryIteration
C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\unittests\Basic\VirtualFileSystemTest.cpp(379):
error: Value of: I->getName()
Actual: { '/' (47, 0x2F), '/' (47, 0x2F), 'r' (114, 0x72), 'o' (111,
0x6F), 'o' (111, 0x6F), 't' (116, 0x74), '/' (47, 0x2F), 'b' (98,
0x62), 'a' (97, 0x61), 'z' (122, 0x7A), '/' (47, 0x2F), 'c' (99, 0x63)
}
Expected: *ExpectedIter
Which is: { '/' (47, 0x2F), '/' (47, 0x2F), 'r' (114, 0x72), 'o' (111,
0x6F), 'o' (111, 0x6F), 't' (116, 0x74), '/' (47, 0x2F), 'b' (98,
0x62), 'a' (97, 0x61), 'z' (122, 0x7A), '/' (47, 0x2F), 'x' (120,
0x78) }
C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\unittests\Basic\VirtualFileSystemTest.cpp(381):
error: Value of: ExpectedIter
Actual: 00C72A87F7E0
Expected: ExpectedEnd
Which is: 00C72A87F800
[ FAILED ] VFSFromYAMLTest.DirectoryIteration (1 ms)
On Tue, May 10, 2016 at 9:27 PM, Sean Silva wrote:
> Hi Bruno,
>
> I had to revert this in r269100 because it was looking like the bot was
> going to be left red overnight.
>
> Changes to this VFS code seem to have a trend of breaking on windows. Any
> idea why that is? I can understand things breaking on windows when writing
> low-level parts of an FS abstraction, but this patch seems fairly
> high-level. Is there a missing layering or something?
>
> -- Sean Silva
>
> On Tue, May 10, 2016 at 11:43 AM, Bruno Cardoso Lopes via cfe-commits
> wrote:
>>
>> Author: bruno
>> Date: Tue May 10 13:43:00 2016
>> New Revision: 269100
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=269100&view=rev
>> Log:
>> [VFS] Reconstruct the VFS overlay tree for more accurate lookup
>>
>> The way we currently build the internal VFS overlay representation leads
>> to inefficient path search and might yield wrong answers when asked for
>> recursive or regular directory iteration.
>>
>> Currently, when reading an YAML file, each YAML root entry is placed
>> inside a new root in the filesystem overlay. In the crash reproducer, a
>> simple "@import Foundation" currently maps to 43 roots, and when looking
>> up paths, we traverse a directory tree for each of these different
>> roots, until we find a match (or don't). This has two consequences:
>>
>> - It's slow.
>> - Directory iteration gives incomplete results since it only return
>> results within one root - since contents of the same directory can be
>> declared inside different roots, the result isn't accurate.
>>
>> This is in part fault of the way we currently write out the YAML file
>> when emitting the crash reproducer - we could generate only one root and
>> that would make it fast and correct again. However, we should not rely
>> on how the client writes the YAML, but provide a good internal
>> representation regardless.
>>
>> This patch builds a proper virtual directory tree out of the YAML
>> representation, allowing faster search and proper iteration. Besides the
>> crash reproducer, this potentially benefits other VFS clients.
>>
>> Modified:
>> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
>> cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>>
>> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=269100&r1=269099&r2=269100&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
>> +++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Tue May 10 13:43:00 2016
>> @@ -719,7 +719,13 @@ public:
>> Status S)
>>: Entry(EK_Directory, Name), Contents(std::move(Contents)),
>> S(std::move(S)) {}
>> + RedirectingDirectoryEntry(StringRef Name, Status S)
>> + : Entry(EK_Directory, Name), S(std::move(S)) {}
>>Status getStatus() { return S; }
>> + void addContent(std::unique_ptr Content) {
>> +Contents.push_back(std::move(Content));
>> + }
>> + Entry
Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup
On Tue, May 10, 2016 at 9:49 PM, Bruno Cardoso Lopes <
bruno.card...@gmail.com> wrote:
> Thanks Sean,
>
> I was about to ask for help and try a 4th attempt, as you noted after
> 3 attempts I was not yet able to make this work on windows though...
>
So sorry! It had gone quiet for a few hours and I wanted to avoid leaving
it red any longer.
> The new tests I added first failed on windows because looks like a
> missing "/" on the dir name forces "\\" to be generated while
> appending the filename instead of "/". After fixing that, now seems
> like the directory iteration on windows has a different order from
> what we are getting on the other platforms, do you know anything about
> this?
Does any platform define a guaranteed directory iteration order? I feel
like depending on it in the first place is unwise (or maybe I'm
misunderstanding? e.g. I'm thinking that we should sort the results of
directory iteration to guarantee a particular order if needed for a
comparison in a test)
> Or can you help me debug it once I land it again?
Sure, but like I mentioned the nature of this error is very troubling to me
(high-level API use running into low-level system issues). It suggests that
there is an incorrect layering or something. I hate these annoying windows
path issues as much as everyone else, so I'd rather we focus energy on
building an appropriate layering to consolidate all the special handling in
one place than to continually band-aid issues as they creep into all parts
of the codebase. VirtualFileSystem.cpp already has quite a bit of technical
debt that violates our policies in this regard (platform-specific #ifdef's
outside libSupport; I count 3 in VirtualFileSystem.cpp which is a huge
number considering how recent that code is).
> I might
> check-in the new tests separately from the rest to make it easier to
> revert.
>
I don't think there's precedent for doing this in LLVM (or at least it
would be considered as bad practice). We typically check in tests alongside
the code being tested specifically to avoid the temptation to leave
untested/broken code in tree.
-- Sean Silva
>
>
> TEST 'Clang-Unit ::
> Basic/BasicTests.exe/VFSFromYAMLTest.DirectoryIteration' FAILED
>
> Note: Google Test filter = VFSFromYAMLTest.DirectoryIteration
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from VFSFromYAMLTest
> [ RUN ] VFSFromYAMLTest.DirectoryIteration
>
>
> C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\unittests\Basic\VirtualFileSystemTest.cpp(379):
> error: Value of: I->getName()
>
> Actual: { '/' (47, 0x2F), '/' (47, 0x2F), 'r' (114, 0x72), 'o' (111,
> 0x6F), 'o' (111, 0x6F), 't' (116, 0x74), '/' (47, 0x2F), 'b' (98,
> 0x62), 'a' (97, 0x61), 'z' (122, 0x7A), '/' (47, 0x2F), 'c' (99, 0x63)
> }
>
> Expected: *ExpectedIter
>
> Which is: { '/' (47, 0x2F), '/' (47, 0x2F), 'r' (114, 0x72), 'o' (111,
> 0x6F), 'o' (111, 0x6F), 't' (116, 0x74), '/' (47, 0x2F), 'b' (98,
> 0x62), 'a' (97, 0x61), 'z' (122, 0x7A), '/' (47, 0x2F), 'x' (120,
> 0x78) }
>
>
> C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\unittests\Basic\VirtualFileSystemTest.cpp(381):
> error: Value of: ExpectedIter
>
> Actual: 00C72A87F7E0
>
> Expected: ExpectedEnd
> Which is: 00C72A87F800
> [ FAILED ] VFSFromYAMLTest.DirectoryIteration (1 ms)
>
>
>
> On Tue, May 10, 2016 at 9:27 PM, Sean Silva wrote:
> > Hi Bruno,
> >
> > I had to revert this in r269100 because it was looking like the bot was
> > going to be left red overnight.
> >
> > Changes to this VFS code seem to have a trend of breaking on windows. Any
> > idea why that is? I can understand things breaking on windows when
> writing
> > low-level parts of an FS abstraction, but this patch seems fairly
> > high-level. Is there a missing layering or something?
> >
> > -- Sean Silva
> >
> > On Tue, May 10, 2016 at 11:43 AM, Bruno Cardoso Lopes via cfe-commits
> > wrote:
> >>
> >> Author: bruno
> >> Date: Tue May 10 13:43:00 2016
> >> New Revision: 269100
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=269100&view=rev
> >> Log:
> >> [VFS] Reconstruct the VFS overlay tree for more accurate lookup
> >>
> >> The way we currently build the internal VFS overlay representation leads
> >> to inefficient path search and might yield wrong answers when asked for
> >> recursive or regular directory iteration.
> >>
> >> Currently, when reading an YAML file, each YAML root entry is placed
> >> inside a new root in the filesystem overlay. In the crash reproducer, a
> >> simple "@import Foundation" currently maps to 43 roots, and when looking
> >> up paths, we traverse a directory tree for each of these different
> >> roots, until we find a match (or don't). This has two consequences:
> >>
> >> - It's slow.
> >> - Directory iteration gives incomplete results since it only return
> >> results
Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup
Hi Sean, > So sorry! It had gone quiet for a few hours and I wanted to avoid leaving it > red any longer. No problem, the priority is to get bot greens! > Does any platform define a guaranteed directory iteration order? I feel like > depending on it in the first place is unwise (or maybe I'm misunderstanding? > e.g. I'm thinking that we should sort the results of directory iteration to > guarantee a particular order if needed for a comparison in a test) Yes, I was thinking about that too, however I'm not yet sure this is actually happening due to iteration order. >> >> Or can you help me debug it once I land it again? > > > Sure, but like I mentioned the nature of this error is very troubling to me > (high-level API use running into low-level system issues). It suggests that > there is an incorrect layering or something. I hate these annoying windows > path issues as much as everyone else, so I'd rather we focus energy on > building an appropriate layering to consolidate all the special handling in > one place than to continually band-aid issues as they creep into all parts > of the codebase. VirtualFileSystem.cpp already has quite a bit of technical > debt that violates our policies in this regard (platform-specific #ifdef's > outside libSupport; I count 3 in VirtualFileSystem.cpp which is a huge > number considering how recent that code is). Totally agree. Part of that is on me - I'm actually relying on http://reviews.llvm.org/D19842 as a base to do a proper clean up by using a target independent version of realpath. FileManager is likely benefiting from that as well (and has itself some layering violations I took precedence from). However, I'm not even sure what are the root causes that make stuff fails on windows, given that, it's hard to know what proper layering should look like, because aside windows-avoid hacks, the rest looks fine to me; I count on you then to help me with that, feel free to file PRs about anything specific :) >> >> I might >> check-in the new tests separately from the rest to make it easier to >> revert. > > > I don't think there's precedent for doing this in LLVM (or at least it would > be considered as bad practice). We typically check in tests alongside the > code being tested specifically to avoid the temptation to leave > untested/broken code in tree. True. However it's kinda subtle in this case: (1) this patch is not really a feature, it just re-arranges the tree to allow faster search, so the current tests passing should be enough. OTOH, the side-effect is that it fixes directory iteration because different roots pointing to the same path now can be seen as the same by directory iteration. I had the intention to test that, to make sure we don't regress in the future. (2) I have no other way to "debug" on windows10-ps4 platform besides reducing-by-commit. Anyway, I'm gonna try a more minimal testcase first. -- Bruno Cardoso Lopes http://www.brunocardoso.cc ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup
On Tue, May 10, 2016 at 11:14 PM, Bruno Cardoso Lopes < bruno.card...@gmail.com> wrote: > Hi Sean, > > > So sorry! It had gone quiet for a few hours and I wanted to avoid > leaving it > > red any longer. > > No problem, the priority is to get bot greens! > > > Does any platform define a guaranteed directory iteration order? I feel > like > > depending on it in the first place is unwise (or maybe I'm > misunderstanding? > > e.g. I'm thinking that we should sort the results of directory iteration > to > > guarantee a particular order if needed for a comparison in a test) > > Yes, I was thinking about that too, however I'm not yet sure this is > actually happening due to iteration order. > > >> > >> Or can you help me debug it once I land it again? > > > > > > Sure, but like I mentioned the nature of this error is very troubling to > me > > (high-level API use running into low-level system issues). It suggests > that > > there is an incorrect layering or something. I hate these annoying > windows > > path issues as much as everyone else, so I'd rather we focus energy on > > building an appropriate layering to consolidate all the special handling > in > > one place than to continually band-aid issues as they creep into all > parts > > of the codebase. VirtualFileSystem.cpp already has quite a bit of > technical > > debt that violates our policies in this regard (platform-specific > #ifdef's > > outside libSupport; I count 3 in VirtualFileSystem.cpp which is a huge > > number considering how recent that code is). > > Totally agree. Part of that is on me - I'm actually relying on > http://reviews.llvm.org/D19842 as a base to do a proper clean up by > using a target independent version of realpath. FileManager is likely > benefiting from that as well (and has itself some layering violations > I took precedence from). However, I'm not even sure what are the root > causes that make stuff fails on windows, given that, it's hard to know > what proper layering should look like, because aside windows-avoid > hacks, the rest looks fine to me; I count on you then to help me with > that, feel free to file PRs about anything specific :) > I'm glad to help, but it makes me uneasy to have somebody working on a filesystem abstraction that does not have ready access to test and debug their changes across the major host platforms that LLVM supports (linux, mac, windows). Is there any way you can get access? I don't think that windows 10 is critical here; win7 or win8 are fine. -- Sean Silva > > >> > >> I might > >> check-in the new tests separately from the rest to make it easier to > >> revert. > > > > > > I don't think there's precedent for doing this in LLVM (or at least it > would > > be considered as bad practice). We typically check in tests alongside the > > code being tested specifically to avoid the temptation to leave > > untested/broken code in tree. > > True. However it's kinda subtle in this case: (1) this patch is not > really a feature, it just re-arranges the tree to allow faster search, > so the current tests passing should be enough. OTOH, the side-effect > is that it fixes directory iteration because different roots pointing > to the same path now can be seen as the same by directory iteration. I > had the intention to test that, to make sure we don't regress in the > future. (2) I have no other way to "debug" on windows10-ps4 platform > besides reducing-by-commit. Anyway, I'm gonna try a more minimal > testcase first. > > -- > Bruno Cardoso Lopes > http://www.brunocardoso.cc > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup
> I'm glad to help, but it makes me uneasy to have somebody working on a > filesystem abstraction that does not have ready access to test and debug > their changes across the major host platforms that LLVM supports (linux, > mac, windows). Is there any way you can get access? I don't think that > windows 10 is critical here; win7 or win8 are fine. I'm mostly trying to make the crash reproducers to work on Darwin; the improvements to VFS are in fact side-effects here, not something I'm working full time on. It would be awesome to have it working on other platforms out-of-the-box, but I just don't have the bandwidth to do it. That said, I'm gonna make sure we don't regress on windows, but unless I have help or get time to setup such machine, I can't guarantee this improvements are going to be supported on windows. -- Bruno Cardoso Lopes http://www.brunocardoso.cc ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup
On Wed, May 11, 2016 at 10:46 AM, Bruno Cardoso Lopes < bruno.card...@gmail.com> wrote: > > I'm glad to help, but it makes me uneasy to have somebody working on a > > filesystem abstraction that does not have ready access to test and debug > > their changes across the major host platforms that LLVM supports (linux, > > mac, windows). Is there any way you can get access? I don't think that > > windows 10 is critical here; win7 or win8 are fine. > > I'm mostly trying to make the crash reproducers to work on Darwin; What are the platform-specifics for crash reproducing? Shouldn't it basically be saving some files and storing some data for reconstructing? We've recently been working on a `--reproduce` for LLD and we haven't needed any ifdefs for windows (some tests that rely on really long path names need to be turned off, but the feature still works). -- Sean Silva > the > improvements to VFS are in fact side-effects here, not something I'm > working full time on. It would be awesome to have it working on other > platforms out-of-the-box, but I just don't have the bandwidth to do > it. That said, I'm gonna make sure we don't regress on windows, but > unless I have help or get time to setup such machine, I can't > guarantee this improvements are going to be supported on windows. > > -- > Bruno Cardoso Lopes > http://www.brunocardoso.cc > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup
> What are the platform-specifics for crash reproducing? Shouldn't it > basically be saving some files and storing some data for reconstructing? Feature-wise the crash reproducer for modules could "just" work for windows, there should not be anything platform-specific, I never tested it on windows though :-) Darwin requires lot of custom logic to handle frameworks, and those use recursive and normal directory iterators to scan inner frameworks; depending on the way we write the YAML file, the VFS wouldn't be able to correctly grab all subdirs / files, which this patch fixes. We don't collect everything because we don't want every reproducer to contain the whole SDK. > We've recently been working on a `--reproduce` for LLD and we haven't needed > any ifdefs for windows (some tests that rely on really long path names need > to be turned off, but the feature still works). The ifdefs are for realpath or related-to, which I mentioned previously should be abstracted properly soon. -- Bruno Cardoso Lopes http://www.brunocardoso.cc ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
