[PATCH] [clang] add support for -W{no-,}inline-asm-syntax

[Chandler Carruth]

On Thu, Feb 20, 2014 at 12:21 AM, Saleem Abdulrasool
<compnerd at compnerd.org>wrote:

> When the integrated assembler is in use, the compiler is able to validate
> inline
> assembly.  However, in order to maintain compatibility with GCC (and
> expectations of user-code), inline assembly should not be validated.  The
> Linux
> kernel, for example, relies on this behaviour to use the compiler as a
> preprocessor.
>

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.


> If we are emitting an object file, then the assembly must obviously be
> parsed,
> and as such, assembly processing is only disabled when emitting an assembly
> file.  It is possible to still perform the inline assembly validation (by
> means
> of parsing) by passing in the new -Winline-asm-syntax flag.
>

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?

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.

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.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140220/fff3e620/attachment.html>