RFR (M): Enable HotSpot build with Clang

Sat May 25 01:39:50 PDT 2013

On Fri, May 24, 2013 at 5:32 PM, Christian Thalinger <
christian.thalinger at oracle.com> wrote:

>
> 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?
>
>
OK, if you insist so badly :)

http://cr.openjdk.java.net/~simonis/webrevs/8015252.v2/

I've tried not to change anything in the default gcc build with the one
exception that i486 will now use '-g' instead of '-gstabs' as well which I
think should be OK. But you can easily change that if you'd like.

Please notice that I won't be in the office until the 3rd of June. Should
you have any further change requests please feel free to edit the patch
yourself if you like.

Regards,
Volker

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