RFR (M): Enable HotSpot build with Clang

Volker Simonis volker.simonis at gmail.com
Tue Jun 4 13:51:57 PDT 2013


Vladimir, thanks for your support - I won't forget it :)


On Tuesday, June 4, 2013, Vladimir Kozlov wrote:

> Why not create separate clang.make?
>
> Vladimir
>
> On 6/4/13 10:00 AM, Christian Thalinger wrote:
>
>
> On Jun 3, 2013, at 2:51 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com>
> wrote:
>
>  I have no idea where this stuff is supposed to be.  Maybe we should move
> the mulnode one to {i486,amd64}.make as well.  Vladimir pushed this
> change in 2009.
>
>
> gcc.make is place when you want lower optimization for all builds
> (product, fastdebug, debug) on all platforms. I played safe back then to
> avoid problems in all cases which may be overkill. And compiler code is not
> critical part of VM (not GC code) when we should worry about its
> performance.
>
>
> Alright.  I've added the same code to Linux as for BSD:
>
> http://cr.openjdk.java.net/~**twisti/8015252/webrev/<http://cr.openjdk.java.net/~twisti/8015252/webrev/>
>
> Please review and then let's push this.
>
> -- Chris
>
>
> Vladimir
>
> On 6/3/13 2:21 PM, Christian Thalinger wrote:
>
>
> On Jun 3, 2013, at 6:31 AM, Volker Simonis <volker.simonis at gmail.com
> <mailto:volker.simonis at gmail.com>> wrote:
>
>  On Fri, May 31, 2013 at 7:47 PM, Christian Thalinger
> <christian.thalinger at oracle.com
> <mailto:christian.thalinger at oracle.com>> wrote:
>
>
>     On May 31, 2013, at 12:41 AM, David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>
>     > I think this is mainly targetted at Volker but ...
>     >
>     > On 31/05/2013 4:32 AM, Christian Thalinger wrote:
>     >>> Here is what I have after merging in your new changes:
>     >>>
>     >>> http://cr.openjdk.java.net/~**twisti/8015252/webrev/<http://cr.openjdk.java.net/~twisti/8015252/webrev/>
>     >>>
>     >>> I see two problems:
>     >>>
>     >>> 1)  It's not possible to turn off precompiled headers because
>     of this:
>     >>>
>     >>> + ifeq ($(USE_CLANG), true)
>     >>> +   # clang has precompiled headers support by default, but
>     the user can switch
>     >>> +   # it off by using 'USE_PRECOMPILED_HEADER=0' on the
>     compile command line.
>     >>> +   ifdef LP64
>     >>> +     USE_PRECOMPILED_HEADER=1
>     >>> +   else
>     >>
>     >> Let me rephrase that:  at least not with an environment variable.
>     >
>     > In this block:
>     >
>     > ! ifeq ($(USE_CLANG), true)
>     > !   # clang has precompiled headers support by default, but the
>     user can switch
>     > !   # it off by using 'USE_PRECOMPILED_HEADER=0' on the compile
>     command line.
>     > !   ifdef LP64
>     > !     USE_PRECOMPILED_HEADER=1
>     > !   else
>     > !     # We don't support precompiled headers on 32-bit builds
>     because there some files are
>     > !     # compiled with -fPIC while others are compiled without
>     (see 'NONPIC_OBJ_FILES' rules.make)
>     > !     # Clang produces an error if the PCH file was comiled with
>     other options than the actual compilation unit.
>     > !     USE_PRECOMPILED_HEADER=0
>     > !   endif
>     >
>     > I think the LP64 case should be guarded by "ifeq
>     ($(USE_PRECOMPILED_HEADERS),)"**.
>
>     Yes, will change that.
>
>     >
>     > The comment "on the compile command line" should be "on the make
>     command line" I think.
>
>     I removed the comment since with the above guard it works with either.
>
>     >
>     > Typo: comiled
>
>     Fixed.
>
>     >
>     > David
>     > -----
>     >
>     >> -- Chris
>     >>
>     >>>
>     >>> 2)  If I compile with clang on Mac and run the compiler
>     regression tests a lot of them fail but they work with a debug VM.
>      So it seems that one of the files is broken with optimization on
>     (-Os or -O3; -O0 is okay).
>
>     I had some time yesterday to figure which file it is:
>      opto/loopTransform.cpp.  Compiling this one with NO_OPT makes
>     everyt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130604/0843dfe8/attachment.html 


More information about the hotspot-runtime-dev mailing list