<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 20, 2014 at 12:21 AM, Saleem Abdulrasool <span dir="ltr"><<a href="mailto:compnerd@compnerd.org" target="_blank">compnerd@compnerd.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":gb4" style="overflow:hidden">When the integrated assembler is in use, the compiler is able to validate inline<br>

assembly.  However, in order to maintain compatibility with GCC (and<br>
expectations of user-code), inline assembly should not be validated.  The Linux<br>
kernel, for example, relies on this behaviour to use the compiler as a<br>
preprocessor.<br></div></blockquote><div><br></div><div>What do you mean by "a preprocessor"? If it is literally using the C-preprocessor over an assembly file, then I agree the assembly shouldn't be validated or ever parsed. But I don't think you do given that this patch relates to "inline assembly", and thus assembly instructions produced inline in the C code.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":gb4" style="overflow:hidden">
<br>
If we are emitting an object file, then the assembly must obviously be parsed,<br>
and as such, assembly processing is only disabled when emitting an assembly<br>
file.  It is possible to still perform the inline assembly validation (by means<br>
of parsing) by passing in the new -Winline-asm-syntax flag.</div></blockquote><div><br></div><div>This really doesn't make sense. So, we've not disabled the inline assembler, so we will eventually produce an error, but we don't ask it to validate the assembly about to be fed to itself (and errored on) while we have the full context of the source code to go with it? How is this reasonable behavior?</div>
<div><br></div><div>Very fundamentally, LLVM's integrated assembler *is* going to assemble the program. If it does not support some construct used in code today, either that construct is a reasonable extension to support, or it isn't. If it is, we should support it both in full assembly files and inline assembly. If it is not, we should reject it in both.</div>
<div><br></div><div>During the transition period we already have a clear and obvious way of saying to not use (or trust) the LLVM assembler which avoids this both for inline assembly and full assembly files.</div><div><br>
</div><div>At least, without a better description of the motivation for "GCC compatibility" here (is it GCC compatibility or GAS compatibility?) I'm very opposed to going further down this route. It seems at best to be delaying an error one phase of compilation, and at worst papering over serious deficiencies in our assembler (or in user code).</div>
</div></div></div>