My understanding of GCC is that it doesn't parse inline assembly except in so far as locating and expanding the %<digit> placeholders. The assembly itself is just a block of text. Assuming that understanding is correct, 1 and 3 would be closer to GCC's approach.
My personal preference would be to only have 3 as far as possible. Either 1/2 are necessary to support targets that do not sufficiently support the integrated assembler but are a migration path. This view is based on the idea that even if 'clang -S' succeeds with no errors, 'clang -integrated-as' will later assemble the assembly file and will error at that point. Essentially by parsing inline assembly when -S is used, we are merely moving the error one command earlier. However, I've realised the problem with this view. I can easily believe that some build systems will configure themselves with clang as the compiler, and gas as a standalone assembler. The result would be that there are two assemblers involved in the build. .c->.o would be compiled with clang, and assembled with 'clang -integrated-as' while .c->.s->.o would be compiled with clang and assembled with gas. With that realization in mind, my preference would be for 2 and 3. Warnings should be emitted for 2 so that ! we get bug reports about assembly we can't handle. As a side-note, updating autoconf/cmake so that they acknowledge that clang is also an assembler on some targets may be a sensible thing to do. This should prevent mixing 'clang -integrated-as' and gas and return us to the view where the integrated assembler will eventually assemble the file. > -----Original Message----- > From: Renato Golin [mailto:[email protected]] > Sent: 20 February 2014 11:38 > To: [email protected]; [email protected] > Cc: [email protected]; [email protected]; > [email protected]; Daniel Sanders > Subject: Re: [PATCH] MC: provide the ability to disable assembly parsing > > > > ================ > Comment at: include/llvm/MC/MCAsmInfo.h:310-315 > @@ -309,2 +309,8 @@ > > + /// Should we parse inline assembly? > + /// The integrated assembler will usually parse inline assembly. > However, > + /// when simply generating an object file, it can be useful to prevent > this > + /// (e.g. the Linux kernel uses it as a fancy preprocessor). > + bool ValidateInlineASMSyntax; > + > public: > ---------------- > Daniel Sanders wrote: > > Isn't this the same as UseIntegratedAssembler above? > Now, reading the comment above, I agree with you that the semantics is > close enough so that we can merge them. I think Saleem's approach to flags > was too conservative. > > I can see the following states: > > 1. We don't even parse, just dump text. > 2. We parse, but don't fail on error (like GNU) 3. We parse and fail on errors > > We need to dump one of them to have only one flag in which case it can be > either: > > * 1 and 3, as it is today, but we'll need to disable the parser by default > even > with IAS on for -S output, and that's what Saleem's patch is trying to do > * 2 and 3, as I proposed on my first comment, and was the original > assumption for enabling the IAS on -S output in the first place > > I'd rather have any of them than what we have now, but I'm not completely > convinced either is the best. > > I still slightly prefer 2 and 3 on the grounds that it was our original > agreement > (me, you, Jim), and it will enable us to do more with inline assembly (ex. > .code16/.code32) without breaking code that depends on weird behaviour > (ex. macros). Also, other folks (Chandler) are preferring this solution. > > > http://llvm-reviews.chandlerc.com/D2839 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
