On Mon, Oct 3, 2016 at 5:24 PM, Xinliang David Li <xinliangli at gmail.com> wrote:> Small repro: > > __attribute__((weak)) int hello_world(); > > int test() { > if (hello_world) > return hello_world(); > return 0; > } > > $ clang -fuse-ld=gold -flto=thin -O2 -shared -fPIC -o libmore.so more.c > $ objdump -t libmore.so |grep hello > 0000000000000000 w *UND* 0000000000000000 hello_world > > $ clang -fuse-ld=bfd -flto=thin -O2 -shared -fPIC -o libmore.so more.c > $ objdump -t libmore.so |grep hello > 0000000000000000 *UND* 0000000000000000 hello_world >Same issue reproduces with just -flto (not just -flto=thin). So this is a general issue with ld.bfd interactions with LLVMgold.so.> > On Mon, Oct 3, 2016 at 4:40 PM, Teresa Johnson <tejohnson at google.com> > wrote: > >> >> >> On Mon, Oct 3, 2016 at 3:53 PM, Xinliang David Li <xinliangli at gmail.com> >> wrote: >> >>> What is the linker command line buidling liblldb.so? is libgcc.a passed >>> in? >>> >> >> There is no difference in the linker command for liblldb.so or bin/lldb >> between the ld.bfd and ld.gold cases, and neither links libgcc.a that I can >> see. >> >> The difference appears to be that the __morestack symbol is weak in the >> ld.gold liblldb.so case (and simply doesn't appear in the resulting >> bin/lldb presumably because libgcc.a is not linked): >> >> $ nm lib/liblldb.so.3.9.1 | grep morestack >> w __morestack >> >> whereas it is an undef in the ld.bfd case: >> >> $ nm lib/liblldb.so | grep morestack >> U __morestack >> >> resulting in the failure linking bin/lldb in that case. >> >> >>> David >>> >>> On Mon, Oct 3, 2016 at 3:52 PM, Xinliang David Li <xinliangli at gmail.com> >>> wrote: >>> >>>> In uint64_t >>>> RTDyldMemoryManager::getSymbolAddressInProcess(const std::string >>>> &Name) { >>>> >>>> there is reference to morestack: >>>> >>>> >>>> >>>> #if defined(__i386__) || defined(__x86_64__) >>>> // __morestack lives in libgcc, a static library. >>>> if (&__morestack && Name == "__morestack") >>>> return (uint64_t)&__morestack; >>>> #endif >>>> #endif // __linux__ && __GLIBC__ >>>> >>>> >>>> On Mon, Oct 3, 2016 at 3:32 PM, Teresa Johnson <tejohnson at google.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Oct 3, 2016 at 2:59 PM, Xinliang David Li < >>>>> xinliangli at gmail.com> wrote: >>>>> >>>>>> Is -fsplit-stack option used anywhere? My wild guess is that with >>>>>> ld.bfd, the thinLTO link for the DSO does not bring in morestack.o from >>>>>> libgcc.a, but the hidden symbol is defined in lldb binary. >>>>>> >>>>> >>>>> AFAICT, no - I had done "ninja -v" so I have all of the intermediate >>>>> build commands, and it doesn't show up in that. >>>>> >>>>> I'll have to do some more digging to figure out why it is referenced >>>>> from liblldb.so in the ld.bfd case and not when using ld.gold >>>>> >>>>> Teresa >>>>> >>>>> David >>>>>> >>>>>> On Mon, Oct 3, 2016 at 1:54 PM, Teresa Johnson via llvm-dev < >>>>>> llvm-dev at lists.llvm.org> wrote: >>>>>> >>>>>>> Aha - finally reproduced! The difference is using ld.bfd not >>>>>>> ld.gold. With that I get the same failure (using 3.9 to build 3.9 sources): >>>>>>> >>>>>>> /usr/local/google/home/tejohnson/binutils_build/install/bin/ld: >>>>>>> bin/lldb-3.9.1: hidden symbol `__morestack' in >>>>>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a(morestack.o) is >>>>>>> referenced by DSO >>>>>>> /usr/local/google/home/tejohnson/binutils_build/install/bin/ld: >>>>>>> final link failed: Bad value >>>>>>> clang-3.9: error: linker command failed with exit code 1 (use -v to >>>>>>> see invocation) >>>>>>> ninja: build stopped: subcommand failed. >>>>>>> >>>>>>> I am not sure what the official support story is for LLVMgold.so and >>>>>>> ld.bfd. As mentioned earlier, the LLVM site indicates it should use the >>>>>>> gold linker. Can you use that while I try to figure out whether this is >>>>>>> something that should be supported/working? >>>>>>> >>>>>>> Thanks, >>>>>>> Teresa >>>>>>> >>>>>>> On Mon, Oct 3, 2016 at 9:56 AM, Carsten Mattner < >>>>>>> carstenmattner at gmail.com> wrote: >>>>>>> >>>>>>>> On Mon, Oct 3, 2016 at 3:50 PM, Teresa Johnson < >>>>>>>> tejohnson at google.com> wrote: >>>>>>>> > >>>>>>>> > On Sun, Oct 2, 2016 at 4:02 AM, Carsten Mattner < >>>>>>>> carstenmattner at gmail.com> wrote: >>>>>>>> >> >>>>>>>> >> On Sun, Oct 2, 2016 at 6:41 AM, Teresa Johnson < >>>>>>>> tejohnson at google.com> wrote: >>>>>>>> > > >>>>>>>> > > > I use trunk, but it depends on how close to the bleeding edge >>>>>>>> you >>>>>>>> > > > are comfortable with. But like I said, I also tried >>>>>>>> bootstrapping >>>>>>>> > > > with 3.9 (both trunk as well as 3.9 sources) and couldn't >>>>>>>> reproduce. >>>>>>>> >> >>>>>>>> >> Hmm, so you're saying neither fails for you, right? >>>>>>>> > >>>>>>>> > Yes >>>>>>>> >>>>>>>> Okay. Do you mind focusing on the 3.9 branch? It's less of a moving >>>>>>>> target >>>>>>>> and lends itself more to figuring out what's failing for me. >>>>>>>> >>>>>>>> As soon as I get around to it, I'll send you my full configure and >>>>>>>> build >>>>>>>> steps as a shell script. Need to streamline it. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Teresa Johnson | Software Engineer | tejohnson at google.com | >>>>>>> 408-460-2413 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> LLVM Developers mailing list >>>>>>> llvm-dev at lists.llvm.org >>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Teresa Johnson | Software Engineer | tejohnson at google.com | >>>>> 408-460-2413 >>>>> >>>> >>>> >>> >> >> >> -- >> Teresa Johnson | Software Engineer | tejohnson at google.com | >> 408-460-2413 >> > >-- Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161003/97226507/attachment.html>
On Mon, Oct 3, 2016 at 6:15 PM, Teresa Johnson <tejohnson at google.com> wrote:> > > On Mon, Oct 3, 2016 at 5:24 PM, Xinliang David Li <xinliangli at gmail.com> > wrote: > >> Small repro: >> >> __attribute__((weak)) int hello_world(); >> >> int test() { >> if (hello_world) >> return hello_world(); >> return 0; >> } >> >> $ clang -fuse-ld=gold -flto=thin -O2 -shared -fPIC -o libmore.so more.c >> $ objdump -t libmore.so |grep hello >> 0000000000000000 w *UND* 0000000000000000 hello_world >> >> $ clang -fuse-ld=bfd -flto=thin -O2 -shared -fPIC -o libmore.so more.c >> $ objdump -t libmore.so |grep hello >> 0000000000000000 *UND* 0000000000000000 hello_world >> > > Same issue reproduces with just -flto (not just -flto=thin). So this is a > general issue with ld.bfd interactions with LLVMgold.so. >Oddly, if I do -Wl,-plugin-opt,save-temps, all of the temps files saved in both cases are exactly the same, including the native object file (which has a weak hello_world). So it is not that we are getting different input from ld.bfd, but rather that it is treating the returned object differently. And if I use the same command as above but replace the IR object with the saved native object, ld.bfd behaves correctly (the final .so has a weak symbol). I'm going to start a different thread about gold-plugin and ld.bfd interactions. Carsten, let me know if you are able to get ld.gold used for your build, as mentioned that is the better tested linker for LLVMgold.so. Thanks, Teresa> >> >> On Mon, Oct 3, 2016 at 4:40 PM, Teresa Johnson <tejohnson at google.com> >> wrote: >> >>> >>> >>> On Mon, Oct 3, 2016 at 3:53 PM, Xinliang David Li <xinliangli at gmail.com> >>> wrote: >>> >>>> What is the linker command line buidling liblldb.so? is libgcc.a passed >>>> in? >>>> >>> >>> There is no difference in the linker command for liblldb.so or bin/lldb >>> between the ld.bfd and ld.gold cases, and neither links libgcc.a that I can >>> see. >>> >>> The difference appears to be that the __morestack symbol is weak in the >>> ld.gold liblldb.so case (and simply doesn't appear in the resulting >>> bin/lldb presumably because libgcc.a is not linked): >>> >>> $ nm lib/liblldb.so.3.9.1 | grep morestack >>> w __morestack >>> >>> whereas it is an undef in the ld.bfd case: >>> >>> $ nm lib/liblldb.so | grep morestack >>> U __morestack >>> >>> resulting in the failure linking bin/lldb in that case. >>> >>> >>>> David >>>> >>>> On Mon, Oct 3, 2016 at 3:52 PM, Xinliang David Li <xinliangli at gmail.com >>>> > wrote: >>>> >>>>> In uint64_t >>>>> RTDyldMemoryManager::getSymbolAddressInProcess(const std::string >>>>> &Name) { >>>>> >>>>> there is reference to morestack: >>>>> >>>>> >>>>> >>>>> #if defined(__i386__) || defined(__x86_64__) >>>>> // __morestack lives in libgcc, a static library. >>>>> if (&__morestack && Name == "__morestack") >>>>> return (uint64_t)&__morestack; >>>>> #endif >>>>> #endif // __linux__ && __GLIBC__ >>>>> >>>>> >>>>> On Mon, Oct 3, 2016 at 3:32 PM, Teresa Johnson <tejohnson at google.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Oct 3, 2016 at 2:59 PM, Xinliang David Li < >>>>>> xinliangli at gmail.com> wrote: >>>>>> >>>>>>> Is -fsplit-stack option used anywhere? My wild guess is that with >>>>>>> ld.bfd, the thinLTO link for the DSO does not bring in morestack.o from >>>>>>> libgcc.a, but the hidden symbol is defined in lldb binary. >>>>>>> >>>>>> >>>>>> AFAICT, no - I had done "ninja -v" so I have all of the intermediate >>>>>> build commands, and it doesn't show up in that. >>>>>> >>>>>> I'll have to do some more digging to figure out why it is referenced >>>>>> from liblldb.so in the ld.bfd case and not when using ld.gold >>>>>> >>>>>> Teresa >>>>>> >>>>>> David >>>>>>> >>>>>>> On Mon, Oct 3, 2016 at 1:54 PM, Teresa Johnson via llvm-dev < >>>>>>> llvm-dev at lists.llvm.org> wrote: >>>>>>> >>>>>>>> Aha - finally reproduced! The difference is using ld.bfd not >>>>>>>> ld.gold. With that I get the same failure (using 3.9 to build 3.9 sources): >>>>>>>> >>>>>>>> /usr/local/google/home/tejohnson/binutils_build/install/bin/ld: >>>>>>>> bin/lldb-3.9.1: hidden symbol `__morestack' in >>>>>>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a(morestack.o) is >>>>>>>> referenced by DSO >>>>>>>> /usr/local/google/home/tejohnson/binutils_build/install/bin/ld: >>>>>>>> final link failed: Bad value >>>>>>>> clang-3.9: error: linker command failed with exit code 1 (use -v to >>>>>>>> see invocation) >>>>>>>> ninja: build stopped: subcommand failed. >>>>>>>> >>>>>>>> I am not sure what the official support story is for LLVMgold.so >>>>>>>> and ld.bfd. As mentioned earlier, the LLVM site indicates it should use the >>>>>>>> gold linker. Can you use that while I try to figure out whether this is >>>>>>>> something that should be supported/working? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Teresa >>>>>>>> >>>>>>>> On Mon, Oct 3, 2016 at 9:56 AM, Carsten Mattner < >>>>>>>> carstenmattner at gmail.com> wrote: >>>>>>>> >>>>>>>>> On Mon, Oct 3, 2016 at 3:50 PM, Teresa Johnson < >>>>>>>>> tejohnson at google.com> wrote: >>>>>>>>> > >>>>>>>>> > On Sun, Oct 2, 2016 at 4:02 AM, Carsten Mattner < >>>>>>>>> carstenmattner at gmail.com> wrote: >>>>>>>>> >> >>>>>>>>> >> On Sun, Oct 2, 2016 at 6:41 AM, Teresa Johnson < >>>>>>>>> tejohnson at google.com> wrote: >>>>>>>>> > > >>>>>>>>> > > > I use trunk, but it depends on how close to the bleeding >>>>>>>>> edge you >>>>>>>>> > > > are comfortable with. But like I said, I also tried >>>>>>>>> bootstrapping >>>>>>>>> > > > with 3.9 (both trunk as well as 3.9 sources) and couldn't >>>>>>>>> reproduce. >>>>>>>>> >> >>>>>>>>> >> Hmm, so you're saying neither fails for you, right? >>>>>>>>> > >>>>>>>>> > Yes >>>>>>>>> >>>>>>>>> Okay. Do you mind focusing on the 3.9 branch? It's less of a >>>>>>>>> moving target >>>>>>>>> and lends itself more to figuring out what's failing for me. >>>>>>>>> >>>>>>>>> As soon as I get around to it, I'll send you my full configure and >>>>>>>>> build >>>>>>>>> steps as a shell script. Need to streamline it. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Teresa Johnson | Software Engineer | tejohnson at google.com | >>>>>>>> 408-460-2413 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> LLVM Developers mailing list >>>>>>>> llvm-dev at lists.llvm.org >>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Teresa Johnson | Software Engineer | tejohnson at google.com | >>>>>> 408-460-2413 >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Teresa Johnson | Software Engineer | tejohnson at google.com | >>> 408-460-2413 >>> >> >> > > > -- > Teresa Johnson | Software Engineer | tejohnson at google.com | > 408-460-2413 >-- Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161004/d3c452c5/attachment-0001.html>
GCC LTO works ok for the test case with both bfd and gold linker. David On Tue, Oct 4, 2016 at 6:58 AM, Teresa Johnson <tejohnson at google.com> wrote:> > > On Mon, Oct 3, 2016 at 6:15 PM, Teresa Johnson <tejohnson at google.com> > wrote: > >> >> >> On Mon, Oct 3, 2016 at 5:24 PM, Xinliang David Li <xinliangli at gmail.com> >> wrote: >> >>> Small repro: >>> >>> __attribute__((weak)) int hello_world(); >>> >>> int test() { >>> if (hello_world) >>> return hello_world(); >>> return 0; >>> } >>> >>> $ clang -fuse-ld=gold -flto=thin -O2 -shared -fPIC -o libmore.so more.c >>> $ objdump -t libmore.so |grep hello >>> 0000000000000000 w *UND* 0000000000000000 hello_world >>> >>> $ clang -fuse-ld=bfd -flto=thin -O2 -shared -fPIC -o libmore.so more.c >>> $ objdump -t libmore.so |grep hello >>> 0000000000000000 *UND* 0000000000000000 hello_world >>> >> >> Same issue reproduces with just -flto (not just -flto=thin). So this is a >> general issue with ld.bfd interactions with LLVMgold.so. >> > > Oddly, if I do -Wl,-plugin-opt,save-temps, all of the temps files saved in > both cases are exactly the same, including the native object file (which > has a weak hello_world). So it is not that we are getting different input > from ld.bfd, but rather that it is treating the returned object > differently. And if I use the same command as above but replace the IR > object with the saved native object, ld.bfd behaves correctly (the final > .so has a weak symbol). > > I'm going to start a different thread about gold-plugin and ld.bfd > interactions. > > Carsten, let me know if you are able to get ld.gold used for your build, > as mentioned that is the better tested linker for LLVMgold.so. > > Thanks, > Teresa > > >> >>> >>> On Mon, Oct 3, 2016 at 4:40 PM, Teresa Johnson <tejohnson at google.com> >>> wrote: >>> >>>> >>>> >>>> On Mon, Oct 3, 2016 at 3:53 PM, Xinliang David Li <xinliangli at gmail.com >>>> > wrote: >>>> >>>>> What is the linker command line buidling liblldb.so? is libgcc.a >>>>> passed in? >>>>> >>>> >>>> There is no difference in the linker command for liblldb.so or bin/lldb >>>> between the ld.bfd and ld.gold cases, and neither links libgcc.a that I can >>>> see. >>>> >>>> The difference appears to be that the __morestack symbol is weak in the >>>> ld.gold liblldb.so case (and simply doesn't appear in the resulting >>>> bin/lldb presumably because libgcc.a is not linked): >>>> >>>> $ nm lib/liblldb.so.3.9.1 | grep morestack >>>> w __morestack >>>> >>>> whereas it is an undef in the ld.bfd case: >>>> >>>> $ nm lib/liblldb.so | grep morestack >>>> U __morestack >>>> >>>> resulting in the failure linking bin/lldb in that case. >>>> >>>> >>>>> David >>>>> >>>>> On Mon, Oct 3, 2016 at 3:52 PM, Xinliang David Li < >>>>> xinliangli at gmail.com> wrote: >>>>> >>>>>> In uint64_t >>>>>> RTDyldMemoryManager::getSymbolAddressInProcess(const std::string >>>>>> &Name) { >>>>>> >>>>>> there is reference to morestack: >>>>>> >>>>>> >>>>>> >>>>>> #if defined(__i386__) || defined(__x86_64__) >>>>>> // __morestack lives in libgcc, a static library. >>>>>> if (&__morestack && Name == "__morestack") >>>>>> return (uint64_t)&__morestack; >>>>>> #endif >>>>>> #endif // __linux__ && __GLIBC__ >>>>>> >>>>>> >>>>>> On Mon, Oct 3, 2016 at 3:32 PM, Teresa Johnson <tejohnson at google.com> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Oct 3, 2016 at 2:59 PM, Xinliang David Li < >>>>>>> xinliangli at gmail.com> wrote: >>>>>>> >>>>>>>> Is -fsplit-stack option used anywhere? My wild guess is that with >>>>>>>> ld.bfd, the thinLTO link for the DSO does not bring in morestack.o from >>>>>>>> libgcc.a, but the hidden symbol is defined in lldb binary. >>>>>>>> >>>>>>> >>>>>>> AFAICT, no - I had done "ninja -v" so I have all of the intermediate >>>>>>> build commands, and it doesn't show up in that. >>>>>>> >>>>>>> I'll have to do some more digging to figure out why it is referenced >>>>>>> from liblldb.so in the ld.bfd case and not when using ld.gold >>>>>>> >>>>>>> Teresa >>>>>>> >>>>>>> David >>>>>>>> >>>>>>>> On Mon, Oct 3, 2016 at 1:54 PM, Teresa Johnson via llvm-dev < >>>>>>>> llvm-dev at lists.llvm.org> wrote: >>>>>>>> >>>>>>>>> Aha - finally reproduced! The difference is using ld.bfd not >>>>>>>>> ld.gold. With that I get the same failure (using 3.9 to build 3.9 sources): >>>>>>>>> >>>>>>>>> /usr/local/google/home/tejohnson/binutils_build/install/bin/ld: >>>>>>>>> bin/lldb-3.9.1: hidden symbol `__morestack' in >>>>>>>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a(morestack.o) is >>>>>>>>> referenced by DSO >>>>>>>>> /usr/local/google/home/tejohnson/binutils_build/install/bin/ld: >>>>>>>>> final link failed: Bad value >>>>>>>>> clang-3.9: error: linker command failed with exit code 1 (use -v >>>>>>>>> to see invocation) >>>>>>>>> ninja: build stopped: subcommand failed. >>>>>>>>> >>>>>>>>> I am not sure what the official support story is for LLVMgold.so >>>>>>>>> and ld.bfd. As mentioned earlier, the LLVM site indicates it should use the >>>>>>>>> gold linker. Can you use that while I try to figure out whether this is >>>>>>>>> something that should be supported/working? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Teresa >>>>>>>>> >>>>>>>>> On Mon, Oct 3, 2016 at 9:56 AM, Carsten Mattner < >>>>>>>>> carstenmattner at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> On Mon, Oct 3, 2016 at 3:50 PM, Teresa Johnson < >>>>>>>>>> tejohnson at google.com> wrote: >>>>>>>>>> > >>>>>>>>>> > On Sun, Oct 2, 2016 at 4:02 AM, Carsten Mattner < >>>>>>>>>> carstenmattner at gmail.com> wrote: >>>>>>>>>> >> >>>>>>>>>> >> On Sun, Oct 2, 2016 at 6:41 AM, Teresa Johnson < >>>>>>>>>> tejohnson at google.com> wrote: >>>>>>>>>> > > >>>>>>>>>> > > > I use trunk, but it depends on how close to the bleeding >>>>>>>>>> edge you >>>>>>>>>> > > > are comfortable with. But like I said, I also tried >>>>>>>>>> bootstrapping >>>>>>>>>> > > > with 3.9 (both trunk as well as 3.9 sources) and couldn't >>>>>>>>>> reproduce. >>>>>>>>>> >> >>>>>>>>>> >> Hmm, so you're saying neither fails for you, right? >>>>>>>>>> > >>>>>>>>>> > Yes >>>>>>>>>> >>>>>>>>>> Okay. Do you mind focusing on the 3.9 branch? It's less of a >>>>>>>>>> moving target >>>>>>>>>> and lends itself more to figuring out what's failing for me. >>>>>>>>>> >>>>>>>>>> As soon as I get around to it, I'll send you my full configure >>>>>>>>>> and build >>>>>>>>>> steps as a shell script. Need to streamline it. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Teresa Johnson | Software Engineer | tejohnson at google.com | >>>>>>>>> 408-460-2413 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> LLVM Developers mailing list >>>>>>>>> llvm-dev at lists.llvm.org >>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Teresa Johnson | Software Engineer | tejohnson at google.com | >>>>>>> 408-460-2413 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Teresa Johnson | Software Engineer | tejohnson at google.com | >>>> 408-460-2413 >>>> >>> >>> >> >> >> -- >> Teresa Johnson | Software Engineer | tejohnson at google.com | >> 408-460-2413 >> > > > > -- > Teresa Johnson | Software Engineer | tejohnson at google.com | > 408-460-2413 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161004/fad39bef/attachment.html>