RFR (M): Enable HotSpot build with Clang

[Christian Thalinger]

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

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

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