RFR (M): Enable HotSpot build with Clang

[Volker Simonis]

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"?
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.


>
>
-- 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/f60f665b/attachment.html