Looks good to me.
/Erik
On 2015-11-04 19:21, Volker Simonis wrote:
Hi,
can somebody please review and sponsor the following tiny build fix:
http://cr.openjdk.java.net/~simonis/webrevs/2015/8141416/
https://bugs.openjdk.java.net/browse/JDK-8141416
Building hotspot on certain systems results i
I suppose configure found a Cygwin-version of freetype (because I
don't think there's a pkg-config on Windows) which can not be used for
a native Windows build.
Please just follow the instructions. They should be pretty clear
(because I wrote them :) If not, please let me know what could be
improv
Sure, I'll do it. :)
/Erik
On 2015-11-05 10:26, Volker Simonis wrote:
Thanks everybody for the reviews, but I still need a sponsor because
unfortunately it is still impossible to push to the hotspot repo from
outside "The Firm" :)
On Thu, Nov 5, 2015 at 10:20 AM, Erik Joelsson wrote:
Looks
On 2015-11-05 09:19, Alan Bateman wrote:
On 05/11/2015 07:27, Magnus Ihse Bursie wrote:
The JDK launchers have been built by a macro which is using
positional arguments instead of named argument. This needs to be
fixed to be able to properly track what is happening.
Some additional TLC for
On 2015-11-04 12:34, Magnus Ihse Bursie wrote:
In the initial build-infra setup, it was possible to selectively
replace individual repos (e.g. corba). This has never been widely
used, and has not been tested or supported for a long time. It
recently turned out to be broken on hotspot.
We shou
Looks good. Nice to see that go away.
/Erik
On 2015-11-05 11:11, Magnus Ihse Bursie wrote:
On 2015-11-04 12:34, Magnus Ihse Bursie wrote:
In the initial build-infra setup, it was possible to selectively
replace individual repos (e.g. corba). This has never been widely
used, and has not been t
On 05/11/2015 07:27, Magnus Ihse Bursie wrote:
The JDK launchers have been built by a macro which is using positional
arguments instead of named argument. This needs to be fixed to be able
to properly track what is happening.
Some additional TLC for launchers is also needed.
To verify the f
Thanks everybody for the reviews, but I still need a sponsor because
unfortunately it is still impossible to push to the hotspot repo from
outside "The Firm" :)
On Thu, Nov 5, 2015 at 10:20 AM, Erik Joelsson wrote:
> Looks good to me.
>
> /Erik
>
>
> On 2015-11-04 19:21, Volker Simonis wrote:
>>
On 2015-11-05 08:58, Erik Joelsson wrote:
This is just so nice! Only one small comment. In LauncherCommon.gmk
there are two ifeq for OS macosx. Perhaps those should be combined?
Yep, that's a good idea. I didn't notice that when I moved the
PACKAGE_PATH logic.
I just combined the two and didn'
On 05/11/2015 09:41, Magnus Ihse Bursie wrote:
If you need to do jigsaw changes, sure, just do what's needed.
However, it sounds like you still need a main class, but in addition
you also need a module. If that's the case, it seems that you could
keep the MAIN_CLASS and just add a MODULE. I
On 05/11/2015 04:19, Martin Buchholz wrote:
Alright, it's a much better situation if we're not giving up on fixing
the underlying problem.
I don't like temporary fixes. They tend to become permanent.
I agree and view this dialing down of the optimization level as
temporary until the issue i
Unfortunately, the --disable-warnings-as-errors flag only operates on
the build-infra code, and does not propagate to the Hotspot build system.
This is unfortunate, and also very confusing for users who think they
have disabled warnings as errors, only to get an error in the hotspot
build inst
Looks ok.
/Erik
On 2015-11-05 16:43, Magnus Ihse Bursie wrote:
Unfortunately, the --disable-warnings-as-errors flag only operates on
the build-infra code, and does not propagate to the Hotspot build system.
This is unfortunate, and also very confusing for users who think they
have disabled w
Hi,
I have signed the OCA and emailed a scan according the instructions. I
separated the freetype changes into a separate batch as suggested. I have
shared the patch files on OneDrive, they are my Public folder. Here’s the link
to the folder: https://onedrive.live.com/redir?resid=a243a3e0b2aaa
Currently the /WX flag is hardcoded in the Hotspot windows make files.
This makes it impossible to turn of warnings-as-errors for Windows
without explicitely hacking the makefiles. This should be fixed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8141548
WebRev:
http://cr.openjdk.java.net/~i
Looks good to me.
/Erik
On 2015-11-05 17:18, Magnus Ihse Bursie wrote:
Currently the /WX flag is hardcoded in the Hotspot windows make files.
This makes it impossible to turn of warnings-as-errors for Windows
without explicitely hacking the makefiles. This should be fixed.
Bug: https://bugs.
The follow-on issue which was filed to track the underlying issue is this:
https://bugs.openjdk.java.net/browse/JDK-8141491
As can be seen it is an alignment problem.
Brian
On Nov 5, 2015, at 4:57 AM, Alan Bateman wrote:
> On 05/11/2015 04:19, Martin Buchholz wrote:
>> Alright, it's a much be
Hi Magnus,
great that finally somebody is addressing this issue!
But shouldn't we also change the lines:
WARNINGS_ARE_ERRORS = -Werror
to:
WARNINGS_ARE_ERRORS ?= -Werror
in the various hotspot compiler files (e.g. make/linux/makefiles/gcc.make).
Maybe I'm missing something, or do you plan to
Hello,
Please review this fix for the current build break in jdk9-dev. It seems
initializing variables to the empty string in shell requires quotes.
Bug: https://bugs.openjdk.java.net/browse/JDK-8141574
Patch:
diff -r 4ba17e992008 common/autoconf/flags.m4
--- a/common/autoconf/flags.m4
+++ b/c
Looks fine; thanks,
-Joe
On 11/5/2015 2:11 PM, Erik Joelsson wrote:
Hello,
Please review this fix for the current build break in jdk9-dev. It
seems initializing variables to the empty string in shell requires
quotes.
Bug: https://bugs.openjdk.java.net/browse/JDK-8141574
Patch:
diff -r 4ba1
I've played around a bit with this today to see if we can fix the
problem and still have gcc generate the nice, vectorized loop it does
today (but without the movdqa of course), and this is what I have so far:
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.00/webrev/
I have not do
This does the same thing but is more elegant than a correct but verbose fix I
was playing with.
Would changing read_value() and write_value() into macros be better for
performance?
Thanks,
Brian
On Nov 5, 2015, at 5:04 PM, Mikael Vidstedt wrote:
> I've played around a bit with this today to
Looks okay to me.
Where do you propose to push this? Please submit via JPRT.
Thanks.
David
On 6/11/2015 2:18 AM, Magnus Ihse Bursie wrote:
Currently the /WX flag is hardcoded in the Hotspot windows make files.
This makes it impossible to turn of warnings-as-errors for Windows
without explicit
> On Nov 4, 2015, at 8:21 AM, Volker Simonis wrote:
>
> Hi,
>
> can somebody please review and sponsor the following tiny build fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8141416/
> https://bugs.openjdk.java.net/browse/JDK-8141416
>
> Building hotspot on certain systems results
Hi Magnus,
On 6/11/2015 1:43 AM, Magnus Ihse Bursie wrote:
Unfortunately, the --disable-warnings-as-errors flag only operates on
the build-infra code, and does not propagate to the Hotspot build system.
This is unfortunate, and also very confusing for users who think they
have disabled warnings
Just realized as per other RFR hotspot uses WARNINGS_ARE_ERRORS not AS
David
On 6/11/2015 5:18 PM, David Holmes wrote:
Looks okay to me.
Where do you propose to push this? Please submit via JPRT.
Thanks.
David
On 6/11/2015 2:18 AM, Magnus Ihse Bursie wrote:
Currently the /WX flag is hardco
26 matches
Mail list logo
