Hi Greg, I'd also like to see the integrated assembler enabled, though I'm only very weakly connected to the 32-bit backend.> 1) The assembly parser does not parse the ARM-ELF directives.Renato asked about inline assembly here, but I think the key question is over the directives LLVM itself decides to generate as a result of Clang invocations. I had a very brief encounter last year which suggested this path was in place. Is there anything you're aware of that's missing along that route? If there is, I think there's a good chance we can invest some time in fixing it. In general terms, I'd like to see integrated-as enabled as soon as it reasonably can be. Relying on gas is icky. Does anyone know of actual clang regressions that would be triggered? Cheers. Tim
>> The assembly parser does not parse the ARM-ELF directives. > Is this for inline asm?Yep>> $ echo "void a(){}" | clang -target arm-none-linux-gnueabi -mllvm-arm-enable-ehabi -integrated-as -c -xc ->>Not implemented yet > Seems to work for me... ;)I see this just recently changed. I just confirmed the issue is in the 'release_32' branch, but not in 'master'.>> There are -Wa options that the integrated assembler does not recognize. > That's not really a problem and will *always* be that way.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?> I think the key question is over the directives LLVM itself decides togenerate as a result of Clang invocations I agree that's the more important question, but shouldn't we be able to throw hand-written assembly files at clang too? It'd be nice to assert that clang can consume its own generated assembly. Check this out (for brevity, assumes arm target is the default): $ echo "void a(){}" | clang -x c -S - -o - | clang -x assembler -c - -integrated-as <stdin>:2:2: error: unknown directive .eabi_attribute 6, 2> Does anyone know of actual clang regressions that would be triggered?I haven't seen any serious issues. Just little things like getting "unsupported argument" if you throw it: "-Wa,-mimplicit-it=always".> I'd like to see integrated-as enabled as soon as it reasonably can beI 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. Thanks, Greg On Tue, Feb 5, 2013 at 1:56 PM, Tim Northover <t.p.northover at gmail.com>wrote:> Hi Greg, > > I'd also like to see the integrated assembler enabled, though I'm only > very weakly connected to the 32-bit backend. > > > 1) The assembly parser does not parse the ARM-ELF directives. > > Renato asked about inline assembly here, but I think the key question > is over the directives LLVM itself decides to generate as a result of > Clang invocations. I had a very brief encounter last year which > suggested this path was in place. > > Is there anything you're aware of that's missing along that route? If > there is, I think there's a good chance we can invest some time in > fixing it. > > In general terms, I'd like to see integrated-as enabled as soon as it > reasonably can be. Relying on gas is icky. Does anyone know of actual > clang regressions that would be triggered? > > Cheers. > > Tim >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130205/781a112a/attachment.html>
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>