llvm dev - Nov 2017 - PSA: debuginfo-tests workflow changing slightly

Since this is causing all of our internal CI to back up, could you please revert
your two changes, so we can make sure that they were actually responsible, and
can work on a fix for this? Let me know how we can help investigate this.

-- adrian
> On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> The first build where a test fails with similar symptoms has just one
blamelist entry:
> 
> http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40391/
<http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40391/>
> 
> Update test_debuginfo.pl script to point to new tree location. (detail
<http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40391/changes#detail0>/ViewSVN
<http://llvm.org/viewvc/llvm-project/?view=rev&rev=317949>)
> by zturner <http://green.lab.llvm.org/green/user/zturner/>
> -- adrian
> 
>> On Nov 13, 2017, at 3:21 PM, Zachary Turner <zturner at google.com
<mailto:zturner at google.com>> wrote:
>> 
>> On the other hand this file hasn't changed recently, but I have no
way to test this as it uses the LLDB code path, which only runs on OSX.
>> 
>> On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <zturner at
google.com <mailto:zturner at google.com>> wrote:
>> I might be missing something, but this doesn't look like me?
>> 
>>
http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40478/consoleFull#-42777206a1ca8a51-895e-46c6-af87-ce24fa4cd561
<http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40478/consoleFull#-42777206a1ca8a51-895e-46c6-af87-ce24fa4cd561>
>> 
>> PASS: debuginfo-tests :: dbg-arg.c (34886 of 40729)
>> PASS: debuginfo-tests :: ctor.cpp (34887 of 40729)
>> PASS: debuginfo-tests :: ctor.cpp (34888 of 40729)
>> PASS: debuginfo-tests :: aggregate-indirect-arg.cpp (34889 of 40729)
>> PASS: debuginfo-tests :: aggregate-indirect-arg.cpp (34890 of 40729)
>> PASS: debuginfo-tests :: dbg-arg.c (34891 of 40729)
>> PASS: debuginfo-tests :: asan.c (34892 of 40729)
>> PASS: debuginfo-tests :: asan.c (34893 of 40729)
>> PASS: debuginfo-tests :: asan-blocks.c (34894 of 40729)
>> PASS: debuginfo-tests :: asan-blocks.c (34895 of 40729)
>> PASS: debuginfo-tests :: nested-struct.cpp (34896 of 40729)
>> PASS: debuginfo-tests :: nested-struct.cpp (34897 of 40729)
>> PASS: debuginfo-tests :: forward-declare-class.cpp (34898 of 40729)
>> PASS: debuginfo-tests :: forward-declare-class.cpp (34899 of 40729)
>> FAIL: debuginfo-tests :: foreach.m (34900 of 40729)
>>  <>******************** TEST 'debuginfo-tests ::
foreach.m' FAILED ********************
>> Script:
>> --
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/bin/clang
--target=x86_64-apple-darwin15.6.0 -O0 -g
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m
-c -o
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/bin/clang
--target=x86_64-apple-darwin15.6.0
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o
-o
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.out
-framework Foundation
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/test_debuginfo.pl
<http://test_debuginfo.pl/>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.out
>> --
>> Exit Code: 1
>> 
>> Command Output (stdout):
>> --
>> Debugger output was:
>> imported lldb from:
"/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Python"
>> error: foreach.m.tmp.out debug map object file
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o'
has changed (actual time is 0x5a0a2528, debug map time is 0x5a0a2526) since this
executable was linked, file will be ignored
>> >  break 25
>> SBBreakpoint: id = 1, file = '', line = 25, exact_match = 0,
locations = 0
>> >  r
>> success
>> >  po thing
>>  = <could not resolve type>
>> > quit
>> 
>> --
>> Command Output (stderr):
>> --
>> 
<>/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m:11:11:
error: expected string not found in input
>> // CHECK: aaa
>>           ^
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.gdb.output:1:1:
note: scanning from here
>> imported lldb from:
"/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Python"
>> ^
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.gdb.output:2:211:
note: possible intended match here
>> error: foreach.m.tmp.out debug map object file
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o'
has changed (actual time is 0x5a0a2528, debug map time is 0x5a0a2526) since this
executable was linked, file will be ignored
>> 
>> 
>> On Mon, Nov 13, 2017 at 3:17 PM Adrian Prantl <aprantl at apple.com
<mailto:aprantl at apple.com>> wrote:
>> It looks like the bots are still red?
>> 
>> — Adrian
>> 
>> 
>>> On Nov 10, 2017, at 3:14 PM, Zachary Turner <zturner at
google.com <mailto:zturner at google.com>> wrote:
>>> 
>>> Wasn't quite fixed, but it got a lot further this time.  This
time there was still an issue in the test_debuginfo.pl
<http://test_debuginfo.pl/> script regarding a hardcoded path to the
llgdb.py script.  I think I never encountered this locally because this codepath
only happens on Darwin, and I was testing on Linux.
>>> 
>>> (As an aside, ugh... Perl...)
>>> 
>>> Regardless, this should be fixed in r317949, and hopefully
that's the last of the issues.  I have to run for a couple of hours, but I
can check on this again in a bit.  But I strongly suspect it will be fixed now.
>>> 
>>> On Fri, Nov 10, 2017 at 2:51 PM Adrian Prantl <aprantl at
apple.com <mailto:aprantl at apple.com>> wrote:
>>> 
>>>> On Nov 10, 2017, at 2:50 PM, Zachary Turner <zturner at
google.com <mailto:zturner at google.com>> wrote:
>>>> 
>>>> I checked in a fix for that already, sorry for the trouble. I’m
waiting for it to cycle
>>> 
>>> awesome. Thanks!
>>> 
>>> -- adrian
>>> 
>>>> On Fri, Nov 10, 2017 at 2:49 PM Adrian Prantl <aprantl at
apple.com <mailto:aprantl at apple.com>> wrote:
>>>> It looks like this broke green dragon:
>>>> 
>>>>
http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40383/console
<http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40383/console>
>>>> 
>>>> llvm-lit:
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/projects/libcxx/utils/libcxx/test/config.py:173:
note: Adding environment variables: {'DYLD_LIBRARY_PATH':
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/./lib',
'LIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT':
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/projects/libcxx/test/filesystem/Output/dynamic_env'}
>>>> 
>>>> llvm-lit:
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/llvm/config.py:332:
note: using clang:
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/bin/clang
>>>> llvm-lit:
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/util.py:379:
note: using SDKROOT:
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk'
>>>> 
>>>> llvm-lit:
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/TestingConfig.py:101:
fatal: unable to parse config file
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/lit.cfg.py
<http://lit.cfg.py/>', traceback: Traceback (most recent call last):
>>>>   File
"/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/TestingConfig.py",
line 88, in load_from_path
>>>>     exec(compile(data, path, 'exec'), cfg_globals,
None)
>>>>   File
"/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/lit.cfg.py
<http://lit.cfg.py/>", line 36, in <module>
>>>>     config.test_source_root =
os.path.join(config.debuginfo_tests_src_root, 'tests')
>>>> AttributeError: TestingConfig instance has no attribute
'debuginfo_tests_src_root'
>>>> 
>>>> FAILED: CMakeFiles/check-all
>>>> 
>>>> -- adrian
>>>> 
>>>> > On Nov 10, 2017, at 1:00 PM, Zachary Turner via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>>> >
>>>> > This is in as of r317925.  I'm keeping an eye out for
failure notifications.  I may or may not need help diagnosing if something does
go wrong (although I'm keeping my fingers crossed)
>>>> >
>>>> > On Thu, Nov 9, 2017 at 4:05 PM Zachary Turner <zturner
at google.com <mailto:zturner at google.com>> wrote:
>>>> > Since it's towards the end of the day already,
I'll put this in tomorrow morning around 9 or 10, to make sure I'm
around to fix anything that arises (or revert).
>>>> >
>>>> >
>>>> >
>>>> > On Thu, Nov 9, 2017 at 2:53 PM Mike Edwards <medwards
at apple.com <mailto:medwards at apple.com>> wrote:
>>>> > Hi Zach,
>>>> > Thanks for doing this extra work to make this lower impact
for the rest of us.  Let’s give it a try and see what happens.
>>>> >
>>>> > -Mike
>>>> >
>>>> >
>>>> >
>>>> >> On Nov 9, 2017, at 13:37, Zachary Turner <zturner
at google.com <mailto:zturner at google.com>> wrote:
>>>> >>
>>>> >> Hi all, I think I've addressed all the concerns
here, and I believe there should be no immediate impact to the current workflow.
with that said, I plan to commit this either later today or early tomorrow if
there are no other concerns.
>>>> >>
>>>> >> On Tue, Nov 7, 2017 at 12:19 PM Zachary Turner
<zturner at google.com <mailto:zturner at google.com>> wrote:
>>>> >> I tested this out, and AFAICT nothing will change.  It
will continue to just work if you have it checked out under clang/tests. 
It's a bit hard to construct this configuration locally since it requires
moving some files around, and applying half of a CL here and half of a CL there.
But, AFAICT it works.
>>>> >>
>>>> >> I'm happy to send you some patches if you want to
try them locally and confirm.
>>>> >>
>>>> >> I'd like to print out a CMake warning if it
detects the tree under clang/test and just mention that the workflow is
deprecated.  Any objections?
>>>> >>
>>>> >> On Mon, Nov 6, 2017 at 1:49 PM Mike Edwards
<medwards at apple.com <mailto:medwards at apple.com>> wrote:
>>>> >> Thank you Zach.
>>>> >>
>>>> >>
>>>> >>> On Nov 6, 2017, at 13:37, Zachary Turner
<zturner at google.com <mailto:zturner at google.com>> wrote:
>>>> >>>
>>>> >>> I’m going to spend a little time seeing if i can
make the change invisible to the bots so they will continue to work as they do
today.  Will report back after I’ve explored that a bit
>>>> >>> On Mon, Nov 6, 2017 at 1:35 PM Mike Edwards
<medwards at apple.com <mailto:medwards at apple.com>> wrote:
>>>> >>>> I'm honestly not opposed to this idea.  It
just seems a shame to do this for purely logistical reasons if most people agree
that the "right" place for debuginfo-tests is outside of the clang
tree.
>>>> >>>
>>>> >>> I totally understand what you are saying here and
will just add that sometimes being part of a larger community means being
willing to do things, sometimes, not exactly the “right” way, due to logistical
reasons.  I am not opposed to what you would like to do, I’m just furrowing my
brow at the timeframe in which to do it.
>>>> >>>
>>>> >>>>
>>>> >>>> That said, I'd still like to hear from
ChrisM and MikeE about why it will take so long, because on the surface it seems
like a low-impact move.
>>>> >>>
>>>> >>> Past experience has taught me, anything I think is
going to be simple and quick to fix, rarely ever turns out that way.  While
there will be a significant amount of work to change the way our bots work here
at Apple, the work is not impossible to accomplish.  Given the choice, I would
of course prefer an approach such as Paulr has suggested.  The ability to run
things in parallel for a time provides for a much lower impact change on the
entire community.  I think this approach may also give us some time to decide
where the debuginfo-test should fit in the new mono-repo.  It would be a bummer
to do the work necessary to make this change, only to discover we would have to
do it differently in the not too distant future to accommodate the new
mono-repo.
>>>> >>>
>>>> >>>  Zach, I do not want to be a blocker here.  I just
want to make sure we have explored all of the options to make sure we are not
missing a lower impact approach.  I also want to make sure we are not doing
something that could wait until we migrate to the mono-repo next year.
>>>> >>>
>>>> >>> Thanks,
>>>> >>> Mike
>>>> >>
>>>> >
>>>> > _______________________________________________
>>>> > LLVM Developers mailing list
>>>> > llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>> 
>>> 
>> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171113/e22d747c/attachment.html>

Yea I'm preparing a revert right now.  Does it happen for you when you run
debuginfo-tests locally?

On Mon, Nov 13, 2017 at 3:28 PM Adrian Prantl <aprantl at apple.com>
wrote:
> Since this is causing all of our internal CI to back up, could you please
> revert your two changes, so we can make sure that they were actually
> responsible, and can work on a fix for this? Let me know how we can help
> investigate this.
>
> -- adrian
>
>
> On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> The first build where a test fails with similar symptoms has just one
> blamelist entry:
>
> http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40391/
>
>
>    1. Update test_debuginfo.pl script to point to new tree location. (
>    detail
>   
<http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40391/changes#detail0>
>    /ViewSVN
<http://llvm.org/viewvc/llvm-project/?view=rev&rev=317949>)
>    by zturner <http://green.lab.llvm.org/green/user/zturner/>
>
> -- adrian
>
> On Nov 13, 2017, at 3:21 PM, Zachary Turner <zturner at google.com>
wrote:
>
> On the other hand this file hasn't changed recently, but I have no way
to
> test this as it uses the LLDB code path, which only runs on OSX.
>
> On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <zturner at
google.com> wrote:
>
>> I might be missing something, but this doesn't look like me?
>>
>>
>>
http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40478/consoleFull#-42777206a1ca8a51-895e-46c6-af87-ce24fa4cd561
>>
>> PASS: debuginfo-tests :: dbg-arg.c (34886 of 40729) PASS:
debuginfo-tests
>> :: ctor.cpp (34887 of 40729) PASS: debuginfo-tests :: ctor.cpp (34888
of
>> 40729) PASS: debuginfo-tests :: aggregate-indirect-arg.cpp (34889 of
40729)
>> PASS: debuginfo-tests :: aggregate-indirect-arg.cpp (34890 of 40729)
PASS:
>> debuginfo-tests :: dbg-arg.c (34891 of 40729) PASS: debuginfo-tests ::
>> asan.c (34892 of 40729) PASS: debuginfo-tests :: asan.c (34893 of
40729)
>> PASS: debuginfo-tests :: asan-blocks.c (34894 of 40729) PASS:
>> debuginfo-tests :: asan-blocks.c (34895 of 40729) PASS: debuginfo-tests
::
>> nested-struct.cpp (34896 of 40729) PASS: debuginfo-tests ::
>> nested-struct.cpp (34897 of 40729) PASS: debuginfo-tests ::
>> forward-declare-class.cpp (34898 of 40729) PASS: debuginfo-tests ::
>> forward-declare-class.cpp (34899 of 40729) FAIL: debuginfo-tests ::
>> foreach.m (34900 of 40729) ******************** TEST
'debuginfo-tests ::
>> foreach.m' FAILED ******************** Script: --
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/bin/clang
>> --target=x86_64-apple-darwin15.6.0 -O0 -g
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m
>> -c -o
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/bin/clang
>> --target=x86_64-apple-darwin15.6.0
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o
>> -o
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.out
>> -framework Foundation
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/
>> test_debuginfo.pl
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.out
>> -- Exit Code: 1 Command Output (stdout): -- Debugger output was:
imported
>> lldb from:
>>
"/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Python"
>> error: foreach.m.tmp.out debug map object file
>>
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o'
>> has changed (actual time is 0x5a0a2528, debug map time is 0x5a0a2526)
since
>> this executable was linked, file will be ignored > break 25
SBBreakpoint:
>> id = 1, file = '', line = 25, exact_match = 0, locations = 0
> r success >
>> po thing = <could not resolve type> > quit -- Command Output
(stderr): --
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m:11:11:
>> error: expected string not found in input // CHECK: aaa ^
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.gdb.output:1:1:
>> note: scanning from here imported lldb from:
>>
"/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Python"
>> ^
>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.gdb.output:2:211:
>> note: possible intended match here error: foreach.m.tmp.out debug map
>> object file
>>
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o'
>> has changed (actual time is 0x5a0a2528, debug map time is 0x5a0a2526)
since
>> this executable was linked, file will be ignored
>>
>> On Mon, Nov 13, 2017 at 3:17 PM Adrian Prantl <aprantl at
apple.com> wrote:
>>
>>> It looks like the bots are still red?
>>>
>>> — Adrian
>>>
>>>
>>> On Nov 10, 2017, at 3:14 PM, Zachary Turner <zturner at
google.com> wrote:
>>>
>>> Wasn't quite fixed, but it got a lot further this time.  This
time there
>>> was still an issue in the test_debuginfo.pl script regarding a
>>> hardcoded path to the llgdb.py script.  I think I never encountered
this
>>> locally because this codepath only happens on Darwin, and I was
testing on
>>> Linux.
>>>
>>> (As an aside, ugh... Perl...)
>>>
>>> Regardless, this should be fixed in r317949, and hopefully
that's the
>>> last of the issues.  I have to run for a couple of hours, but I can
check
>>> on this again in a bit.  But I strongly suspect it will be fixed
now.
>>>
>>> On Fri, Nov 10, 2017 at 2:51 PM Adrian Prantl <aprantl at
apple.com> wrote:
>>>
>>>>
>>>> On Nov 10, 2017, at 2:50 PM, Zachary Turner <zturner at
google.com> wrote:
>>>>
>>>> I checked in a fix for that already, sorry for the trouble. I’m
waiting
>>>> for it to cycle
>>>>
>>>>
>>>> awesome. Thanks!
>>>>
>>>> -- adrian
>>>>
>>>> On Fri, Nov 10, 2017 at 2:49 PM Adrian Prantl <aprantl at
apple.com>
>>>> wrote:
>>>>
>>>>> It looks like this broke green dragon:
>>>>>
>>>>>
>>>>>
http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40383/console
>>>>>
>>>>> llvm-lit:
>>>>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/projects/libcxx/utils/libcxx/test/config.py:173:
>>>>> note: Adding environment variables:
{'DYLD_LIBRARY_PATH':
>>>>>
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/./lib',
>>>>> 'LIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT':
>>>>>
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/projects/libcxx/test/filesystem/Output/dynamic_env'}
>>>>>
>>>>> llvm-lit:
>>>>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/llvm/config.py:332:
>>>>> note: using clang:
>>>>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/bin/clang
>>>>> llvm-lit:
>>>>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/util.py:379:
>>>>> note: using SDKROOT:
>>>>>
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk'
>>>>>
>>>>> llvm-lit:
>>>>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/TestingConfig.py:101:
>>>>> fatal: unable to parse config file
>>>>>
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/
>>>>> lit.cfg.py', traceback: Traceback (most recent call
last):
>>>>>   File
>>>>>
"/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/TestingConfig.py",
>>>>> line 88, in load_from_path
>>>>>     exec(compile(data, path, 'exec'), cfg_globals,
None)
>>>>>   File
>>>>>
"/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/
>>>>> lit.cfg.py", line 36, in <module>
>>>>>     config.test_source_root >>>>>
os.path.join(config.debuginfo_tests_src_root, 'tests')
>>>>> AttributeError: TestingConfig instance has no attribute
>>>>> 'debuginfo_tests_src_root'
>>>>>
>>>>> FAILED: CMakeFiles/check-all
>>>>>
>>>>> -- adrian
>>>>>
>>>>> > On Nov 10, 2017, at 1:00 PM, Zachary Turner via
llvm-dev <
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>> >
>>>>> > This is in as of r317925.  I'm keeping an eye out
for failure
>>>>> notifications.  I may or may not need help diagnosing if
something does go
>>>>> wrong (although I'm keeping my fingers crossed)
>>>>> >
>>>>> > On Thu, Nov 9, 2017 at 4:05 PM Zachary Turner
<zturner at google.com>
>>>>> wrote:
>>>>> > Since it's towards the end of the day already,
I'll put this in
>>>>> tomorrow morning around 9 or 10, to make sure I'm
around to fix anything
>>>>> that arises (or revert).
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Thu, Nov 9, 2017 at 2:53 PM Mike Edwards
<medwards at apple.com>
>>>>> wrote:
>>>>> > Hi Zach,
>>>>> > Thanks for doing this extra work to make this lower
impact for the
>>>>> rest of us.  Let’s give it a try and see what happens.
>>>>> >
>>>>> > -Mike
>>>>> >
>>>>> >
>>>>> >
>>>>> >> On Nov 9, 2017, at 13:37, Zachary Turner
<zturner at google.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Hi all, I think I've addressed all the
concerns here, and I believe
>>>>> there should be no immediate impact to the current
workflow.  with that
>>>>> said, I plan to commit this either later today or early
tomorrow if there
>>>>> are no other concerns.
>>>>> >>
>>>>> >> On Tue, Nov 7, 2017 at 12:19 PM Zachary Turner
<zturner at google.com>
>>>>> wrote:
>>>>> >> I tested this out, and AFAICT nothing will change.
It will
>>>>> continue to just work if you have it checked out under
clang/tests.  It's a
>>>>> bit hard to construct this configuration locally since it
requires moving
>>>>> some files around, and applying half of a CL here and half
of a CL there.
>>>>> But, AFAICT it works.
>>>>> >>
>>>>> >> I'm happy to send you some patches if you want
to try them locally
>>>>> and confirm.
>>>>> >>
>>>>> >> I'd like to print out a CMake warning if it
detects the tree under
>>>>> clang/test and just mention that the workflow is
deprecated.  Any
>>>>> objections?
>>>>> >>
>>>>> >> On Mon, Nov 6, 2017 at 1:49 PM Mike Edwards
<medwards at apple.com>
>>>>> wrote:
>>>>> >> Thank you Zach.
>>>>> >>
>>>>> >>
>>>>> >>> On Nov 6, 2017, at 13:37, Zachary Turner
<zturner at google.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> I’m going to spend a little time seeing if i
can make the change
>>>>> invisible to the bots so they will continue to work as they
do today.  Will
>>>>> report back after I’ve explored that a bit
>>>>> >>> On Mon, Nov 6, 2017 at 1:35 PM Mike Edwards
<medwards at apple.com>
>>>>> wrote:
>>>>> >>>> I'm honestly not opposed to this idea.
It just seems a shame to
>>>>> do this for purely logistical reasons if most people agree
that the "right"
>>>>> place for debuginfo-tests is outside of the clang tree.
>>>>> >>>
>>>>> >>> I totally understand what you are saying here
and will just add
>>>>> that sometimes being part of a larger community means being
willing to do
>>>>> things, sometimes, not exactly the “right” way, due to
logistical reasons.
>>>>> I am not opposed to what you would like to do, I’m just
furrowing my brow
>>>>> at the timeframe in which to do it.
>>>>> >>>
>>>>> >>>>
>>>>> >>>> That said, I'd still like to hear from
ChrisM and MikeE about why
>>>>> it will take so long, because on the surface it seems like
a low-impact
>>>>> move.
>>>>> >>>
>>>>> >>> Past experience has taught me, anything I
think is going to be
>>>>> simple and quick to fix, rarely ever turns out that way. 
While there will
>>>>> be a significant amount of work to change the way our bots
work here at
>>>>> Apple, the work is not impossible to accomplish.  Given the
choice, I would
>>>>> of course prefer an approach such as Paulr has suggested. 
The ability to
>>>>> run things in parallel for a time provides for a much lower
impact change
>>>>> on the entire community.  I think this approach may also
give us some time
>>>>> to decide where the debuginfo-test should fit in the new
mono-repo.  It
>>>>> would be a bummer to do the work necessary to make this
change, only to
>>>>> discover we would have to do it differently in the not too
distant future
>>>>> to accommodate the new mono-repo.
>>>>> >>>
>>>>> >>>  Zach, I do not want to be a blocker here.  I
just want to make
>>>>> sure we have explored all of the options to make sure we
are not missing a
>>>>> lower impact approach.  I also want to make sure we are not
doing something
>>>>> that could wait until we migrate to the mono-repo next
year.
>>>>> >>>
>>>>> >>> Thanks,
>>>>> >>> Mike
>>>>> >>
>>>>> >
>>>>> > _______________________________________________
>>>>> > LLVM Developers mailing list
>>>>> > llvm-dev at lists.llvm.org
>>>>> >
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>>>
>>>>
>>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171113/195b0538/attachment-0001.html>

Yes I can reproduce this locally. It looks like we are not passing an -isysroot
(pointing to the SDK) to clang but it isn’t clear what lit magic would expand
this.

-- adrian
> On Nov 13, 2017, at 3:30 PM, Zachary Turner <zturner at google.com>
wrote:
> 
> Yea I'm preparing a revert right now.  Does it happen for you when you
run debuginfo-tests locally?
> 
> On Mon, Nov 13, 2017 at 3:28 PM Adrian Prantl <aprantl at apple.com
<mailto:aprantl at apple.com>> wrote:
> Since this is causing all of our internal CI to back up, could you please
revert your two changes, so we can make sure that they were actually
responsible, and can work on a fix for this? Let me know how we can help
investigate this.
> 
> -- adrian
> 
> 
>> On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> The first build where a test fails with similar symptoms has just one
blamelist entry:
>> 
>> http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40391/
<http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40391/>
>> 
>> Update test_debuginfo.pl <http://test_debuginfo.pl/> script to
point to new tree location. (detail
<http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40391/changes#detail0>/ViewSVN
<http://llvm.org/viewvc/llvm-project/?view=rev&rev=317949>)
>> by zturner <http://green.lab.llvm.org/green/user/zturner/>
>> -- adrian
>> 
>>> On Nov 13, 2017, at 3:21 PM, Zachary Turner <zturner at
google.com <mailto:zturner at google.com>> wrote:
>>> 
>>> On the other hand this file hasn't changed recently, but I have
no way to test this as it uses the LLDB code path, which only runs on OSX.
>>> 
>>> On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <zturner at
google.com <mailto:zturner at google.com>> wrote:
>>> I might be missing something, but this doesn't look like me?
>>> 
>>>
http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40478/consoleFull#-42777206a1ca8a51-895e-46c6-af87-ce24fa4cd561
<http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40478/consoleFull#-42777206a1ca8a51-895e-46c6-af87-ce24fa4cd561>
>>> 
>>> PASS: debuginfo-tests :: dbg-arg.c (34886 of 40729)
>>> PASS: debuginfo-tests :: ctor.cpp (34887 of 40729)
>>> PASS: debuginfo-tests :: ctor.cpp (34888 of 40729)
>>> PASS: debuginfo-tests :: aggregate-indirect-arg.cpp (34889 of
40729)
>>> PASS: debuginfo-tests :: aggregate-indirect-arg.cpp (34890 of
40729)
>>> PASS: debuginfo-tests :: dbg-arg.c (34891 of 40729)
>>> PASS: debuginfo-tests :: asan.c (34892 of 40729)
>>> PASS: debuginfo-tests :: asan.c (34893 of 40729)
>>> PASS: debuginfo-tests :: asan-blocks.c (34894 of 40729)
>>> PASS: debuginfo-tests :: asan-blocks.c (34895 of 40729)
>>> PASS: debuginfo-tests :: nested-struct.cpp (34896 of 40729)
>>> PASS: debuginfo-tests :: nested-struct.cpp (34897 of 40729)
>>> PASS: debuginfo-tests :: forward-declare-class.cpp (34898 of 40729)
>>> PASS: debuginfo-tests :: forward-declare-class.cpp (34899 of 40729)
>>> FAIL: debuginfo-tests :: foreach.m (34900 of 40729)
>>>  <>******************** TEST 'debuginfo-tests ::
foreach.m' FAILED ********************
>>> Script:
>>> --
>>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/bin/clang
--target=x86_64-apple-darwin15.6.0 -O0 -g
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m
-c -o
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o
>>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/bin/clang
--target=x86_64-apple-darwin15.6.0
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o
-o
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.out
-framework Foundation
>>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/test_debuginfo.pl
<http://test_debuginfo.pl/>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.out
>>> --
>>> Exit Code: 1
>>> 
>>> Command Output (stdout):
>>> --
>>> Debugger output was:
>>> imported lldb from:
"/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Python"
>>> error: foreach.m.tmp.out debug map object file
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o'
has changed (actual time is 0x5a0a2528, debug map time is 0x5a0a2526) since this
executable was linked, file will be ignored
>>> >  break 25
>>> SBBreakpoint: id = 1, file = '', line = 25, exact_match =
0, locations = 0
>>> >  r
>>> success
>>> >  po thing
>>>  = <could not resolve type>
>>> > quit
>>> 
>>> --
>>> Command Output (stderr):
>>> --
>>> 
<>/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m:11:11:
error: expected string not found in input
>>> // CHECK: aaa
>>>           ^
>>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.gdb.output:1:1:
note: scanning from here
>>> imported lldb from:
"/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Python"
>>> ^
>>>
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.gdb.output:2:211:
note: possible intended match here
>>> error: foreach.m.tmp.out debug map object file
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o'
has changed (actual time is 0x5a0a2528, debug map time is 0x5a0a2526) since this
executable was linked, file will be ignored
>>> 
>>> 
>>> On Mon, Nov 13, 2017 at 3:17 PM Adrian Prantl <aprantl at
apple.com <mailto:aprantl at apple.com>> wrote:
>>> It looks like the bots are still red?
>>> 
>>> — Adrian
>>> 
>>> 
>>>> On Nov 10, 2017, at 3:14 PM, Zachary Turner <zturner at
google.com <mailto:zturner at google.com>> wrote:
>>>> 
>>>> Wasn't quite fixed, but it got a lot further this time. 
This time there was still an issue in the test_debuginfo.pl
<http://test_debuginfo.pl/> script regarding a hardcoded path to the
llgdb.py script.  I think I never encountered this locally because this codepath
only happens on Darwin, and I was testing on Linux.
>>>> 
>>>> (As an aside, ugh... Perl...)
>>>> 
>>>> Regardless, this should be fixed in r317949, and hopefully
that's the last of the issues.  I have to run for a couple of hours, but I
can check on this again in a bit.  But I strongly suspect it will be fixed now.
>>>> 
>>>> On Fri, Nov 10, 2017 at 2:51 PM Adrian Prantl <aprantl at
apple.com <mailto:aprantl at apple.com>> wrote:
>>>> 
>>>>> On Nov 10, 2017, at 2:50 PM, Zachary Turner <zturner at
google.com <mailto:zturner at google.com>> wrote:
>>>>> 
>>>>> I checked in a fix for that already, sorry for the trouble.
I’m waiting for it to cycle
>>>> 
>>>> awesome. Thanks!
>>>> 
>>>> -- adrian
>>>> 
>>>>> On Fri, Nov 10, 2017 at 2:49 PM Adrian Prantl <aprantl
at apple.com <mailto:aprantl at apple.com>> wrote:
>>>>> It looks like this broke green dragon:
>>>>> 
>>>>>
http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40383/console
<http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40383/console>
>>>>> 
>>>>> llvm-lit:
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/projects/libcxx/utils/libcxx/test/config.py:173:
note: Adding environment variables: {'DYLD_LIBRARY_PATH':
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/./lib',
'LIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT':
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/projects/libcxx/test/filesystem/Output/dynamic_env'}
>>>>> 
>>>>> llvm-lit:
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/llvm/config.py:332:
note: using clang:
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/bin/clang
>>>>> llvm-lit:
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/util.py:379:
note: using SDKROOT:
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk'
>>>>> 
>>>>> llvm-lit:
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/TestingConfig.py:101:
fatal: unable to parse config file
'/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/lit.cfg.py
<http://lit.cfg.py/>', traceback: Traceback (most recent call last):
>>>>>   File
"/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/TestingConfig.py",
line 88, in load_from_path
>>>>>     exec(compile(data, path, 'exec'), cfg_globals,
None)
>>>>>   File
"/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/test/debuginfo-tests/lit.cfg.py
<http://lit.cfg.py/>", line 36, in <module>
>>>>>     config.test_source_root =
os.path.join(config.debuginfo_tests_src_root, 'tests')
>>>>> AttributeError: TestingConfig instance has no attribute
'debuginfo_tests_src_root'
>>>>> 
>>>>> FAILED: CMakeFiles/check-all
>>>>> 
>>>>> -- adrian
>>>>> 
>>>>> > On Nov 10, 2017, at 1:00 PM, Zachary Turner via
llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>>>> >
>>>>> > This is in as of r317925.  I'm keeping an eye out
for failure notifications.  I may or may not need help diagnosing if something
does go wrong (although I'm keeping my fingers crossed)
>>>>> >
>>>>> > On Thu, Nov 9, 2017 at 4:05 PM Zachary Turner
<zturner at google.com <mailto:zturner at google.com>> wrote:
>>>>> > Since it's towards the end of the day already,
I'll put this in tomorrow morning around 9 or 10, to make sure I'm
around to fix anything that arises (or revert).
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Thu, Nov 9, 2017 at 2:53 PM Mike Edwards
<medwards at apple.com <mailto:medwards at apple.com>> wrote:
>>>>> > Hi Zach,
>>>>> > Thanks for doing this extra work to make this lower
impact for the rest of us.  Let’s give it a try and see what happens.
>>>>> >
>>>>> > -Mike
>>>>> >
>>>>> >
>>>>> >
>>>>> >> On Nov 9, 2017, at 13:37, Zachary Turner
<zturner at google.com <mailto:zturner at google.com>> wrote:
>>>>> >>
>>>>> >> Hi all, I think I've addressed all the
concerns here, and I believe there should be no immediate impact to the current
workflow.  with that said, I plan to commit this either later today or early
tomorrow if there are no other concerns.
>>>>> >>
>>>>> >> On Tue, Nov 7, 2017 at 12:19 PM Zachary Turner
<zturner at google.com <mailto:zturner at google.com>> wrote:
>>>>> >> I tested this out, and AFAICT nothing will change.
It will continue to just work if you have it checked out under clang/tests. 
It's a bit hard to construct this configuration locally since it requires
moving some files around, and applying half of a CL here and half of a CL there.
But, AFAICT it works.
>>>>> >>
>>>>> >> I'm happy to send you some patches if you want
to try them locally and confirm.
>>>>> >>
>>>>> >> I'd like to print out a CMake warning if it
detects the tree under clang/test and just mention that the workflow is
deprecated.  Any objections?
>>>>> >>
>>>>> >> On Mon, Nov 6, 2017 at 1:49 PM Mike Edwards
<medwards at apple.com <mailto:medwards at apple.com>> wrote:
>>>>> >> Thank you Zach.
>>>>> >>
>>>>> >>
>>>>> >>> On Nov 6, 2017, at 13:37, Zachary Turner
<zturner at google.com <mailto:zturner at google.com>> wrote:
>>>>> >>>
>>>>> >>> I’m going to spend a little time seeing if i
can make the change invisible to the bots so they will continue to work as they
do today.  Will report back after I’ve explored that a bit
>>>>> >>> On Mon, Nov 6, 2017 at 1:35 PM Mike Edwards
<medwards at apple.com <mailto:medwards at apple.com>> wrote:
>>>>> >>>> I'm honestly not opposed to this idea.
It just seems a shame to do this for purely logistical reasons if most people
agree that the "right" place for debuginfo-tests is outside of the
clang tree.
>>>>> >>>
>>>>> >>> I totally understand what you are saying here
and will just add that sometimes being part of a larger community means being
willing to do things, sometimes, not exactly the “right” way, due to logistical
reasons.  I am not opposed to what you would like to do, I’m just furrowing my
brow at the timeframe in which to do it.
>>>>> >>>
>>>>> >>>>
>>>>> >>>> That said, I'd still like to hear from
ChrisM and MikeE about why it will take so long, because on the surface it seems
like a low-impact move.
>>>>> >>>
>>>>> >>> Past experience has taught me, anything I
think is going to be simple and quick to fix, rarely ever turns out that way. 
While there will be a significant amount of work to change the way our bots work
here at Apple, the work is not impossible to accomplish.  Given the choice, I
would of course prefer an approach such as Paulr has suggested.  The ability to
run things in parallel for a time provides for a much lower impact change on the
entire community.  I think this approach may also give us some time to decide
where the debuginfo-test should fit in the new mono-repo.  It would be a bummer
to do the work necessary to make this change, only to discover we would have to
do it differently in the not too distant future to accommodate the new
mono-repo.
>>>>> >>>
>>>>> >>>  Zach, I do not want to be a blocker here.  I
just want to make sure we have explored all of the options to make sure we are
not missing a lower impact approach.  I also want to make sure we are not doing
something that could wait until we migrate to the mono-repo next year.
>>>>> >>>
>>>>> >>> Thanks,
>>>>> >>> Mike
>>>>> >>
>>>>> >
>>>>> > _______________________________________________
>>>>> > LLVM Developers mailing list
>>>>> > llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>>> >
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>>> 
>>>> 
>>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171113/a06ed1cf/attachment.html>