RFR (M): Enable HotSpot build with Clang

Volker Simonis volker.simonis at gmail.com
Thu May 23 09:10:08 PDT 2013


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.


>
>
> 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/20130523/f6a49bc7/attachment-0001.html 


More information about the hotspot-runtime-dev mailing list