On Fri, 12 Jan 2024 16:15:34 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal however, as
>> doing s
On Fri, 12 Jan 2024 18:52:46 GMT, Hannes Wallnöfer wrote:
>> This is a rather big change to update the structural navigation in API
>> documentation generated by JavaDoc. It adds a table of contents for the
>> current page to module, package, and class documentation, and replaces the
>> old su
> This is a rather big change to update the structural navigation in API
> documentation generated by JavaDoc. It adds a table of contents for the
> current page to module, package, and class documentation, and replaces the
> old sub-navigation bar with a breadcrumb-style links in those pages. T
On Fri, 12 Jan 2024 13:39:33 GMT, Matthias Baesken wrote:
> > As I mentioned above, the autoconf inserting of those compiler flags can be
> > disabled by setting ac_prog_cc_stdc and >ac_prog_cxx_stdcxx to readonly
> > empty values. It's also a workaround, but is slightly less hacky than
> > fi
On Fri, 12 Jan 2024 16:05:47 GMT, Magnus Ihse Bursie wrote:
> I'm kind of on the fence for this one. On one hand filtering out stuff is
> really hacky, but so is setting internal undocumented variables. We have done
> some meddling with internal variable in a few places before, but I'd really
On Fri, 12 Jan 2024 15:05:46 GMT, Magnus Ihse Bursie wrote:
> In [JDK-8318913](https://bugs.openjdk.org/browse/JDK-8318913), the
> symbolgenerator started to look at current sources as well. This means that
> the gensrc stage needs to be completed before this is run. A dependency was
> added f
On Fri, 12 Jan 2024 15:17:42 GMT, Per Minborg wrote:
> This PR proposes to remove the snippet files in
> `java/lang/foreign/snippet-files` from the build.
make/modules/java.base/Java.gmk line 41:
> 39: java/lang/classfile/snippet-files \
> 40: java/lang/classfile/components/snippet-fil
On Fri, 12 Jan 2024 16:15:34 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal however, as
>> doing s
On Fri, 12 Jan 2024 16:04:20 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> make/autoconf/toolchain.m4
>>
>> Co-authored-by: Magnus Ihse Bursie
>
> make/autoconf/toolchain.m4 line 35
> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
> autoconf flags being added to the command line, and solves the issue by
> filtering out the added flags by force. This is not optimal however, as doing
> so leaves the autoconf message that the flags were added still
On Fri, 12 Jan 2024 13:33:54 GMT, Julian Waters wrote:
> The only downside to that solution on the other hand is the shell will issue
> a diagnostic about writing to a readonly var. Not sure if that is an
> acceptable tradeoff
That definitely sounds worse.
-
PR Comment: https://g
On Fri, 12 Jan 2024 14:49:11 GMT, Julian Waters wrote:
> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
> autoconf flags being added to the command line, and solves the issue by
> filtering out the added flags by force. This is not optimal however, as doing
> so le
In [JDK-8318913](https://bugs.openjdk.org/browse/JDK-8318913), the
symbolgenerator started to look at current sources as well. This means that the
gensrc stage needs to be completed before this is run. A dependency was added
for jdk.compiler-gendata, but unfortunately the same tool is run also i
> From the bug report:
>
> jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file
> for erroneous and failed tests. They are also exposed under tag
> `View HotSpot error log`.
>
> I think we can do the same thing for replay files. A replay file is
> automatically generated
On Fri, 12 Jan 2024 15:26:45 GMT, Magnus Ihse Bursie wrote:
>> From the bug report:
>>
>> jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file
>> for erroneous and failed tests. They are also exposed under tag
>> `View HotSpot error log`.
>>
>> I think we can do the sam
> From the bug report:
>
> jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file
> for erroneous and failed tests. They are also exposed under tag
> `View HotSpot error log`.
>
> I think we can do the same thing for replay files. A replay file is
> automatically generated
On Fri, 12 Jan 2024 10:08:57 GMT, Magnus Ihse Bursie wrote:
> From the bug report:
>
> jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file
> for erroneous and failed tests. They are also exposed under tag
> `View HotSpot error log`.
>
> I think we can do the same thing
This PR proposes to remove the snippet files in
`java/lang/foreign/snippet-files` from the build.
-
Commit messages:
- Exclude snipet files
Changes: https://git.openjdk.org/jdk/pull/17403/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17403&range=00
Issue: https://bugs.o
On Fri, 12 Jan 2024 14:33:01 GMT, Andrew Leonard wrote:
> For gcc toolchains in ALLOW_ABSOLUTE_PATHS_IN_OUTPUT=False builds, this PR
> finds the location of the gcc system include paths, and adds
> -fdebug-prefix-map flags to map them to a standard location. Thus making the
> debuginfo and res
On Fri, 12 Jan 2024 14:47:55 GMT, Andrew Leonard wrote:
> This PR adds --with-debug-prefix-map to the building of gcc in the DevKit
> make file to map the top OUTPUT_ROOT folder to a standard "devkit" path, thus
> ensuring DevKit builds are reproducible regardless of the folder the DevKit
> is
[JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
autoconf flags being added to the command line, and solves the issue by
filtering out the added flags by force. This is not optimal however, as doing
so leaves the autoconf message that the flags were added still display
This PR adds --with-debug-prefix-map to the building of gcc in the DevKit make
file to map the top OUTPUT_ROOT folder to a standard "devkit" path, thus
ensuring DevKit builds are reproducible regardless of the folder the DevKit is
built within.
-
Commit messages:
- 8323671: DevKit
For gcc toolchains in ALLOW_ABSOLUTE_PATHS_IN_OUTPUT=False builds, this PR
finds the location of the gcc system include paths, and adds -fdebug-prefix-map
flags to map them to a standard location. Thus making the debuginfo and
resulting libraries reproducible when using DevKits in different path
On Fri, 12 Jan 2024 13:32:28 GMT, Julian Waters wrote:
>As I mentioned above, the autoconf inserting of those compiler flags can be
>disabled by setting ac_prog_cc_stdc and >ac_prog_cxx_stdcxx to readonly empty
>values. It's also a workaround, but is slightly less hacky than filtering out
>the
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote:
>> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
>> -std=gnu++11 by default to CXX in the configure process .
>> This is not really wanted so better remove / filter out those -std* flags
>> added by autoconf from CXX
On Fri, 12 Jan 2024 11:35:48 GMT, Magnus Ihse Bursie wrote:
> The grep fixes are excellent, thank you for those!
>
> The CXX filtering is a hack, and I'm slightly less happy about that. Otoh,
> the entire autoconf compiler detection stuff is so-so, and we're basically
> trying to avoid getting
On Mon, 8 Jan 2024 21:26:50 GMT, Jonathan Gibbons wrote:
>> Please review a patch to add support for Markdown syntax in documentation
>> comments, as described in the associated JEP.
>>
>> Notable features:
>>
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jd
On Mon, 8 Jan 2024 10:16:21 GMT, Matthias Baesken wrote:
> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
> -std=gnu++11 by default to CXX in the configure process .
> This is not really wanted so better remove / filter out those -std* flags
> added by autoconf from CXX .
>
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote:
>> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
>> -std=gnu++11 by default to CXX in the configure process .
>> This is not really wanted so better remove / filter out those -std* flags
>> added by autoconf from CXX
On Fri, 12 Jan 2024 10:08:57 GMT, Magnus Ihse Bursie wrote:
> From the bug report:
>
> jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file
> for erroneous and failed tests. They are also exposed under tag
> `View HotSpot error log`.
>
> I think we can do the same thing
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote:
>> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
>> -std=gnu++11 by default to CXX in the configure process .
>> This is not really wanted so better remove / filter out those -std* flags
>> added by autoconf from CXX
On Thu, 11 Jan 2024 13:04:35 GMT, Julian Waters wrote:
> I can't believe I missed something so obvious
Don't blame yourself. No-one has noticed for the at least 3 years the code has
been present. :)
-
PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-174780
>From the bug report:
jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file for
erroneous and failed tests. They are also exposed under tag
`View HotSpot error log`.
I think we can do the same thing for replay files. A replay file is
automatically generated when compiler
On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad wrote:
> JMH microbenchmarks may have dependencies on artifacts in the test image
> outside of the benchmarks.jar. This includes native libraries (built into
> `$TEST_IMAGE/micro/native`) and may soon include other test libraries like
> wb.jar (
On Thu, 11 Jan 2024 17:49:42 GMT, Erik Joelsson wrote:
> Fair enough. This isn't worse than the current CWD. The test image dir and
> the support output dir have no guaranteed relationship relative to each
> other, so we can't rely any relative path between them.
Thanks! Perhaps we can improve
On Fri, 12 Jan 2024 07:49:17 GMT, Matthias Baesken wrote:
> We at SAP use and document xlC 17.1.1.4 for jdk22 (use the same for jdk23)
> https://wiki.openjdk.org/display/Build/Supported+Build+Platforms
>
> version 17.1.1.4 is already clang15 (at least that's what the compiler output
> is telli
36 matches
Mail list logo
