[llvm-dev] PSA: debuginfo-tests workflow changing slightly

Zachary Turner via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 6 10:21:30 PST 2017


Can I have some assurance that if it fails again, someone will look into
who has access to the builders so I don't have to keep doing speculative
commits?

On Wed, Dec 6, 2017 at 10:13 AM Adrian Prantl <aprantl at apple.com> wrote:

>
> On Dec 6, 2017, at 10:10 AM, Zachary Turner <zturner at google.com> wrote:
>
> Adrian, Mike, Chris?  Any update on this?  I've temporarily switched to
> working on something different, but I plan to be back on this in a couple
> of weeks.  It's been a month since my first revert of this CL, which seems
> like a reasonable amount of lead-time to deal with issues surrounding
> downstream buildbot failures.  I'm planning to move forward with this in a
> couple of weeks once I finish up my current task, and I would really prefer
> to not be further blocked by downstream buildbot failures.
>
> Is there any way you can try Don's patch above on one of the failing
> machines?  Or proceed with your earlier solution of fixing up all the
> jenkins builders?
>
>
> When he has verified that they work locally on a Darwin machine, they
> should also work on the bots. We don't have any special configuration on
> those machines that isn't also visible in the Jenkins build log. I don't
> mind you committing the patch to verify that they work as long as you keep
> a close eye on the bots to ensure that they don't break and immediately
> revert if they do.
>
> -- adrian
>
>
> On Sat, Nov 25, 2017 at 3:46 PM Don Hinton <hintonda at gmail.com> wrote:
>
>> Hi Zachary:
>>
>> I was able to reproduce the greendragon results locally (OSX), and fix
>> the problem by excluding 'debuginfo-tests' from check-clang -- this
>> prevents them from being added twice, once for check-clang and again for
>> check-debuginfo.
>>
>> Below are the minimized patches I used to reproduce and fix the problem
>> -- based on your originals.
>>
>> I've verified these patches work when including debuginfo-tests in either
>> clang/test or llvm/projects.
>>
>> hth...
>> don
>>
>>
>> local:/Users/dhinton/projects/llvm_project/llvm/tools/clang $ git diff
>> master
>> diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
>> index c1ac9e4f0f..8c2db7600d 100644
>> --- a/test/CMakeLists.txt
>> +++ b/test/CMakeLists.txt
>> @@ -131,3 +131,7 @@ add_lit_testsuites(CLANG ${CMAKE_CURRENT_SOURCE_DIR}
>>  add_custom_target(clang-test)
>>  add_dependencies(clang-test check-clang)
>>  set_target_properties(clang-test PROPERTIES FOLDER "Clang tests")
>> +
>> +if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/debuginfo-tests/CMakeLists.txt")
>> +  add_subdirectory(debuginfo-tests)
>> +endif()
>> diff --git a/test/lit.cfg.py b/test/lit.cfg.py
>> index 39bdf36afd..5323cfe735 100644
>> --- a/test/lit.cfg.py
>> +++ b/test/lit.cfg.py
>> @@ -31,7 +31,7 @@ config.suffixes = ['.c', '.cpp', '.cppm', '.m', '.mm',
>> '.cu',
>>  # excludes: A list of directories to exclude from the testsuite. The
>> 'Inputs'
>>  # subdirectories contain auxiliary inputs for various tests in their
>> parent
>>  # directories.
>> -config.excludes = ['Inputs', 'CMakeLists.txt', 'README.txt',
>> 'LICENSE.txt']
>> +config.excludes = ['Inputs', 'CMakeLists.txt', 'README.txt',
>> 'LICENSE.txt', 'debuginfo-tests']
>>
>>  # test_source_root: The root path where tests are located.
>>  config.test_source_root = os.path.dirname(__file__)
>> @@ -58,8 +58,6 @@ tool_dirs = [config.clang_tools_dir,
>> config.llvm_tools_dir]
>>
>>  tools = [
>>      'c-index-test', 'clang-check', 'clang-diff', 'clang-format', 'opt',
>> -    ToolSubst('%test_debuginfo', command=os.path.join(
>> -        config.llvm_src_root, 'utils', 'test_debuginfo.pl')),
>>      ToolSubst('%clang_func_map', command=FindTool(
>>          'clang-func-mapping'), unresolved='ignore'),
>>  ]
>>
>>
>> local:/Users/dhinton/projects/llvm_project/debuginfo-tests $ git diff master
>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>> new file mode 100644
>> index 0000000..87260f1
>> --- /dev/null
>> +++ b/CMakeLists.txt
>> @@ -0,0 +1,26 @@
>> +# Debug Info tests.  These tests invoke clang to generate programs with
>> +# various types of debug info, and then run those programs under a debugger
>> +# such as GDB or LLDB to verify the results.
>> +
>> +set(DEBUGINFO_TESTS_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
>> +set(DEBUGINFO_TESTS_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
>> +
>> +set(DEBUGINFO_TEST_DEPS
>> +  clang
>> +  FileCheck
>> +  count
>> +  not
>> +  )
>> +
>> +configure_lit_site_cfg(
>> +  ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.py.in
>> +  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg.py
>> +  MAIN_CONFIG
>> +  ${CMAKE_CURRENT_SOURCE_DIR}/lit.cfg.py
>> +  )
>> +
>> +add_lit_testsuite(check-debuginfo "Running debug info integration tests"
>> +  ${CMAKE_CURRENT_BINARY_DIR}
>> +  DEPENDS ${DEBUGINFO_TEST_DEPS}
>> +  )
>> +set_target_properties(check-debuginfo PROPERTIES FOLDER "Debug info tests")
>> diff --git a/lit.cfg.py b/lit.cfg.py
>> new file mode 100644
>> index 0000000..ad65f46
>> --- /dev/null
>> +++ b/lit.cfg.py
>> @@ -0,0 +1,59 @@
>> +# -*- Python -*-
>> +
>> +import os
>> +import platform
>> +import re
>> +import subprocess
>> +import tempfile
>> +
>> +import lit.formats
>> +import lit.util
>> +
>> +from lit.llvm import llvm_config
>> +from lit.llvm.subst import ToolSubst
>> +from lit.llvm.subst import FindTool
>> +
>> +# Configuration file for the 'lit' test runner.
>> +
>> +# name: The name of this test suite.
>> +config.name = 'debuginfo-tests'
>> +
>> +# testFormat: The test format to use to interpret tests.
>> +#
>> +# For now we require '&&' between commands, until they get globally killed and
>> +# the test runner updated.
>> +config.test_format = lit.formats.ShTest(not llvm_config.use_lit_shell)
>> +
>> +# suffixes: A list of file extensions to treat as test files.
>> +config.suffixes = ['.c', '.cpp', '.m']
>> +
>> +# excludes: A list of directories to exclude from the testsuite. The 'Inputs'
>> +# subdirectories contain auxiliary inputs for various tests in their parent
>> +# directories.
>> +config.excludes = ['Inputs']
>> +
>> +# test_source_root: The root path where tests are located.
>> +config.test_source_root = os.path.join(config.debuginfo_tests_src_root)
>> +
>> +# test_exec_root: The root path where tests should be run.
>> +config.test_exec_root = config.debuginfo_tests_obj_root
>> +
>> +llvm_config.use_default_substitutions()
>> +
>> +llvm_config.use_clang()
>> +
>> +if config.llvm_use_sanitizer:
>> +    # Propagate path to symbolizer for ASan/MSan.
>> +    llvm_config.with_system_environment(
>> +        ['ASAN_SYMBOLIZER_PATH', 'MSAN_SYMBOLIZER_PATH'])
>> +
>> +tool_dirs = [config.llvm_tools_dir]
>> +
>> +tools = [
>> +    ToolSubst('%test_debuginfo', command=os.path.join(
>> +        config.debuginfo_tests_src_root, 'test_debuginfo.pl')),
>> +]
>> +
>> +llvm_config.add_tool_substitutions(tools, tool_dirs)
>> +
>> +lit.util.usePlatformSdkOnDarwin(config, lit_config)
>> diff --git a/lit.site.cfg.py.in b/lit.site.cfg.py.in
>> new file mode 100644
>> index 0000000..8c4481a
>> --- /dev/null
>> +++ b/lit.site.cfg.py.in
>> @@ -0,0 +1,25 @@
>> + at LIT_SITE_CFG_IN_HEADER@
>> +
>> +import lit.util
>> +
>> +config.test_exec_root = "@CMAKE_BINARY_DIR@"
>> +
>> +config.llvm_src_root = "@LLVM_SOURCE_DIR@"
>> +config.llvm_obj_root = "@LLVM_BINARY_DIR@"
>> +config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
>> +config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
>> +config.llvm_shlib_dir = "@SHLIBDIR@"
>> +config.llvm_plugin_ext = "@LLVM_PLUGIN_EXT@"
>> +config.debuginfo_tests_obj_root = "@DEBUGINFO_TESTS_BINARY_DIR@"
>> +config.debuginfo_tests_src_root = "@DEBUGINFO_TESTS_SOURCE_DIR@"
>> +config.has_lld = lit.util.pythonize_bool("@DEBUGINFO_TESTS_HAS_LLD@")
>> +config.host_triple = "@LLVM_HOST_TRIPLE@"
>> +config.target_triple = "@TARGET_TRIPLE@"
>> +config.host_arch = "@HOST_ARCH@"
>> +
>> +config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
>> +
>> + at LIT_SITE_CFG_IN_FOOTER@
>> +
>> +# Let the main config do the real work.
>> +lit_config.load_config(config, "@DEBUGINFO_TESTS_SOURCE_DIR@/lit.cfg.py")
>> diff --git a/test_debuginfo.pl b/test_debuginfo.pl
>> new file mode 100755
>> index 0000000..adc11c3
>> --- /dev/null
>> +++ b/test_debuginfo.pl
>> @@ -0,0 +1,80 @@
>> +#!/usr/bin/perl
>> +#
>> +# This script tests debugging information generated by a compiler.
>> +# Input arguments
>> +#   - Input source program. Usually this source file is decorated using
>> +#     special comments to communicate debugger commands.
>> +#   - Executable file. This file is generated by the compiler.
>> +#
>> +# This perl script extracts debugger commands from input source program
>> +# comments in a script. A debugger is used to load the executable file
>> +# and run the script generated from source program comments. Finally,
>> +# the debugger output is checked, using FileCheck, to validate
>> +# debugging information.
>> +#
>> +# On Darwin the default is to use the llgdb.py wrapper script which
>> +# translates gdb commands into their lldb equivalents.
>> +
>> +use File::Basename;
>> +use Config;
>> +use Cwd;
>> +
>> +my $testcase_file = $ARGV[0];
>> +my $executable_file = $ARGV[1];
>> +
>> +my $input_filename = basename $testcase_file;
>> +my $output_dir = dirname $executable_file;
>> +
>> +my $debugger_script_file = "$output_dir/$input_filename.debugger.script";
>> +my $output_file = "$output_dir/$input_filename.gdb.output";
>> +
>> +my %cmd_map = ();
>> +# Assume lldb to be the debugger on Darwin.
>> +my $use_lldb = 0;
>> +$use_lldb = 1 if ($Config{osname} eq "darwin");
>> +
>> +# Extract debugger commands from testcase. They are marked with DEBUGGER:
>> +# at the beginning of a comment line.
>> +open(INPUT, $testcase_file);
>> +open(OUTPUT, ">$debugger_script_file");
>> +while(<INPUT>) {
>> +    my($line) = $_;
>> +    $i = index($line, "DEBUGGER:");
>> +    if ( $i >= 0) {
>> +        $l = length("DEBUGGER:");
>> +        $s = substr($line, $i + $l);
>> +        print OUTPUT  "$s";
>> +    }
>> +}
>> +print OUTPUT "\n";
>> +print OUTPUT "quit\n";
>> +close(INPUT);
>> +close(OUTPUT);
>> +
>> +# setup debugger and debugger options to run a script.
>> +my $my_debugger = $ENV{'DEBUGGER'};
>> +if (!$my_debugger) {
>> +    if ($use_lldb) {
>> +        my $path = dirname(Cwd::abs_path($0));
>> +        $my_debugger = "/usr/bin/env python $path/llgdb.py";
>> +    } else {
>> +        $my_debugger = "gdb";
>> +    }
>> +}
>> +
>> +# quiet / exit after cmdline / no init file / execute script
>> +my $debugger_options = "-q -batch -n -x";
>> +
>> +# run debugger and capture output.
>> +system("$my_debugger $debugger_options $debugger_script_file $executable_file > $output_file 2>&1");
>> +
>> +# validate output.
>> +system("FileCheck", "-input-file", "$output_file", "$testcase_file");
>> +if ($?>>8 == 1) {
>> +    print "Debugger output was:\n";
>> +    system("cat", "$output_file");
>> +    exit 1;
>> +}
>> +else {
>> +    exit 0;
>> +}
>>
>>
>> local:/Users/dhinton/projects/llvm_project/llvm $ git diff master
>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>> index 8cd9d053c63..7d0fe05b511 100644
>> --- a/CMakeLists.txt
>> +++ b/CMakeLists.txt
>> @@ -110,7 +110,7 @@ endif()
>>  # LLVM_EXTERNAL_${project}_SOURCE_DIR using LLVM_ALL_PROJECTS
>>  # This allows an easy way of setting up a build directory for llvm and another
>>  # one for llvm+clang+... using the same sources.
>> -set(LLVM_ALL_PROJECTS "clang;libcxx;libcxxabi;lldb;compiler-rt;lld;polly")
>> +set(LLVM_ALL_PROJECTS "clang;libcxx;libcxxabi;lldb;compiler-rt;lld;polly,debuginfo-tests")
>>  set(LLVM_ENABLE_PROJECTS "" CACHE STRING
>>  	"Semicolon-separated list of projects to build (${LLVM_ALL_PROJECTS}), or \"all\".")
>>  if( LLVM_ENABLE_PROJECTS STREQUAL "all" )
>> @@ -885,13 +885,16 @@ if( LLVM_INCLUDE_EXAMPLES )
>>  endif()
>>
>>  if( LLVM_INCLUDE_TESTS )
>> -  if(EXISTS ${LLVM_MAIN_SRC_DIR}/projects/test-suite AND TARGET clang)
>> -    include(LLVMExternalProjectUtils)
>> -    llvm_ExternalProject_Add(test-suite ${LLVM_MAIN_SRC_DIR}/projects/test-suite
>> -      USE_TOOLCHAIN
>> -      EXCLUDE_FROM_ALL
>> -      NO_INSTALL
>> -      ALWAYS_CLEAN)
>> +  if(TARGET clang)
>> +    if(EXISTS ${LLVM_MAIN_SRC_DIR}/projects/test-suite)
>> +      include(LLVMExternalProjectUtils)
>> +      llvm_ExternalProject_Add(test-suite ${LLVM_MAIN_SRC_DIR}/projects/test-suite
>> +        USE_TOOLCHAIN
>> +        EXCLUDE_FROM_ALL
>> +        NO_INSTALL
>> +        ALWAYS_CLEAN)
>> +    endif()
>> +    add_llvm_external_project(debuginfo-tests projects/debuginfo-tests)
>>    endif()
>>    add_subdirectory(utils/lit)
>>    add_subdirectory(test)
>> diff --git a/projects/CMakeLists.txt b/projects/CMakeLists.txt
>> index 9102efbdcb4..11835fa89d2 100644
>> --- a/projects/CMakeLists.txt
>> +++ b/projects/CMakeLists.txt
>> @@ -10,6 +10,7 @@ foreach(entry ${entries})
>>         (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxxabi) AND
>>         (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libunwind) AND
>>         (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/test-suite) AND
>> +       (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/debuginfo-tests) AND
>>         (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/parallel-libs) AND
>>         (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/openmp))
>>        add_subdirectory(${entry})
>> diff --git a/utils/lit/lit/llvm/config.py b/utils/lit/lit/llvm/config.py
>> index c631f8b8865..c2e5c9ff141 100644
>> --- a/utils/lit/lit/llvm/config.py
>> +++ b/utils/lit/lit/llvm/config.py
>> @@ -413,8 +413,10 @@ class LLVMConfig(object):
>>              self.config.substitutions.append(
>>                  ('%target_itanium_abi_host_triple', ''))
>>
>> -        self.config.substitutions.append(
>> -            ('%src_include_dir', self.config.clang_src_dir + '/include'))
>> +        clang_src_dir = getattr(self.config, 'clang_src_dir', None)
>> +        if clang_src_dir:
>> +            self.config.substitutions.append(
>> +                ('%src_include_dir', os.path.join(clang_src_dir, 'include')))
>>
>>          # FIXME: Find nicer way to prohibit this.
>>          self.config.substitutions.append(
>> diff --git a/utils/test_debuginfo.pl b/utils/test_debuginfo.pl
>> deleted file mode 100755
>> index aaf90d95468..00000000000
>> --- a/utils/test_debuginfo.pl
>> +++ /dev/null
>> @@ -1,80 +0,0 @@
>> -#!/usr/bin/perl
>> -#
>> -# This script tests debugging information generated by a compiler.
>> -# Input arguments
>> -#   - Input source program. Usually this source file is decorated using
>> -#     special comments to communicate debugger commands.
>> -#   - Executable file. This file is generated by the compiler.
>> -#
>> -# This perl script extracts debugger commands from input source program
>> -# comments in a script. A debugger is used to load the executable file
>> -# and run the script generated from source program comments. Finally,
>> -# the debugger output is checked, using FileCheck, to validate
>> -# debugging information.
>> -#
>> -# On Darwin the default is to use the llgdb.py wrapper script which
>> -# translates gdb commands into their lldb equivalents.
>> -
>> -use File::Basename;
>> -use Config;
>> -use Cwd;
>> -
>> -my $testcase_file = $ARGV[0];
>> -my $executable_file = $ARGV[1];
>> -
>> -my $input_filename = basename $testcase_file;
>> -my $output_dir = dirname $executable_file;
>> -
>> -my $debugger_script_file = "$output_dir/$input_filename.debugger.script";
>> -my $output_file = "$output_dir/$input_filename.gdb.output";
>> -
>> -my %cmd_map = ();
>> -# Assume lldb to be the debugger on Darwin.
>> -my $use_lldb = 0;
>> -$use_lldb = 1 if ($Config{osname} eq "darwin");
>> -
>> -# Extract debugger commands from testcase. They are marked with DEBUGGER:
>> -# at the beginning of a comment line.
>> -open(INPUT, $testcase_file);
>> -open(OUTPUT, ">$debugger_script_file");
>> -while(<INPUT>) {
>> -    my($line) = $_;
>> -    $i = index($line, "DEBUGGER:");
>> -    if ( $i >= 0) {
>> -        $l = length("DEBUGGER:");
>> -        $s = substr($line, $i + $l);
>> -        print OUTPUT  "$s";
>> -    }
>> -}
>> -print OUTPUT "\n";
>> -print OUTPUT "quit\n";
>> -close(INPUT);
>> -close(OUTPUT);
>> -
>> -# setup debugger and debugger options to run a script.
>> -my $my_debugger = $ENV{'DEBUGGER'};
>> -if (!$my_debugger) {
>> -    if ($use_lldb) {
>> -        my $path = dirname(Cwd::abs_path($0));
>> -        $my_debugger = "/usr/bin/env python $path/../tools/clang/test/debuginfo-tests/llgdb.py";
>> -    } else {
>> -        $my_debugger = "gdb";
>> -    }
>> -}
>> -
>> -# quiet / exit after cmdline / no init file / execute script
>> -my $debugger_options = "-q -batch -n -x";
>> -
>> -# run debugger and capture output.
>> -system("$my_debugger $debugger_options $debugger_script_file $executable_file > $output_file 2>&1");
>> -
>> -# validate output.
>> -system("FileCheck", "-input-file", "$output_file", "$testcase_file");
>> -if ($?>>8 == 1) {
>> -    print "Debugger output was:\n";
>> -    system("cat", "$output_file");
>> -    exit 1;
>> -}
>> -else {
>> -    exit 0;
>> -}
>>
>>
>>
>> On Tue, Nov 21, 2017 at 9:29 PM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>> Definitely welcome to look into it, but unless you have physical access
>>> to one of these buildbots, I don't think we should commit anything else
>>> speculatively without having someone who does have physical access first
>>> confirm it.
>>>
>>> On Tue, Nov 21, 2017 at 7:25 PM Don Hinton <hintonda at gmail.com> wrote:
>>>
>>>> I sorta enjoy debugging stuff like this, so if you don't mind, I'll dig
>>>> into it once I get a chance -- traveling so, my access is a bit sketchy
>>>> right now.
>>>>
>>>> I'll see if I can grab the logs and let you know if I find anything
>>>> interesting.
>>>>
>>>> On Tue, Nov 21, 2017 at 7:04 PM, Zachary Turner <zturner at google.com>
>>>> wrote:
>>>>
>>>>> That change was added specifically to workaround a failure in a
>>>>> previous version of the commit.  I think as chandler says it's pretty much
>>>>> impossible for me to make any progress unless someone whose build bot is
>>>>> failing actually sits down, applies the patch, makes it work, and then
>>>>> sends me back the result.
>>>>>
>>>>> On Tue, Nov 21, 2017 at 7:03 PM Don Hinton <hintonda at gmail.com> wrote:
>>>>>
>>>>>> Hi Zackary,
>>>>>>
>>>>>> Did you see my followup to you cfe-commits rollback:
>>>>>>
>>>>>>
>>>>>> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171120/210212.html
>>>>>>
>>>>>> I think you can just remove the change to cfe/trunk/test/CMakeLists.txt
>>>>>> and it should work just fine.
>>>>>>
>>>>>> hth...
>>>>>> don
>>>>>>
>>>>>> On Tue, Nov 21, 2017 at 12:00 PM Zachary Turner via llvm-dev <
>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>
>>>>>>> Just an update,
>>>>>>>
>>>>>>> At this point I've submitted and reverted this probably 6+ times,
>>>>>>> and I don't have time to be blocked by this anymore.
>>>>>>>
>>>>>>> I'm looking into alternatives for now, including ways of creating a
>>>>>>> new top-level git repo such as
>>>>>>> https://git.llvm.org/git/codeview-tests.git/.
>>>>>>>
>>>>>>> I wish there were another way, but at this point I've been working
>>>>>>> on appeasing this for close to 2 months and I need some control over the
>>>>>>> bits that determine whether I'm able to make forward progress.
>>>>>>>
>>>>>>> If and when someone on the Apple side has some time to make this
>>>>>>> work with their build infrastructure, I will be happy to revisit.
>>>>>>>
>>>>>>> On Mon, Nov 13, 2017 at 4:44 PM Zachary Turner <zturner at google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Great!  It's close to the end of the day, so I'll submit tomorrow
>>>>>>>> to make sure everything has a chance to go fully green again to ensure I
>>>>>>>> get failure emails if it breaks.
>>>>>>>>
>>>>>>>> On Mon, Nov 13, 2017 at 4:43 PM Adrian Prantl <aprantl at apple.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I can confirm that that fixes the issue!
>>>>>>>>>
>>>>>>>>> — adrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Nov 13, 2017, at 4:38 PM, Zachary Turner <zturner at google.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Yea I also just found it.  Try adding this code in the bottom of
>>>>>>>>> debuginfo-tests/lit.cfg.py
>>>>>>>>>
>>>>>>>>> lit.util.usePlatformSdkOnDarwin(config, lit_config)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Nov 13, 2017 at 4:38 PM Adrian Prantl <aprantl at apple.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Ha! Found it. *Somebody* is setting an SDKROOT variable in the
>>>>>>>>>> environment. Can you find the code that would do this?
>>>>>>>>>>
>>>>>>>>>> — adrian
>>>>>>>>>>
>>>>>>>>>> > On Nov 13, 2017, at 4:30 PM, Adrian Prantl via llvm-dev <
>>>>>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>>>>> >
>>>>>>>>>> > 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> 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/
>>>>>>>>>> >>>
>>>>>>>>>> >>>     • Update test_debuginfo.pl script to point to new tree
>>>>>>>>>> location. (detail/ViewSVN)
>>>>>>>>>> >>> by 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
>>>>>>>>>> >>
>>>>>>>>>> >
>>>>>>>>>> > _______________________________________________
>>>>>>>>>> > 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/20171206/aee9bedd/attachment-0001.html>


More information about the llvm-dev mailing list