<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Yes, it’s unexpected -- these 32 bit relocs are section relative and by using them the code generator is assuming that the two sections will be loaded within
4GB of one another.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">So for large code model compiles, they shouldn’t be used.<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Joshua Gerrard [mailto:joshua.gerrard@roli.com]
<br>
<b>Sent:</b> Wednesday, October 14, 2015 12:52 AM<br>
<b>To:</b> Lang Hames <lhames@gmail.com><br>
<b>Cc:</b> Andy Ayers <andya@microsoft.com>; llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [llvm-dev] [cfe-dev] Orc Windows C++<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">That's great news, thanks! If I can be of any help, let me know. :)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I'll see if I can reduce the example for the relocation issue whilst you're at it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Regards,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Joshua<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p>--<br>
Joshua Gerrard<br>
JUCE Software Developer<o:p></o:p></p>
<p style="margin-bottom:12.0pt"><i><span style="font-size:10.0pt">ROLI’s </span></i><span style="font-size:10.0pt"><a href="http://www.telegraph.co.uk/luxury/design/31520/the-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html" target="_blank"><i><span style="color:#1155CC">award-winning</span></i></a><i> Seaboard
GRAND, celebrated as the “</i><a href="http://edition.cnn.com/2013/09/27/tech/innovation/hans-zimmer-seaboard-future-piano/" target="_blank"><i><span style="color:#1155CC">piano of the future</span></i></a><i>”, is now joined by the </i><a href="https://www.youtube.com/watch?v=fGr7VbDiRNw" target="_blank"><i><span style="color:#1155CC">Seaboard
RISE</span></i></a><i>, “</i><a href="http://www.soundonsound.com/news?NewsID=18726" target="_blank"><i><span style="color:#1155CC">every bit as slimline and attractive as its bigger brother</span></i></a><i>”. The press is hailing the Seaboard RISE as “</i><a href="http://www.wired.co.uk/news/archive/2015-09/10/seaboard-rise-digital-keyboard-launch-uk-price" target="_blank"><i><span style="color:#1155CC">innovative</span></i></a><i>”,
“</i><a href="http://createdigitalmusic.com/2015/09/new-roli-instrument-wants-make-expressive-control-mainstream/" target="_blank"><i><span style="color:#1155CC">expressive</span></i></a><i>”, “</i><a href="http://createdigitalmusic.com/2015/09/new-roli-instrument-wants-make-expressive-control-mainstream/" target="_blank"><i><span style="color:#1155CC">accessible</span></i></a><i>”,
and “</i><a href="http://www.slashgear.com/roli-seaboard-rise-is-like-3d-touch-for-musicians-11404216/" target="_blank"><i><span style="color:#1155CC">a keyboard controller that does to piano keys what 3D touch does to the iPhone</span></i></a><i>”. Now available
for preorder at </i><a href="http://www.roli.com/" target="_blank"><i><span style="color:#1155CC">www.roli.com</span></i></a><i>.</i></span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 14 October 2015 at 06:48, Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hi Joshua, Andy,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm afraid I'm not familiar with COFF. Andy - is <span style="font-size:10.0pt">IMAGE_REL_AMD64_REL32 unexpected if you're compiling for 64-bit mode? It sounds like it from your description above.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">I'll look in to the "BSS sections don't have contents" error tomorrow: It looks like it's happening in platform-agnostic RuntimeDyld code, so hopefully I can reproduce this on Darwin.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">Cheers,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">Lang.</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On Mon, Oct 5, 2015 at 9:28 AM, Joshua Gerrard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">Oops, sorry for the spam.<br>
<br>
That last comment was incorrect. It’s IMAGE_REL_AMD64_REL32 not _5<o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><br>
> On 5 Oct 2015, at 17:26, Joshua Gerrard <<a href="mailto:joshua.gerrard@roli.com" target="_blank">joshua.gerrard@roli.com</a>> wrote:<br>
><br>
> Additional info: when the relocation issue does occur the relocation type is IMAGE_REL_AMD64_REL32_5<br>
><br>
>> On 5 Oct 2015, at 17:16, Joshua Gerrard <<a href="mailto:joshua.gerrard@roli.com" target="_blank">joshua.gerrard@roli.com</a>> wrote:<br>
>><br>
>> It’s pretty intermittent at the moment…sometimes I get the relocation overflow issue, sometimes I get another issue about BSS sections having no contents.<br>
>><br>
>> The source code to reproduce either is simple:<br>
>><br>
>> #include <iostream><br>
>><br>
>> int main (int argc, char* argv[])<br>
>> {<br>
>><br>
>> }<br>
>><br>
>> I’ve managed to reproduce the BSS section issue in clang consistently, and since that comes before terms of where it happens in the compilation / JIT’ing process, I can’t get to the part where I see the relocation issue in clang.exe rather than my own program.<br>
>><br>
>> clang.exe -c "Y:\Documents\Visual Studio 2013\Projects\NewProject\Source\main.cpp"<br>
>> llvm-rtdyld.exe" -execute main.o -dylib=C:\Windows\System32\msvcr120d.dll<br>
>><br>
>> It also occurs with -mcmodel=large specified.<br>
>><br>
>> The exact output of the second command, llvm-rtdyld, is as follows...<br>
>><br>
>> Assertion failed: (Sec->Characteristics & COFF::IMAGE_SCN_CNT_UNINITIALIZED_DATA) == 0 && "BSS sections don't have contents!", file C:\llvm\llvm\lib\Object\COFFObjectFile.cpp, line 951<br>
>> 0x00007FF65EAA574C (0x0000000000000016 0x00007FFC73140648 0x0000007900000008 0x00000079E68EDC40), HandleAbort() + 0xC bytes(s), c:\llvm\llvm\lib\support\windows\signals.inc, line 296<br>
>> 0x00007FFC807B396F (0x00007FF600000016 0x0000000000000000 0x0000007900000004 0x0000000000000101), raise() + 0x35F bytes(s)<br>
>> 0x00007FFC807C2060 (0x00000079E68EE3F0 0x0000000000000240 0x00007FFC80888430 0x00007FF65F7BFF80), abort() + 0x40 bytes(s)<br>
>> 0x00007FFC807ABF78 (0x00007FF65F7BFF80 0x00007FF65F7BFEF0 0xCCCCCCCC000003B7 0xCCCCCCCCCCCCCCCC), _wassert() + 0x108 bytes(s)<br>
>> 0x00007FF65E9E7F57 (0x00000079E6A4AC40 0x00000079E68EE998 0x00000079E6A317FC 0x00000079E68EE968), llvm::object::COFFObjectFile::getSectionContents() + 0x77 bytes(s), c:\llvm\llvm\lib\object\coffobject<br>
>> file.cpp, line 951 + 0x43 byte(s)<br>
>> 0x00007FF65E9E46E4 (0x00000079E6A4AC40 0x00000079E68EEE88 0x00000079E6A317FC 0x00000079E68EEC98), llvm::object::COFFObjectFile::getSectionContents() + 0x74 bytes(s), c:\llvm\llvm\lib\object\coffobject<br>
>> file.cpp, line 293<br>
>> 0x00007FF65E8B2BC5 (0x00000079E68EEC48 0x00000079E68EEE88 0x00000079E68EEC98 0x00000079E68EEC78), llvm::object::SectionRef::getContents() + 0x55 bytes(s), c:\llvm\llvm\include\llvm\object\objectfile.h<br>
>> , line 375 + 0x2D byte(s)<br>
>> 0x00007FF65EA1E516 (0x00000079E6A5DEA0 0x00000079E68EEFF0 0x00000079E6A4AC40 0xCCCCCCCCCCCCCCCC), llvm::RuntimeDyldImpl::loadObjectImpl() + 0x4D6 bytes(s), c:\llvm\llvm\lib\executionengine\runtimedyld<br>
>> \runtimedyld.cpp, line 186 + 0x25 byte(s)<br>
>> 0x00007FF65EA431AC (0x00000079E6A5DEA0 0x00000079E68EF708 0x00000079E6A4AC40 0x00000079E68EF0C8), llvm::RuntimeDyldCOFF::loadObject() + 0x3C bytes(s), c:\llvm\llvm\lib\executionengine\runtimedyld\runt<br>
>> imedyldcoff.cpp, line 57 + 0x14 byte(s)<br>
>> 0x00007FF65EA1B411 (0x00000079E68EF338 0x00000079E68EF708 0x00000079E6A4AC40 0xCCCCCCCCCCCCCCCC), llvm::RuntimeDyld::loadObject() + 0x221 bytes(s), c:\llvm\llvm\lib\executionengine\runtimedyld\runtime<br>
>> dyld.cpp, line 928 + 0x2F byte(s)<br>
>> 0x00007FF65E6781A9 (0x00007FF65FB9AB70 0x00000079E6A45150 0x00007FF65F177408 0xCCCCCCCCCCCCCCCC), executeInput() + 0x419 bytes(s), c:\llvm\llvm\tools\llvm-rtdyld\llvm-rtdyld.cpp, line 365 + 0x1D byte(<br>
>> s)<br>
>> 0x00007FF65E67A885 (0x00007FF600000004 0x00000079E6A45150 0x0000000000000000 0x0000000000000000), main() + 0xF5 bytes(s), c:\llvm\llvm\tools\llvm-rtdyld\llvm-rtdyld.cpp, line 687 + 0x5 byte(s)<br>
>> 0x00007FF65EE518CD (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), __tmainCRTStartup() + 0x19D bytes(s), f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c, line 626 + 0x19 byte<br>
>> (s)<br>
>> 0x00007FF65EE519FE (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), mainCRTStartup() + 0xE bytes(s), f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c, line 466<br>
>> 0x00007FFC9C4F2D92 (0x00007FFC9C4F2D70 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0x22 bytes(s)<br>
>> 0x00007FFC9EE19F64 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x34 bytes(s)<br>
>><br>
>> …the stack trace of which looks semantically the same as when I have that assertion triggered in my own program.<br>
>><br>
>> Relevant information:<br>
>> - llvm, clang and compiler-rt revision 249038 from trunk<br>
>> - built with the command (where ../llvm is the llvm source root) cmake -G "Visual Studio 12 2013 Win64" -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF -DLLVM_INCLUDE_DOCS=OFF -DLLVM_USE_CRT_DEBUG=MDd -DLLVM_USE_CRT_RELEASE=MD ../llvm<br>
>> - VS2013 version 12.0.40629.00 Update 5<br>
>><br>
>> Running the same code without llvm-rtdyld.exe (i.e. non-JIT) does so without error.<br>
>><br>
>> Thanks very much for any response!<br>
>><br>
>> (Sorry for the slow reply, was trying to get something as minimal as possible for you to look at)<br>
>><br>
>>> On 2 Oct 2015, at 19:45, Andy Ayers <<a href="mailto:andya@microsoft.com" target="_blank">andya@microsoft.com</a>> wrote:<br>
>>><br>
>>> If LLVM is generating the x64 code and you have specified a large code model, you should not see any 32 bit relocations.<br>
>>><br>
>>> So it would be interesting to determine what kind of relocation you are seeing and where it came from.<br>
>>><br>
>>> -----Original Message-----<br>
>>> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of Joshua Gerrard via llvm-dev<br>
>>> Sent: Friday, October 2, 2015 1:18 AM<br>
>>> To: Hayden Livingston <<a href="mailto:halivingston@gmail.com" target="_blank">halivingston@gmail.com</a>><br>
>>> Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
>>> Subject: Re: [llvm-dev] [cfe-dev] Orc Windows C++<br>
>>><br>
>>> Thanks for the link!<br>
>>> There’s some code there that looks extremely relevant to say the least.<br>
>>><br>
>>>> On 1 Oct 2015, at 19:00, Hayden Livingston <<a href="mailto:halivingston@gmail.com" target="_blank">halivingston@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Maybe looking at their code might help:<br>
>>>><br>
>>>> <a href="https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu" target="_blank">
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu</a><br>
>>>> <a href="http://b.com" target="_blank">b.com</a>%2fdotnet%2fllilc%2fblob%2fdd12743f9cdb5418f1c39b2cd756da1e8396a9<br>
>>>> 22%2flib%2fJit%2fLLILCJit.cpp%23L299&data=01%7c01%7candya%40microsoft.<br>
>>>> com%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f141af91ab2d7cd011d<br>
>>>> b47%7c1&sdata=4LCM5dPAFSQZYdEV2jNoXbtIg79%2foS5%2bB8O2Nl3ZqT4%3d<br>
>>>><br>
>>>> On Thu, Oct 1, 2015 at 10:45 AM, David Blaikie via llvm-dev<br>
>>>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>>>> Moving to the LLVM Dev list & cc'ing Lang.<br>
>>>>><br>
>>>>> On Thu, Oct 1, 2015 at 4:23 AM, Joshua Gerrard via cfe-dev<br>
>>>>> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>>>>><br>
>>>>>> Hello folks,<br>
>>>>>><br>
>>>>>> I’m developing an application that uses Orc JIT for C++, which works<br>
>>>>>> swimmingly on Mac OS X. However, the Windows version has been a<br>
>>>>>> battle and a half, and it’s now at the point where I need some assistance to progress.<br>
>>>>>><br>
>>>>>> The problem I’m having is “Relocation overflow” (related:<br>
>>>>>> <a href="https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fllv" target="_blank">
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fllv</a><br>
>>>>>> <a href="http://m.org" target="_blank">m.org</a>%2fbugs%2fshow_bug.cgi%3fid%3d23228%23c8%2c&data=01%7c01%7candy<br>
>>>>>> a%<a href="http://40microsoft.com" target="_blank">40microsoft.com</a>%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SnxHR5RzKhzNYFDeryATV0MSpqTcjZauHtTG2GTEazA%3d see #8) … so I spoke to some clang developers who focussed
on Windows at CppCon last week, and they gave me the following advice:<br>
>>>>>> - Use ELF<br>
>>>>>> - Using this results in another issue about comdat sections, see here:<br>
>>>>>> <a href="https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2froo" target="_blank">
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2froo</a><br>
>>>>>> <a href="http://t.cern.ch" target="_blank">t.cern.ch</a>%2fphpBB3%2fviewtopic.php%3ft%3d19808&data=01%7c01%7candya%<br>
>>>>>> <a href="http://40microsoft.com" target="_blank">40microsoft.com</a>%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f141a<br>
>>>>>> f91ab2d7cd011db47%7c1&sdata=DxCUHFZFW7SxfN6pHlHDfT3yY4DrE5DZTyLCVDWv<br>
>>>>>> 3Yw%3d<br>
>>>>>> - Stick with COFF, but use the large code model<br>
>>>>>> - No observed difference, seems to be the case because JITDefault<br>
>>>>>> is being used in the same way as Large, which would make sense<br>
>>>>>> - According to the clang developers I spoke to, Lang and Andy<br>
>>>>>> might have an interest in fixing this (would seem likely, as they’re<br>
>>>>>> the two commenters on the first issue I linked), since it’s better<br>
>>>>>> to use COFF on Windows than keep trying to work around it<br>
>>>>>><br>
>>>>>> Any ideas?<br>
>>>>>><br>
>>>>>> Thanks in advance!<br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> cfe-dev mailing list<br>
>>>>>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>>>>>> <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flist" target="_blank">
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flist</a><br>
>>>>>> <a href="http://s.llvm.org" target="_blank">s.llvm.org</a>%2fcgi-bin%2fmailman%2flistinfo%2fcfe-dev&data=01%7c01%7ca<br>
>>>>>> ndya%<a href="http://40microsoft.com" target="_blank">40microsoft.com</a>%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86<br>
>>>>>> f141af91ab2d7cd011db47%7c1&sdata=9uOfIMd1%2b2DesS3Bne%2f2jkbDpV5REzk<br>
>>>>>> VYj33rujvMGY%3d<br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> LLVM Developers mailing list<br>
>>>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>>>> <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists" target="_blank">
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists</a><br>
>>>>> .<a href="http://llvm.org" target="_blank">llvm.org</a>%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev&data=01%7c01%7can<br>
>>>>> dya%<a href="http://40microsoft.com" target="_blank">40microsoft.com</a>%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f1<br>
>>>>> 41af91ab2d7cd011db47%7c1&sdata=FZAxWxfyZeisom9maEJGCLgK2aboy%2bnneyka<br>
>>>>> 4FPlh%2bE%3d<br>
>>>>><br>
>>><br>
>>> _______________________________________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>> <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev%0a&data=01%7c01%7candya%40microsoft.com%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=y93xNmwi0v4F3tMocQyu1rGo7zCnU5y3T2FLxSdSWo0%3d" target="_blank">
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev%0a&data=01%7c01%7candya%40microsoft.com%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=y93xNmwi0v4F3tMocQyu1rGo7zCnU5y3T2FLxSdSWo0%3d</a><br>
>><br>
><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>