On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz
wrote:
> Hi David and build-dev folk,
>
> After way too much build/hotspot hacking, I have a better fix:
>
> clang inlined os::current_stack_pointer into its caller __in the same
> translation unit___ (that could be fixed in a separate change) so o
Looks good to me.
/Erik
On 2018-06-20 16:49, Martin Buchholz wrote:
Thanks Erik.
On Wed, Jun 20, 2018 at 4:19 PM, Erik Joelsson
mailto:[email protected]>> wrote:
Hello,
It's very probable that we have made several such mistakes with
our flags, since for the most part, w
Thanks Erik.
On Wed, Jun 20, 2018 at 4:19 PM, Erik Joelsson
wrote:
> Hello,
>
> It's very probable that we have made several such mistakes with our flags,
> since for the most part, we have a 1-1 mapping of compiler and OS. We
> certainly appreciate correcting this whenever possible. I don't hav
I agree. This looks like a good example of legacy hotspot build settings
that we just translated as they were from the old hotspot build system.
/Erik
On 2018-06-20 16:39, Martin Buchholz wrote:
I saw in the *.cmdline files that when I build with clang, we get these
defines:
-DINCLUDE_SUFFI
Filed https://bugs.openjdk.java.net/browse/JDK-8205451
/Erik
On 2018-06-20 16:36, Erik Joelsson wrote:
That certainly looks like a bug. That macro was added to try to get
rid of the __FILE__ macro in the source code. Using __FILE__ and
__DATE__ makes it hard to achieve fully reproducible buil
I saw in the *.cmdline files that when I build with clang, we get these
defines:
-DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc
I see now that -DTARGET_COMPILER_gcc was intentional
HOTSPOT_TOOLCHAIN_TYPE=$TOOLCHAIN_TYPE
if test "x$TOOLCHAIN_TYPE" = xclang; then
HOTSPOT_TOOLCHAIN_TY
That certainly looks like a bug. That macro was added to try to get rid
of the __FILE__ macro in the source code. Using __FILE__ and __DATE__
makes it hard to achieve fully reproducible builds where we can verify
build changes by simply comparing the output files.
/Erik
On 2018-06-20 16:30,
While exploring the *.cmdline files created by the build (thank you, those
are very helpful!) I noticed that they all contain
-DTHIS_FILE='""'
Probably there should be an actual file name there.
Hello,
It's very probable that we have made several such mistakes with our
flags, since for the most part, we have a 1-1 mapping of compiler and
OS. We certainly appreciate correcting this whenever possible. I don't
have the expertise to verify your claim here, but I will take your word
for i
Hi David and build-dev folk,
After way too much build/hotspot hacking, I have a better fix:
clang inlined os::current_stack_pointer into its caller __in the same
translation unit___ (that could be fixed in a separate change) so of course
in this case it didn't have to follow the ABI. Fix is obvi
On 2018-06-20 11:10, Sergey Bylokhov wrote:
Hi, Erik.
Can you please clarify what will be minimum supported
versions(macOS,xcode)?
Older versions of Xcode installed on local machines will likely continue
to work for a while, as long as the community supports it.
Xcode 9.4 has 10.13.4 listed
Hi, Erik.
Can you please clarify what will be minimum supported versions(macOS,xcode)?
On 20/06/2018 09:07, Erik Joelsson wrote:
It's time for Oracle to change the official compiler used for building
OpenJDK on Macosx. The new version will be 9.4 and the build will happen
on Macosx 10.13(.4).
Looks fine.
-phil.
On 06/20/2018 09:07 AM, Erik Joelsson wrote:
It's time for Oracle to change the official compiler used for building
OpenJDK on Macosx. The new version will be 9.4 and the build will
happen on Macosx 10.13(.4).
Bug: https://bugs.openjdk.java.net/browse/JDK-8205424
Webrev:
Erik:
It's time for Oracle to change the official compiler used for building
OpenJDK on Macosx. The new version will be 9.4 and the build will happen
on Macosx 10.13(.4).
Bug: https://bugs.openjdk.java.net/browse/JDK-8205424
Webrev: http://cr.openjdk.java.net/~erikj/8205424/webrev.01/
Looks
It's time for Oracle to change the official compiler used for building
OpenJDK on Macosx. The new version will be 9.4 and the build will happen
on Macosx 10.13(.4).
Bug: https://bugs.openjdk.java.net/browse/JDK-8205424
Webrev: http://cr.openjdk.java.net/~erikj/8205424/webrev.01/
/Erik
Hi Pengfei,
On 20 June 2018 at 12:08, Pengfei Li wrote:
> Hi
>
> I have tried the patch (
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052991.html )
> on Ubuntu 18.04 machines (x86_64 & aarch64) with glibc=2.26.1 and build is OK.
>
> There's a small issue within the following
Yes, but you are a Committer, so that is fine in this case, since we
have two Reviewers already :)
Thank you! I'll push now.
..Thomas
On Wed, Jun 20, 2018 at 5:00 PM, Baesken, Matthias
wrote:
> Hi Thomas , looks good (however I am not a Reviewer) !
>
>
>> From: Thomas Stüfe
>> Date: Wed, Jun
Hi Thomas , looks good (however I am not a Reviewer) !
> From: Thomas Stüfe
> Date: Wed, Jun 20, 2018 at 10:00 AM
> Subject: RFR(xxs): 8205407: [windows, vs<2017] C4800 after 8203197
> To: build-dev
>
>
> Hi all,
>
> May I please have reviews for this small build fix?
>
> https://bugs.ope
Thomas:
May I please have reviews for this small build fix?
https://bugs.openjdk.java.net/browse/JDK-8205407
http://cr.openjdk.java.net/~stuefe/webrevs/8205497-windows-c4800/webrev.00/webrev/
In short, we need to disable C4800 for the JVM build as well since 8203197.
Looks good.
Tim
Thanks Tim.
On Wed, Jun 20, 2018 at 3:48 PM, Tim Bell wrote:
> Thomas:
>
>> May I please have reviews for this small build fix?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8205407
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8205497-windows-c4800/webrev.00/webrev/
>>
>> In short, we need
jdk-submit ran through without errors.
Anyone?
Plus, do you agree this falls under the trivial rule?
Thanks, Thomas
On Wed, Jun 20, 2018 at 10:00 AM, Thomas Stüfe wrote:
> Hi all,
>
> May I please have reviews for this small build fix?
>
> https://bugs.openjdk.java.net/browse/JDK-8205407
> htt
Hi all,
May I please have reviews for this small build fix?
https://bugs.openjdk.java.net/browse/JDK-8205407
http://cr.openjdk.java.net/~stuefe/webrevs/8205497-windows-c4800/webrev.00/webrev/
In short, we need to disable C4800 for the JVM build as well since 8203197.
Thank you,
Thomas
22 matches
Mail list logo
