RFR: Some build fixes for gcc4.7
David Holmes
david.holmes at oracle.com
Wed Dec 12 01:27:49 PST 2012
On 12/12/2012 6:19 PM, Roman Kennke wrote:
> Hi David,
>
> From my perspective, there are the following proposed changes not
> committed yet:
Sorry I was only referring to gcc4.7 specific issues.
For the other patches you are doing the right thing, it is just
unfortunate that there is a lot happening right now (M6 is just around
the corner) and people have a lot on their plate.
David
-----
> 1.
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007294.html
>
> From that one, only the jdk part is missing:
> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/
>
> I think it's the only one with a bug-id even:
> 8003868: fix shark for latest HotSpot and LLVM
>
> 2. Then there is the library_call build fixes. (Which have also been
> proposed by Yasumasa Suenaga, which now got the bug id 8004898 and
> Christian is working on it.)
>
> Then I posted a bunch of others on hotspot-compiler-dev (maybe
> hotspot-dev would have been better?)
>
> 3. Fix OSR in Shark for non-empty incoming stack
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009087.html
>
> This one got a little review by David Chase, for which I will send an
> updated webrev soon. I was hoping to get some more feedback though, or
> even a bug-id.
>
> 4. Implement deoptimization support in Shark
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009088.html
>
> This one did not get any feedback yet, no bug-id either.
>
> 5. Fix volatile float field access in Shark
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009089.html
>
> Same, no feedback, no bug-id.
>
> 6. Enable JSR292 support in Shark
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009090.html
>
> Got some positive feedback from John Rose, but no bug id and no
> progress.
>
> Please let me know if I should do anything different in the future
> (different mailing list, different format, ..) Also, if it helps, I can
> group all those changes into one big change, I just thought that it is
> easier to review in logical chunks (otherwise the changes would
> interleave and it's difficult to say what belongs to what).
>
>
> Thanks for your cooperation!
>
> Best regards,
> Roman
>
>
>> I think the library_call issue is the only thing that still needs
>> working on.
>>
>> David
>>
>> On 12/12/2012 8:17 AM, Coleen Phillimore wrote:
>>>
>>> On 12/11/2012 05:00 PM, Roman Kennke wrote:
>>>> Am Dienstag, den 11.12.2012, 16:53 -0500 schrieb Coleen Phillimore:
>>>>> Now I hit this library_call.cpp compilation error. Has it been pushed
>>>>> yet? I was going to piggyback this with another cleanup that I was
>>>>> making if not.
>>>> No, it has not been pushed yet. :-(
>>>>
>>>> Seems like all my patches have become stuck in the queue. Is there
>>>> anything that I can do to make them move forward? Should I file them in
>>>> openjdk bugzilla?
>>>
>>> What you are doing is the right way to submit patches. We don't really
>>> monitor openjdk bugzilla. I think people are working on your other patches.
>>>
>>> thanks,
>>> Coleen
>>>
>>>>
>>>> Regards,
>>>> Roman
>>>>
>>>>> thanks,
>>>>> Coleen
>>>>>
>>>>> On 12/07/2012 11:28 AM, Roman Kennke wrote:
>>>>>> Am Donnerstag, den 06.12.2012, 18:40 -0500 schrieb Coleen Phillimore:
>>>>>>> The changes to binaryTreeDictionary.cpp are already in the hotspot-gc
>>>>>>> repository and will/have been pushed up to main already. They should
>>>>>>> already be in hotspot-comp.
>>>>>> Ah great, good to see, thanks! :-)
>>>>>>
>>>>>>> Which compiler complains about the library_call.cpp changes? I have an
>>>>>>> unstable ubuntu 12.10 system in order to run with gcc 4.7.2 and this
>>>>>>> file compiles fine for me as is.
>>>>>> This happens on Fedora, gcc 4.7.2. Fedora tends to incorporate
>>>>>> improvements from dev versions sometimes... I agree with David, it
>>>>>> would
>>>>>> be good to fix in any case.
>>>>>>
>>>>>> Thanks,
>>>>>> Roman
>>>>>>
>>>>>>
>>>>
>>>
>
>
More information about the hotspot-dev
mailing list