On Thu, 25 Mar 2021 16:25:32 GMT, Magnus Ihse Bursie <[email protected]> wrote:
> We have a handful of assembly files in the JDK. They have long been left
> aside, with a "if it ain't broken, don't fix it" attitude.
>
> In the current panama-vector, there is a lot more assembly files incoming,
> including for the Windows platforrm, which has not existed for a long time in
> the JDK.
>
> It is time to give assembly files some more love and care. This patch cleans
> up the handling in the build system, and it unifies between .s and .S files.
>
> For historical reasons, .s has been the suffix used in the posix world to
> signify assembly output as generated by a compiler, and .S to signify
> "hand-written" precious assembly. One effect of this is that gcc and clang
> will run the preprocessor on files named .S but not on files named .s.
>
> All our files are "hand-written" in this sense, and should have the .S
> suffix. But not all had. On mac, it was even worse, where the files were
> named .s but the option `-x assembler-with-cpp` was used to force clang to
> treat them as .S files instead... This change however made the preprocesser
> try to parse comments of the form
> # if (a) {
> as preprocessor directives, and balk at them. In one of the files, I had to
> wrap this in preprocessor comments (`/* ... */`).
>
> We also had inconsistent handling on dependencies. For preprocessed assembly
> files, it really makes sense to have dependency tracking, exactly as for
> C/C++ files. Now the dependency tracking in NativeCompilation is simplified,
> and applies to all files. (The sole exception is Windows assembly, since masm
> is unable to output dependency information, even though it is able to include
> files :-().
>
> This patch has been partly written by Sandhya Viswanathan
> <[email protected]> for the panama-vector repo.
make/autoconf/toolchain.m4 line 887:
> 885: # On windows, the assember is "ml.exe". We currently don't need
> this so
> 886: # do not require.
> 887: if test "x$OPENJDK_TARGET_CPU_BITS" = "x64"; then
If this is for the BUILD_AS, shouldn't we be checking OPENJDK_BUILD_CPU_BITS?
-------------
PR: https://git.openjdk.java.net/jdk/pull/3198
