<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 31, 2013 at 7:47 PM, Christian Thalinger <span dir="ltr"><<a href="mailto:christian.thalinger@oracle.com" target="_blank">christian.thalinger@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><br>
On May 31, 2013, at 12:41 AM, David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote:<br>
<br>
> I think this is mainly targetted at Volker but ...<br>
><br>
> On 31/05/2013 4:32 AM, Christian Thalinger wrote:<br>
>>> Here is what I have after merging in your new changes:<br>
>>><br>
>>> <a href="http://cr.openjdk.java.net/~twisti/8015252/webrev/" target="_blank">http://cr.openjdk.java.net/~twisti/8015252/webrev/</a><br>
>>><br>
>>> I see two problems:<br>
>>><br>
>>> 1) It's not possible to turn off precompiled headers because of this:<br>
>>><br>
>>> + ifeq ($(USE_CLANG), true)<br>
>>> + # clang has precompiled headers support by default, but the user can switch<br>
>>> + # it off by using 'USE_PRECOMPILED_HEADER=0' on the compile command line.<br>
>>> + ifdef LP64<br>
>>> + USE_PRECOMPILED_HEADER=1<br>
>>> + else<br>
>><br>
>> Let me rephrase that: at least not with an environment variable.<br>
><br>
> In this block:<br>
><br>
> ! ifeq ($(USE_CLANG), true)<br>
> ! # clang has precompiled headers support by default, but the user can switch<br>
> ! # it off by using 'USE_PRECOMPILED_HEADER=0' on the compile command line.<br>
> ! ifdef LP64<br>
> ! USE_PRECOMPILED_HEADER=1<br>
> ! else<br>
> ! # We don't support precompiled headers on 32-bit builds because there some files are<br>
> ! # compiled with -fPIC while others are compiled without (see 'NONPIC_OBJ_FILES' rules.make)<br>
> ! # Clang produces an error if the PCH file was comiled with other options than the actual compilation unit.<br>
> ! USE_PRECOMPILED_HEADER=0<br>
> ! endif<br>
><br>
> I think the LP64 case should be guarded by "ifeq ($(USE_PRECOMPILED_HEADERS),)".<br>
<br>
</div></div>Yes, will change that.<br>
<div class="im"><br>
><br>
> The comment "on the compile command line" should be "on the make command line" I think.<br>
<br>
</div>I removed the comment since with the above guard it works with either.<br>
<br>
><br>
> Typo: comiled<br>
<br>
Fixed.<br>
<div class="im"><br>
><br>
> David<br>
> -----<br>
><br>
>> -- Chris<br>
>><br>
>>><br>
>>> 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).<br>
<br>
</div>I had some time yesterday to figure which file it is: opto/loopTransform.cpp. Compiling this one with NO_OPT makes everything to work.<br>
<br></blockquote><div><br></div><div>I can confirm this on Linux.<br></div><div><br></div><div>How did you fix it exactly? Have you added:<br><br>OPT_CFLAGS/loopTransform.o = $(OPT_CFLAGS/NOOPT)<br><br></div><div>to 'amd64.make' and excluded 'loopTransform.o' from precompiled header compilation in 'gcc.make' with:<br>
<br> PCH_FLAG/loopTransform.o = $(PCH_FLAG/NO_PCH)<br><br></div><div>That's what I've done to solve solve the problem.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Here are some build time numbers for my MacBook Pro:<br>
<br>
debug:<br>
------<br>
<br>
llvm-g++:<br>
<br>
real 2m28.831s<br>
user 12m58.277s<br>
sys 2m6.650s<br>
<br>
clang:<br>
<br>
real 1m28.552s<br>
user 8m4.760s<br>
sys 0m56.263s<br>
<br>
product:<br>
--------<br>
<br>
llvm-g++:<br>
<br>
real 2m16.939s<br>
user 12m32.473s<br>
sys 1m47.061s<br>
<br>
clang:<br>
<br>
real 1m35.744s<br>
user 8m50.101s<br>
sys 0m53.294s<br>
<br>
I think I know which I'm going to use… :-)<br>
<br>
-- Chris<br>
<div class=""><div class="h5"><br>
>>><br>
>>> Do you have any problems on Linux?<br>
>>><br>
>>> -- Chris<br>
>>><br>
>>>><br>
>>>>><br>
>>>>> David<br>
>>>>> -----<br>
>>>>><br>
>>>>>> Please notice that I won't be in the office until the 3rd of June.<br>
>>>>>> Should you have any further change requests please feel free to edit the<br>
>>>>>> patch yourself if you like.<br>
>>>>>><br>
>>>>>> Regards,<br>
>>>>>> Volker<br>
>>>>>><br>
>>>>>> -- Chris<br>
>>>>>><br>
>>>>>>> -- Chris<br>
>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>>> But you can say the exact same thing about the Solaris<br>
>>>>>>>> gcc support.<br>
>>>>>>>><br>
>>>>>>>> Btw. I just trying to resurrect this.<br>
>>>>>>>><br>
>>>>>>>> -- Chris<br>
>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> David<br>
>>>>>>>>> -----<br>
>>>>>>>>><br>
>>>>>>>>>> Once it's in we could start with the JDK forest and<br>
>>>>>>>> the configure part<br>
>>>>>>>>>> in the base repository. That would require two extra<br>
>>>>>>>> change sets anyway.<br>
>>>>>>>>>> The HotSpot build currently isn't very<br>
>>>>>>>> configure-agnostic anyway and<br>
>>>>>>>>>> once the other parts have been completed, configure<br>
>>>>>>>> could just pass<br>
>>>>>>>>>> USE_CLANG=true (plus perhaps some extra variables in<br>
>>>>>>>> the case we have<br>
>>>>>>>>>> more than one clang version on the system) to the<br>
>>>>>>>> HotSpot build and<br>
>>>>>>>>>> everything should work.<br>
>>>>>>>>>> As a last step we would have to test on Mac as well.<br>
>>>>>>>> I currently don't<br>
>>>>>>>>>> have one at hand, but sponsors are always welcome:)<br>
>>>>>>>>>><br>
>>>>>>>>>> Volker<br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> David H.<br>
>>>>>>>>>><br>
>>>>>>>>>> -- Chris<br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> David<br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>><br>
>>><br>
>><br>
<br>
</div></div></blockquote></div><br></div></div>