RFR (M): Enable HotSpot build with Clang

[Christian Thalinger]

On May 24, 2013, at 2:05 AM, Volker Simonis <volker.simonis at gmail.com> wrote:

> 
> 
> 
> On Thu, May 23, 2013 at 7:15 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> On May 23, 2013, at 9:10 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
>> On Thu, May 23, 2013 at 5:50 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>> On May 23, 2013, at 2:30 AM, David Holmes <david.holmes at oracle.com> wrote:
>> 
>> > Hi Volker,
>> >
>> > On 23/05/2013 4:19 PM, Volker Simonis wrote:
>> >> On Thursday, May 23, 2013, David Holmes wrote:
>> >>    On 23/05/2013 1:59 PM, Christian Thalinger wrote:
>> >>        On May 22, 2013, at 2:28 PM, David Chase
>> >>        <david.r.chase at oracle.com> wrote:
>> >>
>> >>            Any idea how this interacts with "new build"?
>> >>
>> >>        It shouldn't since it doesn't set USE_CLANG=true.
>> >>
>> >>    Let me rephrase David's question :)
>> >>
>> >>    Will this allow me to simply point configure at clang, using
>> >>    --with-toolkit, and have everything just work?
>> >>
>> >>    I suspect not as, as you say, it doesn't set USE_CLANG=true.
>> >>
>> >>    Note I suspect the same is true for attempting to build on Solaris
>> >>    using gcc.
>> >>
>> >> You're right. This change only affects the HotSpot repository and it is
>> >> only the first ( and currently manual) step towards a complete JDK build
>> >> with clang.
>> >>
>> >> Nevertheless it seems usefull to me for the reasons I've pointed out.
>> >> And the resulting HotSpot should be usable within a 'normal' JDK build
>> >> with GCC (at least for the few smoke tests I've run).
>> >
>> > Yes I have no problem with it as it stands for hotspot. I do cringe at the need for the file duplication and am concerned that as clang is not one of the official build tools that it would be easy for the settings to bit-rot.
>> 
>> True.  When I tried to make a build work with clang I reused the GCC files but we have so many warnings that it doesn't work.  If we are gradually fixing these warnings we can get rid of the clang files again.
>> 
>> 
>> I'm not really sure this is desirable. There are other subtle differences (e.g. PCH) and there are clang options not understood by GCC and vice versa (e.g. the stack-alignment). You can see all of them if you look into the patch.
>> 
>> What we could do is to leave globalDefinitions_clang.hpp emtpy and just include globalDefinitions_gcc.hpp into it. But I don't know if that would be worth it?
>> 
>> After all they are two different compilers so maybe it's better to also treat them that way.
> 
> Well, clang tries very hard to be GCC compatible so we can build on that.  Here is what I did for BSD:
> 
> http://cr.openjdk.java.net/~twisti/8015252/webrev/make/bsd/makefiles/gcc.make.udiff.html
> 
> 
> Looks OK for me.
> 
> Why have you commented "-Wno-tautological-constant-out-of-range-compare"?

Because it's not supported by the clang version of Xcode 4.6.2:

cthaling at macbook:~$ clang -Wtautological-constant-out-of-range-compare
clang: warning: unknown warning option '-Wtautological-constant-out-of-range-compare'; did you mean '-Wtautological-compare'?
clang: error: no input files
cthaling at macbook:~$ clang -v
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.3.0
Thread model: posix

> Actually "-Wno-tautological-compare" implies "-Wno-tautological-constant-out-of-range-compare" but running with "-Wno-tautological-compare" and "-Wtautological-constant-out-of-range-compare" reveals a warning in:
> 
> hotspot/src/cpu/x86/vm/assembler_x86.cpp:1418:27: error: comparison of constant 16 with expression of type 'Assembler::Condition' is always true [-Werror,-Wtautological-constant-out-of-range-compare]
>   assert((0 <= cc) && (cc < 16), "illegal cc");
>                        ~~ ^ ~~
>  
> I don't think we need these:
> +  #if (defined(__GNUC__) && (__GNUC__ > 2)) || defined(__clang__) // gcc 2.x does not support noinline attribute
> because clang defines __GNUC__:
> 
> $ clang -dM -E - < /dev/null | grep __GNUC__
> #define __GNUC__ 4
>  
> 
> Agree.

Will you change Linux to also reuse the GCC files and remove these ifdefs?

-- Chris

>  
>  
> -- Chris
> 
>> 
>> 
>>  
>> > But you can say the exact same thing about the Solaris gcc support.
>> 
>> Btw. I just trying to resurrect this.
>> 
>> -- Chris
>> 
>> >
>> > David
>> > -----
>> >
>> >> Once it's in we could start with the JDK forest and the configure part
>> >> in the base repository. That would require two extra change sets anyway.
>> >> The HotSpot build currently isn't very configure-agnostic anyway and
>> >> once the other parts have been completed, configure could just pass
>> >> USE_CLANG=true (plus perhaps some extra variables in the case we have
>> >> more than one clang version on the system) to the HotSpot build and
>> >> everything should work.
>> >>  As a last step we would have to test on Mac as well. I currently don't
>> >> have one at hand, but sponsors are always welcome:)
>> >>
>> >> Volker
>> >>
>> >>
>> >>    David H.
>> >>
>> >>        -- Chris
>> >>
>> >>
>> >>            David
>> >>
>> >>
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130524/6e85b114/attachment-0001.html