<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 10, 2013, at 1:24 PM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 10/12/2013 19:47, Jim Grosbach
wrote:<br>
</div>
<blockquote cite="mid:F1D6D96D-F783-4CD7-B186-A94A8DB95A1D@apple.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div>
<div>On Dec 10, 2013, at 11:26 AM, Alp Toker <<a moz-do-not-send="true" href="mailto:alp@nuanti.com">alp@nuanti.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> <br>
<div class="moz-cite-prefix">On 10/12/2013 18:03, Jim
Grosbach wrote:<br>
</div>
<blockquote cite="mid:C5C76C35-2DDD-4634-A8BE-7B754C673D9F@apple.com" type="cite">
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> That causes
dissonance between what the compiler sees and what
lit.py sees for no particularly good reason. One of
the nice properties of lit tests is that they're also
valid compiler inputs, so trailing slash is a bit
unfortunate.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>How does the backslash break this in any way?</div>
</blockquote>
<br>
The backslash is interpreted by lit and the compiler in
different and incompatible ways.</div>
</blockquote>
<div><br>
</div>
<div>I disagree that this is different or incompatible.</div>
<div><br>
</div>
<div>In any case, you didn’t answer the more important of my two
questions. What compilers interpret this code differently?</div>
</div>
</blockquote>
<br>
Hi Jim,<br>
<br>
There are lots of ways line continuations are interpreted
differently between compilers and even different versions from the
same vendor.\<br></div></blockquote></div><div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><br>
This is inherent because each frontend has a different take on
fundamental issues like where lines and comments begin and end, and
even the semantics of what translation phases are vary between
compilers.<br>
<br></div></blockquote><div><br></div><div>No, they really don’t, modulo bugs. This is standards compliance territory. If the compilers aren’t conformant implementations, I have zero sympathy.</div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
Here's one quick example of how compilers interpret this code
differently:<br>
<br>
<blockquote><code><b>$</b> printf '//\\ \nint x=0;\nint x=0;' >
f.c</code><code></code><br>
<code></code><code></code><br>
<code></code><code><b>$</b> cat f.c</code><code></code><br>
<code></code><code>//\ </code><code></code><br>
<code></code><code>int x=0;</code><code></code><br>
<code></code><code>int x=0;</code><code></code><br>
<code></code><code></code><br>
<code></code><code><b>$</b> clang -fsyntax-only f.c</code><code></code><br>
<code></code><code></code><br>
<code></code><code><b>$</b> gcc-4.9 -fsyntax-only f.c</code><code></code><br>
<code></code><code></code><br>
<code></code><code><b>$</b> cl f.c</code><code></code><br>
<code></code><code>Microsoft (R) C/C++ Optimizing Compiler Version
18.00.21005.1 for x64</code><code></code><br>
<code></code><code>Copyright (C) Microsoft Corporation. All
rights reserved.</code><code></code><br>
<code></code><code></code><br>
<code></code><b><code>f.c(3) : </code></b><b><code><font color="#ff0000">error C2374</font></code></b><b><code>: 'x'
: redefinition; multiple initialization</code></b><b><code></code></b><b><br>
</b><b><code></code></b><b><code> f.c(2) : see declaration
of 'x</code></b><font face="monospace"><b>’</b></font></blockquote></div></blockquote></div>That’s a bug in either MSVC or in whatever you’re using to get a bash prompt on windows. Probably line-ending related. It’s incorrectly not recognizing the continuation character at all.<div><br></div><div>-Jim</div></body></html>