<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 12:14 PM, Riyad Parvez <span dir="ltr"><<a href="mailto:riyad.parvez@uwaterloo.ca" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=riyad.parvez@uwaterloo.ca&cc=&bcc=&su=&body=','_blank');return false;">riyad.parvez@uwaterloo.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Nov 9, 2015 at 11:52 AM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=kcc@google.com&cc=&bcc=&su=&body=','_blank');return false;">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Intuitively, one may indeed think that some signed integer overflows are more dangerous than others.<div>But scientifically, they are all bugs. </div></div></blockquote><div><br></div></span><div>I agree, they are all bugs unless someone using overflows for optimizing code. But from security perspective not all bugs are security vulnerabilities. Right now I'm interested into security vulnerabilities only.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>My favorite real-life example: <a href="http://stackoverflow.com/questions/7682477/why-does-integer-overflow-on-x86-with-gcc-cause-an-infinite-loop" target="_blank">http://stackoverflow.com/questions/7682477/why-does-integer-overflow-on-x86-with-gcc-cause-an-infinite-loop</a></div><div><br></div><div>It is totally unclear if we can come up with a reliable heuristic that will distinguish between less harmful and more harmful int overflows.</div><div>E.g. what if the computation of an array index happens in a separate function?</div><div><br></div></div></blockquote><div><br></div></span><div>In academic security research, what I've seen so far is that dynamic taint analysis is done with conjunction with overflow checks. If the operands in overflows are tainted by user input and that arithmetic overflow leads to crashes etc. i.e., an user has the ability to crash the program by simply providing different kinds of input, then it's more interesting. But again, things are not that simple. Overflows can change the intended semantics of the program which in turn can lead to security vulnerabilities.</div><div><br></div><div>Coming back to the original question, is there any API or option to enable overflow checks for certain translation units?</div></div></div></div></blockquote><div><br></div><div>You can do this by simply adding -fsanitize=* to the units you want to check and not adding it to others. </div><div>You can also use -fsanitize-blacklist=blacklist.txt, see <a href="http://clang.llvm.org/docs/SanitizerSpecialCaseList.html">http://clang.llvm.org/docs/SanitizerSpecialCaseList.html</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>--kcc </div><div>  </div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 7:07 AM, Riyad Parvez via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cfe-dev@lists.llvm.org&cc=&bcc=&su=&body=','_blank');return false;">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Sun, Nov 8, 2015 at 11:07 PM, Alexander Potapenko <span dir="ltr"><<a href="mailto:glider@google.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=glider@google.com&cc=&bcc=&su=&body=','_blank');return false;">glider@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr">Can you please give an example of a benign integer overflow?<br></p></blockquote></span><div>Here 'benign' from security perspective is usually defined as arithmetic overflows that don't trigger low-level security vulnerabilities e.g. buffer overflows. Many arithmetic overflows don't trigger buffer overflows eventually. Copy pasted from [1]:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>For example, if
x is an int type variable, the statement if(x >= -2
&& x<= 0x7ffffffd) will be translated into such
a piece of assembly code by GCC-4.2.0 compiler:
mov eax, x; // eax = x
add eax, 2; // eax = eax+2
js target
In this case, a large x such as 0x7fffffff causes an
overflow in above add instruction, but it is harmless as
GCC actually uses this overflow to reduce a comparison
instruction.</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr">
Note that by disabling the checks for non-pointer arithmetic you can easily throw the baby out with the bathwater. The compiler can easily take advantage of signed integer overflow being undefined irrespective of it being called "benign" or not.</p></blockquote></span><div>There's a good paper on this, you can have a look if you are interested [2].</div><div><br></div><div>[1] <a href="https://www.utdallas.edu/~zxl111930/file/IntScope_NDSS09.pdf" target="_blank">https://www.utdallas.edu/~zxl111930/file/IntScope_NDSS09.pdf</a></div><div>[2] <a href="https://people.csail.mit.edu/nickolai/papers/wang-stack.pdf" target="_blank">https://people.csail.mit.edu/nickolai/papers/wang-stack.pdf</a></div><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<p dir="ltr">sent from phone</p><div><div>
<div class="gmail_quote">On Nov 7, 2015 1:19 PM, "Riyad Parvez via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cfe-dev@lists.llvm.org&cc=&bcc=&su=&body=','_blank');return false;">cfe-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Is it possible to enable integer overflow sanitizer for certain cases as in many cases integer overflows are benign? I'm interested in mainly integer overflow during pointer arithmetic or memory allocations. Or enabling sanitizer for certain course files?</div><div><br></div>Thanks,<div>Riyad</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 3, 2015 at 7:43 PM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=vonosmas@gmail.com&cc=&bcc=&su=&body=','_blank');return false;">vonosmas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Nov 3, 2015 at 3:26 PM, Riyad Parvez via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cfe-dev@lists.llvm.org&cc=&bcc=&su=&body=','_blank');return false;">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Thanks a lot.<div><br></div><div>I had decided to detect overflow by SIGABRT. The issue SIGABRT is also thorwn by when assertion violation occurs. So SIGABRT is not the perfect indicator of overflow. </div><div><br></div><div>I see all the arithmetic operations are performed by "__ubsan_handle_*_overflow" built-in functions. If I catch SIGABRT, "__ubsan_handle_*_overflow" functions in the stack, can I safely assume the program is terminated in overflow?<br></div></div></blockquote><div><br></div></span><div>Probably yes: if one of these function was called by the program, it will certainly report an overflow. In theory, we don't guarantee that the names of these functions will stay the same, or that we always report overflows through them (i.e. it's an implementation detail), but in practice it would unlikely change soon.</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>Thanks,</div><div>Riyad</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 23, 2015 at 3:01 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=kcc@google.com&cc=&bcc=&su=&body=','_blank');return false;">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div><br></div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Oct 23, 2015 at 11:35 AM, Riyad Parvez <span dir="ltr"><<a href="mailto:riyad.parvez@uwaterloo.ca" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=riyad.parvez@uwaterloo.ca&cc=&bcc=&su=&body=','_blank');return false;">riyad.parvez@uwaterloo.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Interesting! "UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1" works fine, but just "UBSAN_OPTIONS=abort_on_error=1" doesn't work. Is it by design?</div></blockquote><div><br></div><div><br></div></span><div>sort of. </div><div>by default, ubsan simply does not exit, so it does not care about abort_on_error. </div><div><div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 23, 2015 at 2:30 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=kcc@google.com&cc=&bcc=&su=&body=','_blank');return false;">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Oct 23, 2015 at 11:27 AM, Riyad Parvez <span dir="ltr"><<a href="mailto:riyad.parvez@uwaterloo.ca" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=riyad.parvez@uwaterloo.ca&cc=&bcc=&su=&body=','_blank');return false;">riyad.parvez@uwaterloo.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Thanks! It works on the latest version of clang, but I was using clang 3.4 where it didn't work.</div></blockquote><div><br></div></span><div>3.4 was loooong ago. </div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>On a more related note, SIGABRT better indicator of bugs than non-zero exit status. So I've tried "ASAN_OPTIONS=abort_on_error=1" option which works for address sanitizer where program exists with SIGABRT. But "UBSAN_OPTIONS=abort_on_error=1" doesn't exit with SIGABRT. Is there any way to make overflow sanitizer exit with SIGABRT similar to address sanitizer?</div></div></blockquote><div><br></div></span><div>Just checked: </div><div><br></div><div><div>% clang -fsanitize=address,signed-integer-overflow int-overflow.c && UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1 ./a.out ; echo EXIT STATUS: $?</div><span><div>int-overflow.c:5:5: runtime error: signed integer overflow: 1073741824 + 1073741824 cannot be represented in type 'int'</div></span><div>SUMMARY: AddressSanitizer: undefined-behavior int-overflow.c:5:5 in </div><div>Aborted (core dumped)</div><div>EXIT STATUS: 134</div></div><div><div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 23, 2015 at 1:06 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=kcc@google.com&cc=&bcc=&su=&body=','_blank');return false;">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Oct 23, 2015 at 7:08 AM, Riyad Parvez <span dir="ltr"><<a href="mailto:riyad.parvez@uwaterloo.ca" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=riyad.parvez@uwaterloo.ca&cc=&bcc=&su=&body=','_blank');return false;">riyad.parvez@uwaterloo.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Thanks for the reply.<div><br></div><div>I am developing a fuzzer and interested to find overflows. </div></div></blockquote><div><br></div></span><div>So am I :) </div><div><a href="http://llvm.org/docs/LibFuzzer.html" target="_blank">llvm.org/docs/LibFuzzer.html</a><br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Is there any way to detect when errors are detected? To explain more, I have instrumented the binary to see which functions are called in run-time. What are the functions that are called when overflow is detected? When these functions are called I will know overflow is detected.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Oct 22, 2015 at 8:08 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=kcc@google.com&cc=&bcc=&su=&body=','_blank');return false;">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Oct 22, 2015 at 11:52 AM, Riyad Parvez via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cfe-dev@lists.llvm.org&cc=&bcc=&su=&body=','_blank');return false;">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi All,<div><br></div><div>With "-fsanitize=integer" flag, when an overflow is detected the program is terminated with zero exit code.</div></div></blockquote><div><br></div></span><div>You can change this behavior by using env. var.</div><div>UBSAN_OPTIONS=halt_on_error=1<br></div><div><br></div></div></div></div></blockquote><div><br></div></span><div>I've tried this; didn't work.</div></div></div></div></blockquote><div><br></div></span><div>What exactly do you run? </div><div><br></div><div>Here is what works for me: </div><div><br></div><div><div>% cat int-overflow.c </div><div>#include <stdio.h></div><div>int x;</div><div>int main(int argc, char **argv) {</div><div>  x += 1 << 30;</div><div>  x += 1 << 30;</div><div>  printf("%d\n", x);</div><div>  return 0;</div><div>}</div></div><div><br></div><div><br></div><div><div>% clang -fsanitize=signed-integer-overflow int-overflow.c && ./a.out ; echo EXIT STATUS: $?</div><div>int-overflow.c:5:5: runtime error: signed integer overflow: 1073741824 + 1073741824 cannot be represented in type 'int'</div><div>-<a href="tel:2147483648" value="+12147483648" target="_blank">2147483648</a></div><div>EXIT STATUS: 0</div><div>% clang -fsanitize=signed-integer-overflow int-overflow.c && UBSAN_OPTIONS=halt_on_error=1 ./a.out ; echo EXIT STATUS: $?</div><div>int-overflow.c:5:5: runtime error: signed integer overflow: 1073741824 + 1073741824 cannot be represented in type 'int'</div><div>EXIT STATUS: 1</div><div>% </div></div><span><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>(Not sure if this is properly documented anywhere. Alexey? )</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div> But with "-fsanitize=address" flag, the program terminates with non-zero exit code. I think the address sanitizer behavior of non-zero exit code is more intuitive since the program did exit in error. Is there any reason integer overflow sanitizer exits the program with zero exit code?</div></div></blockquote><div><br></div></span><div>One of the reasons, maybe:</div><div>Programs are more often ubsan-unclean than asan-unclean, and halting on every ubsan message makes it harder to deploy the tool. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks,</div><div>Riyad</div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cfe-dev@lists.llvm.org&cc=&bcc=&su=&body=','_blank');return false;">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cfe-dev@lists.llvm.org&cc=&bcc=&su=&body=','_blank');return false;">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div></div></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=vonosmas@gmail.com&cc=&bcc=&su=&body=','_blank');return false;">vonosmas@gmail.com</a></div></div>
</font></span></div></div>
</blockquote></div><br></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cfe-dev@lists.llvm.org&cc=&bcc=&su=&body=','_blank');return false;">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div>
</div></div></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cfe-dev@lists.llvm.org&cc=&bcc=&su=&body=','_blank');return false;">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>