It might be UBSan false positive :) What about ASan?
https://bugs.openjdk.java.net/browse/JDK-8189800
在 2018年09月06日 09:12, Martin Buchholz 写道:
it's difficult to use llvm tools like sanitizers on openjdk sources,
because of the "cheating" - relying on undefined behavior, and the JIT.
On Wed,
it's difficult to use llvm tools like sanitizers on openjdk sources,
because of the "cheating" - relying on undefined behavior, and the JIT.
On Wed, Sep 5, 2018 at 6:09 PM, Leslie Zhai wrote:
> Hi Martin,
>
> Thanks for your response!
>
> I haven't tested compiling OpenJDK 12-dev with LLVM toolc
Hi Martin,
Thanks for your response!
I haven't tested compiling OpenJDK 12-dev with LLVM toolchain, perhaps
the issue had been fixed already, because clang treat invalid argument
'-std=gnu++98' not allowed with 'C' as error. It is better only apply
EXTRA_CFLAGS to C without EXTRA_CXXFLAGS.
On 6/09/2018 8:13 AM, Magnus Ihse Bursie wrote:
6 sep. 2018 kl. 00:00 skrev David Holmes :
Hi Magnus,
On 5/09/2018 10:11 PM, Magnus Ihse Bursie wrote:
When I removed (mostly) all mapfiles for the JDK libraries, building of libjsig
started failing on Solaris, and that part was backed out.
He
> 6 sep. 2018 kl. 00:00 skrev David Holmes :
>
> Hi Magnus,
>
>> On 5/09/2018 10:11 PM, Magnus Ihse Bursie wrote:
>> When I removed (mostly) all mapfiles for the JDK libraries, building of
>> libjsig started failing on Solaris, and that part was backed out.
>> Here's a new, and improved soluti
Hi Magnus,
On 5/09/2018 10:11 PM, Magnus Ihse Bursie wrote:
When I removed (mostly) all mapfiles for the JDK libraries, building of
libjsig started failing on Solaris, and that part was backed out.
Here's a new, and improved solution to remove the mapfile for libjsig,
even on Solaris.
Bug:
Hi Severin,
Might as well raise this here too as it's really a build philosophy
issue. Shouldn't flags like -ffp-contract=off (and the existing AIX
-qfloat=nomaf) be toolchain specific rather than platform specific?
Thanks,
David
On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
Hi,
Cross-post
Hi Severin,
On 6/09/2018 4:36 AM, Severin Gehwolf wrote:
Hi,
On Linux x86 (32 and 64 bit) sharedRuntime{Trans,Trig}.ccp files get
compiled with -O0. It appears to be for the same (historical?) reason
as for fdlibm files in core-libs. JDK-8210416 is an attempt to make
this consistent on all Linu
looks fine.
On 05/09/2018 05:19, Magnus Ihse Bursie wrote:
As per the discussion in JDK-8056217, the file awt_makecube.cpp (which
is not compiler nor used) should be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8056217
Change:
$ hg status
R src/java.desktop/windows/native/common/awt
Hello,
On 09/05/2018 04:15 PM, joe darcy wrote:
Hello,
On 9/5/2018 6:12 AM, Severin Gehwolf wrote:
Hi,
Cross-posting this review-thread on core-libs-dev and build-dev as this
is a build change, but affects fdlibm which is core-libs.
With JDK-8170153 optimization for fdlibm code has been tur
Hello,
On 9/5/2018 6:12 AM, Severin Gehwolf wrote:
Hi,
Cross-posting this review-thread on core-libs-dev and build-dev as this
is a build change, but affects fdlibm which is core-libs.
With JDK-8170153 optimization for fdlibm code has been turned on for
ppc64 s390 and aarch64. This patch inte
So ... Magnus, are you happy with the current state of the proposed patch?
On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
>
> For the gcc toolchain this can not be the case:
> # Minimum supported linker versions, empty means unspecified
> TOOLCHAIN_MIN
On 09/05/2018 06:51 PM, Erik Joelsson wrote:
It was pointed out offline that I had missed some "Mercurial" in log
messages. This webrev also reintroduces the .gitignore file that was
mistakenly omitted in the last webrev.
http://cr.openjdk.java.net/~erikj/8210283/webrev.03/
Hi Erik,
thanks
Hi,
On Linux x86 (32 and 64 bit) sharedRuntime{Trans,Trig}.ccp files get
compiled with -O0. It appears to be for the same (historical?) reason
as for fdlibm files in core-libs. JDK-8210416 is an attempt to make
this consistent on all Linux arches (as s390x/ppc64/aarch64 already use
that) for fdlib
We seem to have some confusion about flags for C vs. flags for C++. Most
flags for most toolchains apply to both C and C++, so it's understandable
that we want to unify them. But some flags, notably -std, are
language-specific. We have both EXTRA_CFLAGS and EXTRA_CXXFLAGS, so we
should expect EX
Looks good to me.
/Magnus
> 5 sep. 2018 kl. 18:51 skrev Erik Joelsson :
>
> It was pointed out offline that I had missed some "Mercurial" in log
> messages. This webrev also reintroduces the .gitignore file that was
> mistakenly omitted in the last webrev.
>
> http://cr.openjdk.java.net/~eri
Looks good.
/Erik
On 2018-09-05 09:05, Andrew Haley wrote:
The JDK8u backport of 8034788 changed the variable name CXX_VERSION
(in configure) to CXX_VERSION_NUMBER. Unfortunately this was not done
consistently, and as a result the version number check for GCC is
broken. As a result of that bro
Looks good to me.
/Erik
On 2018-09-05 05:19, Magnus Ihse Bursie wrote:
As per the discussion in JDK-8056217, the file awt_makecube.cpp (which
is not compiler nor used) should be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8056217
Change:
$ hg status
R src/java.desktop/windows/nat
Looks good.
/Erik
On 2018-09-05 05:12, Magnus Ihse Bursie wrote:
"make dist-clean" leaves build.log and configure.log behind, as well
as the rotated .old files.
Bug: https://bugs.openjdk.java.net/browse/JDK-8081858
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8081858-fix-dist-clean/webrev.0
Hello,
Looks good to me.
/Erik
On 2018-09-05 05:11, Magnus Ihse Bursie wrote:
When I removed (mostly) all mapfiles for the JDK libraries, building
of libjsig started failing on Solaris, and that part was backed out.
Here's a new, and improved solution to remove the mapfile for libjsig,
eve
Looks good, thanks!
/Erik
On 2018-09-05 04:42, Maurizio Cimadamore wrote:
Here's the modified webrev - as suggested, I replaced /tmp/replacement
with $1.tmp
http://cr.openjdk.java.net/~mcimadamore/8210318_v2/
Thanks
Maurizio
On 04/09/18 18:50, Erik Joelsson wrote:
Hello,
$TARGET was jus
On 2018-09-05 04:03, Baesken, Matthias wrote:
Hello, when compilingjdk/jdk on Windows, (with VS2017 update level 15.8
and not disabling warnings as errors )
I came across this warning leading to build error :
C:/jdk-just-clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(
It was pointed out offline that I had missed some "Mercurial" in log
messages. This webrev also reintroduces the .gitignore file that was
mistakenly omitted in the last webrev.
http://cr.openjdk.java.net/~erikj/8210283/webrev.03/
/Erik
On 2018-09-04 16:27, Erik Joelsson wrote:
New webrev: h
On Wed, 2018-09-05 at 17:05 +0100, Andrew Haley wrote:
> The JDK8u backport of 8034788 changed the variable name CXX_VERSION
> (in configure) to CXX_VERSION_NUMBER. Unfortunately this was not done
> consistently, and as a result the version number check for GCC is
> broken. As a result of that brok
Hi Andrew,
I think I did that, so must have gone macro-blind by that point. Yes,
looks good to me.
Thanks
Kevin
On 05/09/2018 17:05, Andrew Haley wrote:
The JDK8u backport of 8034788 changed the variable name CXX_VERSION
(in configure) to CXX_VERSION_NUMBER. Unfortunately this was not done
The JDK8u backport of 8034788 changed the variable name CXX_VERSION
(in configure) to CXX_VERSION_NUMBER. Unfortunately this was not done
consistently, and as a result the version number check for GCC is
broken. As a result of that brokenness, HotSpot built on all GCC
versions >=6 is unstable.
Int
With jdk10 repos you should be using solstudio 12.4.
The changes were added to jdk11 repos to begin support
for solstudio 12.6, but there are some additional patches
needed in solstudio 12.6 to be able to build openjdk.
Hopefully those issues will be resolved for the next jdk release.
On 9/5/18,
Hello,
I am sure I am doing something wrong, but having build problems with
OpenJDK under Solaris.
Error:
# gmake
Building target 'default (exploded-image)' in configuration
'solaris-x86_64-normal-server-release'
Creating support/modules_libs/java.base/libjsig.so from 1 file(s)
Compiling 8 f
Thanks Magnus!
And sorry, I mistakenly thought I did reply ☹
- Derek
> -Original Message-
> From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf Of
> Magnus Ihse Bursie
> Sent: Wednesday, September 05, 2018 5:26 AM
> To: David Holmes
> Cc: build-dev
> Subject: Re: RFR
> On Sep 5, 2018, at 5:07 AM, Magnus Ihse Bursie
> wrote:
> We do set SHELL to bash for make, so it *should* be running command lines
> using bash.
Verifying that was why I made this suggestion:
In your build directory, in ./configure-support/config.log, search for
the line starting with "
On 05/09/2018 13:58, Magnus Ihse Bursie wrote:
The file sdp.conf.template is copied only when building for solaris,
but it resides in the unix source directory.
SDP is legacy now and we should probably think about removing it, esp.
with the rsocket support in the works.
In the mean time, as th
Hi,
Cross-posting this review-thread on core-libs-dev and build-dev as this
is a build change, but affects fdlibm which is core-libs.
With JDK-8170153 optimization for fdlibm code has been turned on for
ppc64 s390 and aarch64. This patch intends to turn it on on all arches
on Linux. I've not obse
The file sdp.conf.template is copied only when building for solaris, but
it resides in the unix source directory.
Bug: https://bugs.openjdk.java.net/browse/JDK-8059019
Patch inline:
diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy-java.base.gmk
--- a/make/copy/Copy-java.base.gmk
+++ b/
As per the discussion in JDK-8056217, the file awt_makecube.cpp (which
is not compiler nor used) should be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8056217
Change:
$ hg status
R src/java.desktop/windows/native/common/awt_makecube.cpp
/Magnus
"make dist-clean" leaves build.log and configure.log behind, as well as
the rotated .old files.
Bug: https://bugs.openjdk.java.net/browse/JDK-8081858
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8081858-fix-dist-clean/webrev.01
/Magnus
When I removed (mostly) all mapfiles for the JDK libraries, building of
libjsig started failing on Solaris, and that part was backed out.
Here's a new, and improved solution to remove the mapfile for libjsig,
even on Solaris.
Bug: https://bugs.openjdk.java.net/browse/JDK-8200609
WebRev:
http
On 2018-09-05 13:42, Maurizio Cimadamore wrote:
Here's the modified webrev - as suggested, I replaced /tmp/replacement
with $1.tmp
http://cr.openjdk.java.net/~mcimadamore/8210318_v2/
Looks good to me.
/Magnus
Thanks
Maurizio
On 04/09/18 18:50, Erik Joelsson wrote:
Hello,
$TARGET was j
Here's the modified webrev - as suggested, I replaced /tmp/replacement
with $1.tmp
http://cr.openjdk.java.net/~mcimadamore/8210318_v2/
Thanks
Maurizio
On 04/09/18 18:50, Erik Joelsson wrote:
Hello,
$TARGET was just pseudo code. In your case it's $1.tmp.
/Erik
On 2018-09-04 10:34, Maurizi
On 5/09/2018 7:25 PM, Magnus Ihse Bursie wrote:
A ping on this webrev...
I've not seen a single thumbs up. :(
David: The arm64 port is now officially on it's way out. [1] I hope that
makes you feel confident that the build documentation changes does not
have to mention it.
Yes.
Thanks,
Dav
Hello, when compilingjdk/jdk on Windows, (with VS2017 update level 15.8
and not disabling warnings as errors )
I came across this warning leading to build error :
C:/jdk-just-clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
error C2220: warning treated as error - no '
On 2018-09-05 11:33, Aleksey Shipilev wrote:
On 09/05/2018 11:25 AM, Magnus Ihse Bursie wrote:
A ping on this webrev...
Oh, I thought is was done. Had to walk around the thread to look for the link.
This webrev?
Bug: https://bugs.openjdk.java.net/browse/JDK-8182733
WebRev:
http://cr.op
Hi Andrew,
Thanks for your response!
I just quote it from here:
http://mail.openjdk.java.net/pipermail/build-dev/2016-July/017464.html
I spotted that jsig is just a single C file and so doesn't
need the -std flag. In fact, it complains about it:
Compiling jsig.c (for libjsig.so)
( ( /usr/bin/
On 09/05/2018 11:25 AM, Magnus Ihse Bursie wrote:
> A ping on this webrev...
Oh, I thought is was done. Had to walk around the thread to look for the link.
This webrev?
Bug: https://bugs.openjdk.java.net/browse/JDK-8182733
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8182733-update-aarch64-
A ping on this webrev...
I've not seen a single thumbs up. :(
David: The arm64 port is now officially on it's way out. [1] I hope that
makes you feel confident that the build documentation changes does not
have to mention it.
/Magnus
[1] http://openjdk.java.net/jeps/340
On 2018-08-03 03:02
On 2018-09-05 09:49, Zambonifofex wrote:
Hello. It seems to work fine on Bash. On Fish, I get the following error:
fish: Unsupported use of '&&'. In fish, please use 'COMMAND; and COMMAND'.
cd
/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjv
On Wed, 2018-09-05 at 07:38 +1000, David Holmes wrote:
> On 5/09/2018 7:29 AM, Erik Joelsson wrote:
> > On 2018-09-04 14:06, David Holmes wrote:
> > > Hi Severin,
> > >
> > > On 5/09/2018 1:36 AM, Severin Gehwolf wrote:
> > > > Hi,
> > > >
> > > > Could I please get reviews of this JDK 8-only cha
Hello. It seems to work fine on Bash. On Fish, I get the following error:
fish: Unsupported use of '&&'. In fish, please use 'COMMAND; and COMMAND'.
cd
/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs
&& \
On 2018-08-22 17:45, Ioi Lam wrote:
Looks like it's this command that failed:
cd
/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs
&& \
/usr/bin/nm --defined-only *.o | /usr/bin/nawk '{ if ($3 ~
/^_ZTV|^gHotSpotVM|^UseSharedSpaces$|^_ZN9Argu
On 2018-09-04 04:56, Kim Barrett wrote:
On Aug 21, 2018, at 11:45 PM, Zambonifofex wrote:
Hello.
I’ve run the following commands (using the Fish shell):
It might be nothing, but this caught my eye. Are you using fish as
your shell when trying to configure / build? Maybe that doesn't work?
Tha
On 2018-08-22 02:24, Ioi Lam wrote:
I am not sure if this is documented anywhere. Try searching for "Error
2". It usually will tell you where the error is.
There's an entire section named "Locating the Source of the Error" in
doc/building.md. It's worth reading to be proficient in finding and
You’re right, sorry. I haven’t been around OpenJDK for some weeks and forgot
about posting to build-dev when posting.
I will push in around 2-3 hours, currently on a train.
Adrian
> On Sep 5, 2018, at 9:05 AM, Magnus Ihse Bursie
> wrote:
>
>> On 2018-09-04 23:29, David Holmes wrote:
>> Hi Ad
Hi Magnus,
Thanks for your kind response!
在 2018年09月05日 14:40, Magnus Ihse Bursie 写道:
On 2018-09-05 06:03, Leslie Zhai wrote:
Hi all,
Thanks for Aleksandar Beserminji great job:
https://reviews.llvm.org/D50437
It is not easy to reproduce the LLVMBUG-38221[1] by building
OpenJDK8, it need
On 2018-09-04 17:49, Erik Joelsson wrote:
On 2018-09-03 00:19, David Holmes wrote:
On 30/08/2018 10:36 PM, Magnus Ihse Bursie wrote:
Hi folks,
This bug report goes all the way back to 2008. :-) So instead of
just letting it go on to it's second decade of existence, I went
about and fixed it.
On 2018-09-04 23:29, David Holmes wrote:
Hi Adrian,
All changes that touch the build system must be reviewed by build-dev
- now cc'd.
This has been discussed at some length in build-dev. But I agree, it's
good that also the actual RFR is cc:ed here.
The patch, unsurprisingly, LGTM.
/Magnus
On 2018-09-05 01:27, Erik Joelsson wrote:
New webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.02/
Looks good to me.
/Magnus
Fixed the comment in SourceRevision.gmk.
Added an SCM identifier in the string so a typical .src-rev file now
looks like this:
.:hg:3f189f451ff1+
or like
55 matches
Mail list logo
