> 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.
This is not entirely true. GCC also has to understand a bit about constant pools, the instruction set etc, but I don't know all the details. I think GCC doesn't parse the inline assembly further for the lack of an integrated assembler (and the desire to not duplicate gas), not because they though it was forbidden. > 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. Using Clang with integrated assembler on error mode to assembly result + another assembler entirely to produce object files would be a user error, not tool error. User that need another assembler should turn the integrated assembler off, or at least not turn further inline asm validation on. This is why I think the validation should be off by default, but still parsing the file to account for constant pool, instruction set and other inline asm issues. On any error, the compiler should just give up and dump text, and in that, the behaviour is identical to what GCC does. I don't see this as a temporary measure to support infant assemblers, but as a final destination to cope with legacy inline asm code in any platform at the same time as being compatible with the GNU toolchain, and being safer and nicer to our users. http://llvm-reviews.chandlerc.com/D2839 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
