Re: gcc, arm, and thumbs mode

Kozlov wrote: > Hi Thomas, > > On 5/27/22 16:12, Thomas Stüfe wrote: > > P.S. I found one possible solution for my particular problem was to add > > `.type function` to the static assembler routine. That caused gcc to use > > the correct jump instruction (blx instea

Re: gcc, arm, and thumbs mode

(cited the wrong JBS issue, the correct one is https://bugs.openjdk.java.net/browse/JDK-8284997) On Fri, May 27, 2022 at 3:12 PM Thomas Stüfe wrote: > Hi, > > I am investigating the arm-specific problem > https://bugs.openjdk.java.net/browse/JDK-8283326. It looks like the >

gcc, arm, and thumbs mode

Hi, I am investigating the arm-specific problem https://bugs.openjdk.java.net/browse/JDK-8283326. It looks like the error is caused by arm- and thumb-code interleaving: GCC-compiled code, in thumb mode, calls into a static assembler subroutine that has been compiled into arm mode, but the caller

Re: RFR: 8284752: Zero does not build on Mac OS X due to missing os::current_thread_enable_wx implementation

Hi Magnus, On Wed, Apr 13, 2022 at 1:23 PM Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > On 2022-04-12 15:21, David Holmes wrote: > > On Tue, 12 Apr 2022 11:31:03 GMT, Johannes Bechberger < > d...@openjdk.java.net> wrote: > > > >> Adds an implementation of the missing method

Re: Failing jdk11u AIX build on Adoptium servers

Hi Matthias, On Thu, Mar 24, 2022 at 4:55 PM Baesken, Matthias wrote: > Hi , > > > > >My expected course of action is as follows: > >- Bump the minimum requirements in our Supported Builds document > >[https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms] > >- Open an issue

Re: Failing jdk11u AIX build on Adoptium servers

cc build-dev. Hi Tyler, makes sense to me. Wrt the documentation, probably we should change the minimum requirement of jdk12 too then. Cheers, Thomas On Thu, Mar 24, 2022 at 4:05 PM Tyler Steele wrote: > Hi all, > > In regards to the new Harfbuzz version bump (and the work done to prepare

Re: Supporting alternative toolchains on Windows

As Dalibor wrote, I would not expect too many performance surprises. That said, a more pragmatic approach may be to create a shim layer for visual studio compiler and linker, e.g. a fake "cl.exe" and "link.exe" that translate VC++ options and paths to whatever toolchain you like. That way you

Re: JDK-8282532

Hi Jules, On Wed, Mar 2, 2022 at 1:29 PM Jules W. wrote: > Apologies for not creating a thread consulting the mailing list before > submitting the PR, I'm still getting used to the process (And also thought > this would create unnecessary noise for people within this list). > On the contrary,

Re: GHAs and precompiled headers

On Mon, Jan 24, 2022 at 10:31 AM Aleksey Shipilev wrote: > On 1/24/22 10:26 AM, Thomas Stüfe wrote: > > > > > > On Mon, Jan 24, 2022 at 10:15 AM Aleksey Shipilev <mailto:sh...@redhat.com>> wrote: > > > > On 1/24/22 8:43 AM, Thomas Stüfe wrote: >

Re: GHAs and precompiled headers

On Mon, Jan 24, 2022 at 10:15 AM Aleksey Shipilev wrote: > On 1/24/22 8:43 AM, Thomas Stüfe wrote: > > We generally build without --disable-precompiled-headers in GHAs, which > > hides errors from missing includes. Since GHAs are very useful to test > > builds on

GHAs and precompiled headers

Hi, We generally build without --disable-precompiled-headers in GHAs, which hides errors from missing includes. Since GHAs are very useful to test builds on side platforms, would it not make sense to build without precompiled headers? Or is that too costly? Thanks, Thomas

Re: gtest test targets fail with "Unknown test selection: 'gtest'" on jdk15-17

Hi Abigail, at some point (it may have been JDK 15, I am not sure atm) we stopped including the google test framework in our repo and instead require the builder to provide it externally. See configure option "--with-gtest". Must point to a copy of the googletest framework (

Re: Does CDS archive generation work for crossbuilds?

Hi Alan, On Sat, Oct 23, 2021 at 9:58 AM Alan Bateman wrote: > > > On 23/10/2021 07:57, Thomas Stüfe wrote: > > Hi, > > > > when I crossbuild (for linux aarch64, using a devkit, building on linux > > x64), for some reason I don't > > get the classes.js

Does CDS archive generation work for crossbuilds?

Hi, when I crossbuild (for linux aarch64, using a devkit, building on linux x64), for some reason I don't get the classes.jsa generated inside the images directory. My configure options: --with-devkit=/shared/projects/openjdk/devkits/x86_64-linux-gnu-to-aarch64-linux-gnu

Re: CMake replacing Autotools?

On Fri, Mar 19, 2021 at 2:39 PM wrote: > On 2021-03-19 03:14, Thomas Stüfe wrote: > > On Fri, Mar 19, 2021 at 11:04 AM Andrew Haley wrote: > > > >> On 3/19/21 9:22 AM, Thomas Stüfe wrote: > >>>> 2. More choices to actually build the project: Use integr

Re: CMake replacing Autotools?

On Fri, Mar 19, 2021 at 11:04 AM Andrew Haley wrote: > On 3/19/21 9:22 AM, Thomas Stüfe wrote: > >> 2. More choices to actually build the project: Use integrated build > >> tools of IDEs (Visual Studio, Xcode) or use Ninja, which is faster than > >> gmake > >

Re: CMake replacing Autotools?

Hi Christoph, On Fri, Mar 19, 2021 at 12:01 AM Christoph Grüninger wrote: > Hi Magnus, > > for sure, I am going to do CMake cheerleading. > > I think OpenJDK would profit from a change to CMake: > > 1. Less tools required for building: CMake + gmake/Ninja/msbuild/Xcode > instead of Autotools

gtest-specific defines?

Hi, Sometimes one needs access to hotspot internals only for the sake of gtests. At the moment there is no define which tells me whether I build with gtests or not, so I add those interfaces unconditionally, with a "only for gtests" comment. I wonder whether it makes sense to add a define which

Re: [External] : Re: AArch64 OpenJDK bootstrap failure on head

(dropping Andrew and Aleksey) On Tue, Feb 2, 2021 at 6:13 PM Ioi Lam wrote: > > > On 2/2/21 1:32 AM, Thomas Stüfe wrote: > > > > On Mon, Feb 1, 2021 at 10:11 PM Ioi Lam wrote: > >> On 2/1/21 9:36 AM, Thomas Stüfe wrote: >> >> This does not solve the a

Re: AArch64 OpenJDK bootstrap failure on head

On Mon, Feb 1, 2021 at 10:11 PM Ioi Lam wrote: > On 2/1/21 9:36 AM, Thomas Stüfe wrote: > > This does not solve the alignment problem, but I don't like that we > unconditionally print a message here since this is a non-fatal error. Also, > CDS mapping may fail for other reasons,

Re: AArch64 OpenJDK bootstrap failure on head

This does not solve the alignment problem, but I don't like that we unconditionally print a message here since this is a non-fatal error. Also, CDS mapping may fail for other reasons, for which we do not print unconditionally. I think we should make this info log level: ---

Re: RFR: 8258477: Pre-submit testing using GitHub Actions should merge changes from target branch

On Wed, Dec 16, 2020 at 3:20 PM Robin Westberg wrote: > Hi Thomas, > > > On 16 Dec 2020, at 14:54, Thomas Stüfe wrote: > > > > Hi Robin, > > > > does this mean tests won't run on branches which cannot be merged with > the > > assumed target br

Re: RFR: 8258477: Pre-submit testing using GitHub Actions should merge changes from target branch

Hi Robin, does this mean tests won't run on branches which cannot be merged with the assumed target branch? Thanks, Thomas On Wed, Dec 16, 2020 at 11:55 AM Robin Westberg wrote: > Normally when running GitHub Actions on a pull request, what is checked > out is the merge of the pull request

gh actions fail on linux x64 when fetching libsound

Hi, all my linux x64 gh builds fail with: "E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/a/alsa-lib/libasound2-dev_1.2.2-2.1ubuntu2.1_amd64.deb 404 Not Found [IP: 52.147.219.192 80]" https://github.com/tstuefe/jdk/runs/1452221121 Does anyone have an idea? Thanks,

Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow

Hi Bernhard, just some drive-by comments. - 40-50 min builds seem to be excessive for just the hotspot build, do you know what exactly takes that long? Is this for release and debug each or both combined? - Is it worth the cycles to build both release *and* debug? How probable is it that a

Re: RFR: 8256414: add optimized build to submit workflow [v2]

t; > On Nov 16, 2020, at 12:43 PM, Thomas Stüfe > wrote: > >  > > Hi, > > just curious, was the optimized build not earmarked for removal? I dimly > remember reading discussions about this. > > Thanks, Thomas > > On Mon, Nov 16, 2020 at 9:35 PM Daniel D.Daugher

Re: RFR: 8256414: add optimized build to submit workflow [v2]

Hi, just curious, was the optimized build not earmarked for removal? I dimly remember reading discussions about this. Thanks, Thomas On Mon, Nov 16, 2020 at 9:35 PM Daniel D.Daugherty wrote: > On Mon, 16 Nov 2020 19:29:59 GMT, Igor Ignatyev > wrote: > > >> Marked as reviewed by shade

Re: Why do we export "JVM_handle_xxx_signal"?

de it. We > should probably drop the JVM_ prefix, since this function is not > declared in jvm.h. > > Thanks > - Ioi > > On 10/29/20 9:02 AM, Thomas Stüfe wrote: > > Hi, > > > > Does anyone know why we explicitly export JVM_handle_bsd_signal and > >

Why do we export "JVM_handle_xxx_signal"?

Hi, Does anyone know why we explicitly export JVM_handle_bsd_signal and JVM_handle_linux_signal (the latter also accidentally from symbols-aix)? These functions are not even the real signal handler, just an internal function; the signal handler is "javaSignalHandler", but that one is not

Re: RFR(S) : 8245610 : remove in-tree copy on gtest

On Mon, Jun 8, 2020 at 3:14 PM Erik Joelsson wrote: > On 2020-06-07 23:56, Thomas Stüfe wrote: > > Also, it may be me, but where do I find the official build > > documentation? Googling "building openjdk" gives me a number of hits, > > neither one seems officia

Re: RFR(S) : 8245610 : remove in-tree copy on gtest

s' private cr directory :) but since it does not mention google test at all I don't think this is recent. Thanks, Thomas On Mon, Jun 1, 2020 at 6:01 PM Thomas Stüfe wrote: > Hi Magnus, > > On Mon, Jun 1, 2020 at 1:35 PM Magnus Ihse Bursie < > magnus.ihse.bur...@oracle.com> wrote:

Re: RFR(S) : 8245610 : remove in-tree copy on gtest

Hi Magnus, On Mon, Jun 1, 2020 at 1:35 PM Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > > > On 2020-05-29 07:04, Thomas Stüfe wrote: > > Hi Igor, > > thank you for taking the time to answer my grumblings. > > Yes, comparison with jtreg is a bit

Re: RFR(S) : 8245610 : remove in-tree copy on gtest

convenience it causes to > you, yet given you need to download gtest only once and it's fairly easy to > hide `with-gtest` behind a script or an alias like configure_openjdk='bash > ./configure --with-gtest=$GTEST_HOME', I hope it won't cause problems for > you and won't discourage

Re: RFR(S) : 8245610 : remove in-tree copy on gtest

Hi, I know the boat has sailed, I missed this one. But I am a bit unhappy about this. I always build with gtests; I think it makes no sense to not build with gtest. Even if you do not want to run the gtests (and it makes sense to always do since its a good first-base validity test), hotspot

Re: RFR: JDK-8244966: Add .vscode to .hgignore

LGTM. Cheers, Thomas On Sat, May 16, 2020 at 1:34 AM Lemmond, Dan wrote: > Hi, > > This is my first review request so apologies for any missteps or > inconsistencies. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244966 > Webrev: http://cr.openjdk.java.net/~phh/8244966/webrev.01/ > >

Re: RFR: 8199138: Add RISC-V support to Zero

Looks still good. ..Thomas On Tue 7. Apr 2020 at 01:20, John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello! > > On 4/6/20 8:09 PM, John Paul Adrian Glaubitz wrote: > > I have reduced the complexity of the patch as some of the changes from > > the previous change set are

Re: RFR: 8199138: Add RISC-V support to Zero

Hi Adrian, looks good to me. Cheers, Thomas On Mon, Apr 6, 2020, 20:11 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello! > > Please review this small change which adds basic support for the riscv64 > target for Linux/Zero [1]. > > I have reduced the complexity of the

Re: RFR [11u] 8232572: Add hooks for custom output dir in Bundles.gmk

LGTM. ..Thomas On Mon, Mar 9, 2020 at 2:57 PM Langer, Christoph wrote: > Hi, > > please review this Oracle parity backport. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232572 > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/ae0af9fb3dbb > Webrev:

Re: JLI_Launch has mangled name in jli.dll when building for win32

Hi Robert, This means that the function is using the __stdcall calling convention. I do not know whether this is correct or not, but caller and callee have to agree on the calling convention used, so the prototype for that function used when compiling the caller code must have been declared with

Re: AIX xlc16 options langlvl=c99vla / langlvl=noredefmac is not supported

I think this is fine for 14. Cheers, Thomas On Mon, Jul 8, 2019 at 9:23 AM Baesken, Matthias wrote: > Hello, when building jdk/jdk on AIX (using the current default > xlc16) I get a ton of warnings : > > warning: 1540-5200 The option "langlvl=c99vla" is not supported. > warning:

Re: RFR: [XS] 8227171: provide function names in native stack trace on aix with xlc16

It's trivial IMHO. Ship it. On Thu, Jul 4, 2019, 09:30 Baesken, Matthias wrote: > Hello, any more reviews ? > > May I push the change ? > > > > Best regards, Matthias > > > > > > > > *From:* Thomas Stüfe > *Sent:* Mittwoch, 3. Juli 2019 14

Re: RFR: [XS] 8227171: provide function names in native stack trace on aix with xlc16

Looks good and trivial. Thanks for fixing. ..Thomas On Wed, Jul 3, 2019 at 2:02 PM Baesken, Matthias wrote: > Hello please review this small fix for AIX (needed with the new xlc16) . > > Currently we miss function names in the hs_err file : > > 0x000115098660 - 0x09000f629a4c

Re: [8u] RFR: 8210761: libjsig is being compiled without optimization

On Wed, Jun 26, 2019 at 2:27 PM Severin Gehwolf wrote: > On Wed, 2019-06-26 at 14:21 +0200, Thomas Stüfe wrote: > > > > One curious question though about the original bug, was this really a > > measurable performance issue? I would have thought that libjsig is > &g

Re: [8u] RFR: 8210761: libjsig is being compiled without optimization

I'd be okay with doing this on AIX if Christoph is. One curious question though about the original bug, was this really a measurable performance issue? I would have thought that libjsig is not invoked often enough for this to make a difference.. Cheers, Thomas On Wed, Jun 26, 2019 at 2:05 PM

Re: RFR: 8224087: Compile C code for at least C99 Standard compliance

Hi David, Thank you for doing this, this looks all very good. I wish though we had a clear whitelist of features to use or blacklist for features to avoid. Most developers do not use Windows as a primary platform, so it will always be a surprise whether Windows breaks in submit tests. I am also

Re: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC

On Fri, Apr 5, 2019 at 10:51 AM David Holmes wrote: > Hi Thomas, > > On 5/04/2019 6:23 pm, Thomas Stüfe wrote: > > Hi, > > > > sorry, just sniping in from the side. > > > > About the motivation: the original intent of Yasumasas patch was to > >

Re: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC

p.s.: Review is at hs-runtime-dev: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-March/033150.html . On Fri, Apr 5, 2019 at 10:23 AM Thomas Stüfe wrote: > Hi, > > sorry, just sniping in from the side. > > About the motivation: the original intent of

Re: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC

Hi, sorry, just sniping in from the side. About the motivation: the original intent of Yasumasas patch was to reduce the length of the event log messages. I have a patch out there for RFR, since ~2 weeks or so, which largely solves this problem: https://bugs.openjdk.java.net/browse/JDK-8220762

Re: [OpenJDK 2D-Dev] [13] RFR: JDK-8217707: JNICALL declaration breaks Splash screen functions

Looks fine. Cheers, Thomas On Thu, Mar 28, 2019 at 5:11 PM Alexey Ivanov wrote: > Any volunteers for review? > > On 24/03/2019 19:18, Alexey Ivanov wrote: > > Hi, > > > > Please review the fix for jdk 13. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8217707 > > webrev:

Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows

(at least shell tests) > that will not work properly. > > /Erik > On 2019-01-16 00:49, Thomas Stüfe wrote: > > Hi guys, > > Just wanted to know what the state is. Did you already add the support for > WSL or is this still WIP? If it should work, is there a documentation &

Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows

Hi guys, Just wanted to know what the state is. Did you already add the support for WSL or is this still WIP? If it should work, is there a documentation somewhere I could follow? Thank you! Thomas On Sat, Dec 22, 2018 at 4:55 AM Andrew Luo < andrewluotechnolog...@outlook.com> wrote: > Just

Re: RFR(XS): 8214063: [AIX] Disable symbol visibility flags

On Tue, Nov 27, 2018 at 4:35 PM Volker Simonis wrote: > > Hi, > > can I please have a review for the following trivial change which > simply disables the symbol visibility flags on AIX: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/ >

Re: RFR(S): 8214343: Handle the absence of Xrandr more generically

Looks good Volker. I agree, NO_XRANDR is reasonable and better than HAVE_XRANDR. I have to say, the amount of work this took is insane for the size of the problem involved. Cheers, Thomas On Tue, Nov 27, 2018 at 2:54 PM Volker Simonis wrote: > > Hi, > > can I please have a review for the

Re: [OpenJDK 2D-Dev] RFR(XS): 8213944: Fix AIX build after the removal of Xrandr.h and add a configure check for it

Side note, I wondered whether IBM does anything original in their openj9 (the jdk parts they forked off OpenJDK) since they are targetting AIX too and must be having the same build error. But I cannot find anything they did: --- thomas@t450:/shared/projects/openjdk/j9/openj9-openjdk-jdk$ git log

Re: bash completion for make targets

:) Thank you Magnus! On Wed, Nov 21, 2018 at 1:03 PM Magnus Ihse Bursie wrote: > > On 2018-11-20 14:30, Thomas Stüfe wrote: > > > Hi Magnus, > > > > The problem did vanish for me. Tab completion works again in all my > > configurations. On zero, which I do n

Re: RFR(XS): 8214120: [REDO] Fix sun.awt.nativedebug on X11 platforms

Hi Volker, looks good to me. Lets wait for jdk-submit though - especially since you changed linking on Windows too by adding JNIEXPORT. Gruss Thomas On Tue, Nov 20, 2018 at 6:13 PM Volker Simonis wrote: > > Hi, > > so here's a reworked version of my previous change: > >

Re: bash completion for make targets

with that version too, so either this was a local fluke or it was fixed before 8213736. Cheers, Thomas On Tue, Nov 20, 2018 at 12:56 PM Magnus Ihse Bursie wrote: > > On 2018-11-08 12:20, Thomas Stüfe wrote: > > On Thu, Nov 8, 2018 at 12:13 PM Magnus Ihse Bursie > > wrote: > &

Re: (trivial, urgent) RFR(xxs): 8214075: [BACKOUT] 8214007: Fix sun.awt.nativedebug on X11 platforms

Thanks guys. I pushed. ..Thomas On Mon, Nov 19, 2018 at 10:21 PM David Holmes wrote: > > On 20/11/2018 7:17 am, Thomas Stüfe wrote: > > p.s. does this need a jdk-submit run? > > No. Please push. If there are any issues I'll follow up. > > Thanks, > David >

Re: (trivial, urgent) RFR(xxs): 8214075: [BACKOUT] 8214007: Fix sun.awt.nativedebug on X11 platforms

p.s. does this need a jdk-submit run? I'm about to call it a day, and since jdk-submit takes 4-6 hours, that would mean someone else would have to push the fix. ..Thomas On Mon, Nov 19, 2018 at 10:13 PM Thomas Stüfe wrote: > > Hi all, > > may I please have a quick review. We wan

(trivial, urgent) RFR(xxs): 8214075: [BACKOUT] 8214007: Fix sun.awt.nativedebug on X11 platforms

Hi all, may I please have a quick review. We want to backout 8214007 for now since it breaks Solaris. https://bugs.openjdk.java.net/browse/JDK-8214075 http://cr.openjdk.java.net/~stuefe/webrevs/8214075-backout-8214007/webrev.00/webrev/ Thanks, Thomas

Re: [OpenJDK 2D-Dev] RFR(XS): 8213944: Fix AIX build after the removal of Xrandr.h and add a configure check for it

FWIW I am very much in favor of (1) and if aesthetics are a problem in awt_GraphicsEnv.c, a "HAVE_XRANDR" define would make things a bit prettier... just my 2c. On Mon, Nov 19, 2018 at 6:58 PM Volker Simonis wrote: > > Hi Phil, > > I'd like to kindly ask you to suggest how we can proceed with

Re: RFR: 8213591 : running bin/idea.sh in Cygwin: generated project cannot be imported - was : RE: bin/idea.sh and Cygwin

pushed. On Wed, Nov 14, 2018 at 9:11 AM Baesken, Matthias wrote: > > HI Michal , tested on my Windows 10 machine , works nicely ! > > Best regards, Matthias > > > > -Original Message- > > From: Michal Vala > > Sent: Montag, 12. November 2018 05:2

Re: RFR: 8213591 : running bin/idea.sh in Cygwin: generated project cannot be imported - was : RE: bin/idea.sh and Cygwin

this? > > Also I'd like to ask someone to sponsor this, as I'm just an author. > > > On 11/9/18 7:09 PM, Thomas Stüfe wrote: > > Hi Michal, > > > > I tested this and it now works nicely for me (win7, vs2017, with > > current jdk/jdk). > > > > Ch

Re: RFR: 8213591 : running bin/idea.sh in Cygwin: generated project cannot be imported - was : RE: bin/idea.sh and Cygwin

replaced by empty string. Sure that it's not acceptable. > > Anyway, JT_HOME should be only variable that can be empty. > > new webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8213591/webrev.02/ > > On 11/9/18 5:42 PM, Thomas Stüfe wrote: > > On Fri, Nov 9, 2018 at 5:35 PM

Re: RFR: 8213591 : running bin/idea.sh in Cygwin: generated project cannot be imported - was : RE: bin/idea.sh and Cygwin

On Fri, Nov 9, 2018 at 5:35 PM Thomas Stüfe wrote: > > Hi Michal, > > does not yet work for me. I get cygpath Usage output: > > $ bash ./bin/idea.sh > Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME... >cygpath [-c HANDLE] >cygpath [-AD

Re: RFR: 8213591 : running bin/idea.sh in Cygwin: generated project cannot be imported - was : RE: bin/idea.sh and Cygwin

Hi Michal, does not yet work for me. I get cygpath Usage output: $ bash ./bin/idea.sh Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME... cygpath [-c HANDLE] cygpath [-ADHOPSW] cygpath [-F ID] Convert Unix and Windows format paths, or output system path

Re: windows cygwin version test too strict

Please ignore all my mails. My repository was just off. I did a fresh re-clone, now all is fine. Thanks, Thomas On Fri, Nov 9, 2018 at 4:13 PM Thomas Stüfe wrote: > > ..bypassing this version check yields a similar error later on, where > a more modern GNUmake is not accepted: >

Re: windows cygwin version test too strict

it in the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. ..Thomas On Fri, Nov 9, 2018 at 4:09 PM Thomas Stüfe wrote: > > Hi all, > > When running configure on Windows, I get now: > > configure: Your cygwin is too old. You are running 2.11.2(0.329/5/3), >

windows cygwin version test too strict

Hi all, When running configure on Windows, I get now: configure: Your cygwin is too old. You are running 2.11.2(0.329/5/3), but at least cygwin 1.7 is required. Please upgrade. When looking at basics_windows.m4: CYGWIN_VERSION_OK=`$ECHO $CYGWIN_VERSION | $GREP ^1.7.` if test

Re: bash completion for make targets

On Thu, Nov 8, 2018 at 12:13 PM Magnus Ihse Bursie wrote: > > On 2018-11-08 12:10, Thomas Stüfe wrote: > > > Hi all, > > > > This may be a stupid question, and not that important, but bash > > completion for targets like "clean" and "images"

bash completion for make targets

Hi all, This may be a stupid question, and not that important, but bash completion for targets like "clean" and "images" stopped working for me. "reconfigure" still works thouugh. Did anything change? Best Regards, Thomas

Re: RFR(XS): 8213515: Improve freetype detection on linux/ppc64/ppc64le/s390x

+1 Gruss Thomas On Thu, Nov 8, 2018 at 10:25 AM Volker Simonis wrote: > > Hi, > > can I please have a review for the following trivial enhancement of > the freetype detection on linux/ppc64/ppc64le/s390x: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8213515/ >

Re: RFR: JDK-8213428: Add a no preocmpiled header Linux build to builds-tier1 and jdk-submit

Hi Erik, I cannot comment on the fix, but thanks for doing this! Best Regards, Thomas On Tue, Nov 6, 2018 at 7:06 PM Erik Joelsson wrote: > > A recent discussion on build-dev brought out the need for jdk-submit to > include a build with precompiled headers disabled. We currently have > such

Re: RFR: JDK-8213339 Update precompiled.hpp with headers based on current frequency

Hi David, On Sun, Nov 4, 2018 at 11:09 PM David Holmes wrote: > > On 4/11/2018 5:27 PM, Magnus Ihse Bursie wrote: > > > >> 3 nov. 2018 kl. 23:24 skrev David Holmes : > >> > >>> On 3/11/2018 10:09 PM, David Holmes wrote: > >>> Looks okay - thanks for doing all the experiments! (Though I'm still

Re: Stop using precompiled headers for Linux?

Hi Magnus, your winning variant gives me a nice boost on my thinkpad: pch, standard: real17m52.367s user52m20.730s sys 4m53.711s pch, your variant: real15m0.514s user46m6.466s sys 2m38.371s (non-pch is ~19-20 minutes WTC) With those numbers, I might start using pch

Re: Stop using precompiled headers for Linux?

On Thu, Nov 1, 2018 at 12:05 PM Magnus Ihse Bursie wrote: > > On 2018-11-01 11:54, Aleksey Shipilev wrote: > > On 11/01/2018 11:43 AM, Magnus Ihse Bursie wrote: > >> But then again, it might just signal that the list of headers included in > >> the PCH is no longer > >> optimal. If it used to be

Re: Stop using precompiled headers for Linux?

It would help already if Oracle would disable precompiled headers for the submit test builds. ..Thomas On Tue, Oct 30, 2018 at 6:26 PM Ioi Lam wrote: > > Is there any advantage of using precompiled headers on Linux? It's on by > default and we keep having breakage where someone would forget to

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

Hi Kim, On Mon, Oct 8, 2018 at 8:32 PM Kim Barrett wrote: > > > On Oct 8, 2018, at 6:48 AM, Thomas Stüfe wrote: > > > > Hi Kim, > > > > is this JEP only about C++14 features or shall we discuss older > > features too? The reason I am asking is that I

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

Hi Kim, is this JEP only about C++14 features or shall we discuss older features too? The reason I am asking is that I would like us to officially endorse namespaces. Not inline namespaces, just plain old namespaces. HotSpot makes very limited use of namespaces. Not really true, we already use

Re: RFR : 8211146 : fix problematic elif-tests after recent gcc warning changes Werror=undef

Thanks for clarifying! Thomas On Wed, Sep 26, 2018, 14:20 Baesken, Matthias wrote: > Hi Thomas, I think your understanding is correct : > > "#ifdef " > > or > > "#if defined()" > > Are ok while > > "#if " > > or > > "#elif " > > Lead to the compile error on gcc with current warnings. > >

Re: RFR : 8211146 : fix problematic elif-tests after recent gcc warning changes Werror=undef

On Wed, Sep 26, 2018 at 11:51 AM, Alan Bateman wrote: > > > On 26/09/2018 10:24, Baesken, Matthias wrote: >> >> >> Hello, please review this small build fix . >> >> After the recent changes to the gcc compile flags with 8211029, >> most of our Linux builds stopped working . >> >> Error

Re: RFR: 8210647: libsaproc is being compiled without optimization.

;> On Sep 18, 2018, at 2:08 AM, Thomas Stüfe wrote: >> >> Hi Severin, >> >> I get reproducable build errors with your fix on my machine (Ubuntu 16.4). >> >> When I build release (no special build options), I get: >> >> /shared/projects/openjdk/

Re: RFR: 8210647: libsaproc is being compiled without optimization.

Hi Severin, On Tue, Sep 18, 2018 at 11:24 AM, Severin Gehwolf wrote: > Hi Thomas, > > On Tue, 2018-09-18 at 11:08 +0200, Thomas Stüfe wrote: >> Hi Severin, >> >> I get reproducable build errors with your fix on my machine (Ubuntu 16.4). >> >> When I buil

Re: RFR: 8210647: libsaproc is being compiled without optimization.

Hi Severin, I get reproducable build errors with your fix on my machine (Ubuntu 16.4). When I build release (no special build options), I get: /shared/projects/openjdk/jdk-jdk/source/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c: In function ‘read_exec_segments’:

Re: defpath extension won't work with jdk/submit

Thank you Tim! Should I find time, I may look at it too more closely. In the meantime, your workaround works fine, thanks. Have nice vacations! ..Thomas On Mon, Sep 3, 2018 at 5:32 PM, Tim Bell wrote: > On 09/03/18 07:25, Thomas Stüfe wrote: >> >> Hi guys, >> >> th

Re: defpath extension won't work with jdk/submit

anymore? Thank you, Best Regards, Thomas On Wed, Aug 29, 2018 at 8:49 AM, Thomas Stüfe wrote: > Adding the push path manually to hgrc works fine, so I use that as a > workaround. > > Thanks, Thomas > > On Wed, Aug 29, 2018 at 8:01 AM, Thomas Stüfe wrote: >> Than

Re: defpath extension won't work with jdk/submit

Adding the push path manually to hgrc works fine, so I use that as a workaround. Thanks, Thomas On Wed, Aug 29, 2018 at 8:01 AM, Thomas Stüfe wrote: > Thank you Tim. Happy to know it is not my setup. Lets see what ops says. > > Best, Thomas > > On Wed, Aug 29, 2018 at 1:58 AM,

Re: defpath extension won't work with jdk/submit

Thank you Tim. Happy to know it is not my setup. Lets see what ops says. Best, Thomas On Wed, Aug 29, 2018 at 1:58 AM, Tim Bell wrote: > Thomas: > >> when trying to run hg defpath to set the paths to the jdk12 submit >> repo (http://hg.openjdk.java.net/jdk/submit), it fails: >> >>

defpath extension won't work with jdk/submit

Hi all, when trying to run hg defpath to set the paths to the jdk12 submit repo (http://hg.openjdk.java.net/jdk/submit), it fails: thomas@t450:/shared/projects/openjdk/jdk-submit/source$ hg defpath -du stuefe abort: http://hg.openjdk.java.net/jdk/submit: Repository not found No hgrc files

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

On Fri, Jun 22, 2018 at 1:57 PM, David Holmes wrote: > On 21/06/2018 10:37 PM, Thomas Stüfe wrote: >> >> On Thu, Jun 21, 2018 at 1:27 PM, David Holmes >> wrote: >>> >>> On 21/06/2018 10:05 AM, Martin Buchholz wrote: >>>> >>

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

On Thu, Jun 21, 2018 at 1:27 PM, David Holmes wrote: > On 21/06/2018 10:05 AM, Martin Buchholz wrote: >> >> 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

Re: RFR(xxs): 8205407: [windows, vs<2017] C4800 after 8203197

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üf

Re: RFR(xxs): 8205407: [windows, vs<2017] C4800 after 8203197

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

Re: RFR(xxs): 8205407: [windows, vs<2017] C4800 after 8203197

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/bro

Re: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

Looks good to me, Volker. Thank you for fixing the tests. ..Thomas On Mon, Jun 18, 2018 at 6:04 PM, Volker Simonis wrote: > On Mon, Jun 18, 2018 at 8:17 AM, David Holmes wrote: >> Hi Volker, >> >> src/hotspot/share/runtime/globals.hpp >> >> This change should not be needed! We do minimal VM

Re: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

Hi Volker, On Fri, Jun 15, 2018 at 10:05 AM, Volker Simonis wrote: > On Thu, Jun 14, 2018 at 9:04 PM, Thomas Stüfe wrote: >> Hi Volker, >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/make/autoconf/hotspot.m4.udiff.html >> >> Seems like a

Re: RFR: 8205091: AIX: build errors in hotspot after 8203641: Refactor String Deduplication into shared

Hi Matthias, Good catch. Patch for me is good if you guys agree on a good uncommon name. Gruß Thomas On Fri, Jun 15, 2018, 09:48 Baesken, Matthias wrote: > Please review this small change that fixes the AIX build after > "8203641: Refactor String Deduplication into shared". > > We are

Re: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

Hi Volker, http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/make/autoconf/hotspot.m4.udiff.html Seems like a roundabout way to have a platform specific default value. Why not determine a default value beforehand: if test "x$OPENJDK_TARGET_OS" = "xaix"; then ENABLE_CDS_DEFAULT="false"

Re: RFR(xs): 8204935: [aix] TOC overflow in libjvm.so (release build)

Thank you Magnus. On Wed, Jun 13, 2018 at 3:40 PM, Magnus Ihse Bursie wrote: > Looks good to me. > > /Magnus > >> 13 juni 2018 kl. 10:28 skrev Thomas Stüfe : >> >> Thank you Matthias! >> >> I'll wait for someone from the Oracle Build Group to have a say.

Re: RFR(xs): 8204935: [aix] TOC overflow in libjvm.so (release build)

t; -Original Message- >> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- >> boun...@openjdk.java.net] On Behalf Of Thomas Stüfe >> Sent: Mittwoch, 13. Juni 2018 08:14 >> To: build-dev ; ppc-aix-port- >> d...@openjdk.java.net >> Subject: RFR(xs): 8204935:

  1   2   3   >