RFR (M): Enable HotSpot build with Clang

[Tim Bell]

I created RFE JDK-8015252 - Enable HotSpot build with Clang

The report should be visible at this URL in the next few business days:

http://bugs.sun.com/view_bug.do?bug_id=8015252

Tim

On 05/22/13 01:41 PM, Volker Simonis wrote:
>
> Hi,
>
> I'd like to propose the following change:
>
> http://cr.openjdk.java.net/~simonis/webrevs/hotspot_clang.v1/ 
> <http://cr.openjdk.java.net/%7Esimonis/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 |PATH| settings.
>
> 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=true| nothing 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
>