RFR (M): Enable HotSpot build with Clang

[Volker Simonis]

Hi,

I'd like to propose the following change:

http://cr.openjdk.java.net/~simonis/webrevs/hotspot_clang.v1/

It would be great if somebody could open a BugID for it. Following some
details:

With this patch it becomes possible to build the HotSpot VM with the
clang<http://clang.llvm.org/>,
the "C language family frontend for LLVM". The changes have been tested
with clang 3.0 and 3.2 on 64-bit Linux/Intel (Ubuntu 12.04) building both
32-bit and 64-bit HotSpot VMs. The clang-build can be simply triggered by
setting USE_CLANG=true on the HotSpot build command line (in hotspot/make):

make jvmg USE_CLANG=true ALT_BOOTDIR=/share/software/Java/jdk1.7.0
ARCH_DATA_MODEL=32 HOTSPOT_BUILD_JOBS=8
make product USE_CLANG=true ALT_BOOTDIR=/share/software/Java/jdk1.7.0
ARCH_DATA_MODEL=64 HOTSPOT_BUILD_JOBS=8
make product USE_CLANG=true ALT_BOOTDIR=/share/software/Java/jdk1.7.0
ARCH_DATA_MODEL=64 HOTSPOT_BUILD_JOBS=8 USE_PRECOMPILED_HEADER=0

What is it good for?

The clang compiler provides very good diagnostic messages and warnings.
Currently all the following warnings are switched off in order to
successfully build the HotSpot with -Werror:

-Wno-unused-value -Wno-logical-op-parentheses
-Wno-parentheses-equality -Wno-parentheses
-Wno-switch -Wno-tautological-constant-out-of-range-compare
-Wno-tautological-compare
-Wno-delete-non-virtual-dtor -Wno-deprecated -Wno-format
-Wno-dynamic-class-memaccess
-Wno-return-type -Wno-empty-body

 Gradually turning these warnings (or at least some of them) on and fixing
the corresponding responsible source code locations may considerably
improve the code quality and even reveal some real bugs.

Another advantage of a clang build is the fact that clang is the default
compiler on MacOS. So this can be also seen as a first step towards 7123056
: Update compiler used in Mac 10.7 to
clang<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123056>.

Implementation Details

Currently the build will pick clang/clang++ from the current PATH much in
the same way as this is done for the gcc build. It is therefore possible to
test the build with different versions of clang by simply changing the
PATHsettings.

The changes are minimal in the sense that they don't change anything in the
current default build tool chain on Linux/Intel (i.e. without
USE_CLANG=truenothing will change). The very few source code changes
basically insert new
code variants for clang in places where we already dispatched based on the
compiler anyway.

The clang build only supports precompiled headers in 64-bit builds because
for 32-bit builds some files are compiled with -fPIC while others are
compiled without (see NONPIC_OBJ_FILES in make/linux/makefiles/rules.make).
But clang fails with an error if the PCH file was compiled with other
options than the actual compilation unit. Therefore the default is to use
PCHs for 64-bit builds (but this can be turned off with
USE_PRECOMPILED_HEADER=0) and switch them off for 32-bit builds.

Regards,

Volker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130522/bb9d562f/attachment.html