[LLVMdev] [cfe-dev] Integrated ARM assembler

Renato Golin renato.golin at linaro.org
Tue Feb 5 15:48:31 PST 2013


On 5 February 2013 23:21, Greg Fitzgerald <garious at gmail.com> wrote:

> > Is this for inline asm?
>
> Yep
>

In that case, using GAS is always a better options... for now. ;)


What I'd prefer to see is if the integrated-as doesn't recognize the
> option, clang should report a warning and switch to the 'no-integrated-as'
> path.  Thoughts?
>

The main problem with this is that in a large project, with different
flags, some files will be compiled with integrated-as, others with GAS, and
this could also change in time, creating a good headache for many people. ;)


I agree that's the more important question, but shouldn't we be able to
> throw hand-written assembly files at clang too?
>

Of course we should, but as long as it's hidden behind a flag, it'll never
be properly tested and people will never fix the bugs...


$ echo "void a(){}" | clang -x c -S - -o - | clang -x assembler -c -
> -integrated-as
> <stdin>:2:2: error: unknown directive
> .eabi_attribute 6, 2
>

Hum, that's bad and should be fixed. Can you create a bug, pls?


I agree, but if you do it today, some builds will certainly choke at
> compile-time.  Chromium serves as a nice big workload that currently builds
> with a very recent version of Clang.  As is, that build will go down if you
> switched the default on them.
>

I think this is a concern. Not everyone can change to recent versions of
clang as soon as they come out, but as long as the problems are just
warnings, I think we can risk a bit more exposure.

Can you compile Chromium entirely, ignoring the warnings and hand-written
ASM, with integrated-as, for ARM?

In your project configuration, you could add "-no-integrated-as" for the
parts that do have inline ASM.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130205/cd89b2bf/attachment.html>


More information about the llvm-dev mailing list