(In reply to Alex Chronopoulos [:achronop] from comment #14)
In the following run  the build files are configured to use clang for the assembly files (*.S), in conjunction with
-integrated-as (which is the default). This works well on Linux, clang builds the assembly files successfully, and the build is green. On the other hand windows does not behave the same way. The assembler, armasm64, is invoked to build the assembly files, even though integrated as has been requested, and the build fails.
-integrated-as is an option passed to the compiler, not the build system. The build system uses
AS for compiling assembly files (.asm and .S).
AS and its associated options and info is all set up here:
You'll see that for clang-cl, we use some external assembler always:
For the history, it is possible to work around the windows error by using the same steps described in Bug 1540760 which are to parse the *.S file with gas-preprocessor and change the file extension from .S to .asm .
The generated .asm has the appropriate syntax for armasm64, so this works.
Nevertheless if it was possible to teach our windows build system to compile the *.S files with clang instead of armasm, no modification would be necessary. The Linux example shows that clang can handle it successfully. In addition to that, since
integrated as has been requested, invoking an external assembler looks like a bug in our build system.
This is not a bug, for the aforementioned reason that the integrated assembler is a compiler option, not a build system option.
Nathan, do you think it is possible to use clang to compile the *.S files for the windows builds? Is there a quick way to try that out?
It's possible? You could try making the rule for
$(CC) instead of
$(AS), and maybe massaging it to look more like the
$(ASOBJS) rule, a couple of lines above. It's also possibly we could add a
no_really_use_the_compiler flag for assembly sources. Not sure how much would break...Is this really more useful than just using gas-preprocessor?
It looks like clang now has a fully-featured
gas compatible assembly parser, which it didn't have back in the day when we added
-fno-integrated-as or whatever. It's possible that some of those uses around the tree could go away, but that would be subject to whether our minimum supported clang does the
gas thing, too.