RFR (M): Enable HotSpot build with Clang

[Christian Thalinger]

On Jun 3, 2013, at 6:31 AM, Volker Simonis <volker.simonis at gmail.com> wrote:

> On Fri, May 31, 2013 at 7:47 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> On May 31, 2013, at 12:41 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> > I think this is mainly targetted at Volker but ...
> >
> > On 31/05/2013 4:32 AM, Christian Thalinger wrote:
> >>> Here is what I have after merging in your new changes:
> >>>
> >>> http://cr.openjdk.java.net/~twisti/8015252/webrev/
> >>>
> >>> I see two problems:
> >>>
> >>> 1)  It's not possible to turn off precompiled headers because of this:
> >>>
> >>> + ifeq ($(USE_CLANG), true)
> >>> +   # clang has precompiled headers support by default, but the user can switch
> >>> +   # it off by using 'USE_PRECOMPILED_HEADER=0' on the compile command line.
> >>> +   ifdef LP64
> >>> +     USE_PRECOMPILED_HEADER=1
> >>> +   else
> >>
> >> Let me rephrase that:  at least not with an environment variable.
> >
> > In this block:
> >
> > ! ifeq ($(USE_CLANG), true)
> > !   # clang has precompiled headers support by default, but the user can switch
> > !   # it off by using 'USE_PRECOMPILED_HEADER=0' on the compile command line.
> > !   ifdef LP64
> > !     USE_PRECOMPILED_HEADER=1
> > !   else
> > !     # We don't support precompiled headers on 32-bit builds because there some files are
> > !     # compiled with -fPIC while others are compiled without (see 'NONPIC_OBJ_FILES' rules.make)
> > !     # Clang produces an error if the PCH file was comiled with other options than the actual compilation unit.
> > !     USE_PRECOMPILED_HEADER=0
> > !   endif
> >
> > I think the LP64 case should be guarded by "ifeq ($(USE_PRECOMPILED_HEADERS),)".
> 
> Yes, will change that.
> 
> >
> > The comment "on the compile command line" should be "on the make command line" I think.
> 
> I removed the comment since with the above guard it works with either.
> 
> >
> > Typo: comiled
> 
> Fixed.
> 
> >
> > David
> > -----
> >
> >> -- Chris
> >>
> >>>
> >>> 2)  If I compile with clang on Mac and run the compiler regression tests a lot of them fail but they work with a debug VM.  So it seems that one of the files is broken with optimization on (-Os or -O3; -O0 is okay).
> 
> I had some time yesterday to figure which file it is:  opto/loopTransform.cpp.  Compiling this one with NO_OPT makes everything to work.
> 
> 
> I can confirm this on Linux.

Good.

> 
> How did you fix it exactly? Have you added:
> 
> OPT_CFLAGS/loopTransform.o = $(OPT_CFLAGS/NOOPT)
> 
> to 'amd64.make'

No.  I added it to gcc.make because there was already this one:
+   # 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation. 
+   ifneq "$(shell expr \( \( $(CC_VER_MAJOR) = 4 \) \& \( $(CC_VER_MINOR) = 3 \) \))" "0"
+     OPT_CFLAGS/mulnode.o += -O0
+   endif
I have no idea where this stuff is supposed to be.  Maybe we should move the mulnode one to {i486,amd64}.make as well.  Vladimir pushed this change in 2009.
> and excluded 'loopTransform.o' from precompiled header compilation in 'gcc.make' with:
> 
>     PCH_FLAG/loopTransform.o = $(PCH_FLAG/NO_PCH)

Yes.

Here is an updated webrev:

http://cr.openjdk.java.net/~twisti/8015252/webrev/

-- Chris

> 
> That's what I've done to solve solve the problem.

>  
> Here are some build time numbers for my MacBook Pro:
> 
> debug:
> ------
> 
> llvm-g++:
> 
> real    2m28.831s
> user    12m58.277s
> sys     2m6.650s
> 
> clang:
> 
> real    1m28.552s
> user    8m4.760s
> sys     0m56.263s
> 
> product:
> --------
> 
> llvm-g++:
> 
> real    2m16.939s
> user    12m32.473s
> sys     1m47.061s
> 
> clang:
> 
> real    1m35.744s
> user    8m50.101s
> sys     0m53.294s
> 
> I think I know which I'm going to use… :-)
> 
> -- Chris
> 
> >>>
> >>> Do you have any problems on Linux?
> >>>
> >>> -- Chris
> >>>
> >>>>
> >>>>>
> >>>>> David
> >>>>> -----
> >>>>>
> >>>>>> 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/20130603/5edc681c/attachment.html