Integrated: 8310863: Build failure after JDK- 8305341
On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Build failure after JDK- 8305341 This pull request has now been integrated. Changeset: 8242c647 Author:Julian Waters URL: https://git.openjdk.org/jdk/commit/8242c647b9d31320757363b69e7048a109ce86df Stats: 11 lines in 3 files changed: 0 ins; 5 del; 6 mod 8310863: Build failure after JDK- 8305341 Reviewed-by: dholmes - PR: https://git.openjdk.org/jdk/pull/14645
Re: RFR: 8310863: Build failure after JDK- 8305341
On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Build failure after JDK- 8305341 Our tier 1 builds have passed. Thanks - Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14645#pullrequestreview-1497595990
Re: RFR: JDK-8310380: Handle problems in core-related tests on macOS when codesign tool does not work [v3]
On Fri, 23 Jun 2023 08:37:16 GMT, Matthias Baesken wrote: > Chris are you okay with the latest rev. of this change? Sorry, I've been on vacation the past few days. I will have a look at it tomorrow. - PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1606661232
Re: RFR: 8294316: SA core file support is broken on macosx-x64 starting with macOS 12.x [v2]
On Fri, 23 Jun 2023 19:31:20 GMT, Tom Rodriguez wrote:
>> This is a minor fix to core file reading on macos x. I can confirm that
>> after this fix I can run the problem listed SA core file tests on Ventura.
>
> Tom Rodriguez has updated the pull request incrementally with three
> additional commits since the last revision:
>
> - Flatten nested ifs
> - Adjust ordering of message
> - Adjust printing
src/jdk.hotspot.agent/macosx/native/libsaproc/ps_core.c line 302:
> 300: // The base of the library is offset by a random amount which ends
> up as a load command with a
> 301: // filesize of 0. This must be ignored otherwise the base address
> of the library is wrong.
> 302: if (segcmd.filesize != 0 && add_map_info(ph, fd, segcmd.fileoff,
> segcmd.vmaddr, segcmd.vmsize, segcmd.flags) == NULL) {
I actually preferred this part with two `if` statements. Seems easier to read
that way.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14569#discussion_r1241570338
Re: RFR: 8310863: Build failure after JDK- 8305341
On Mon, 26 Jun 2023 04:26:47 GMT, David Holmes wrote:
> > as is evident in the tests for this PR
>
> You mean the GHA builds? They don't seem to be building the failing
> `jdk.jdwp.agent-static-libs` target.
I can't recompile the JDK at the moment to compile ArrayReferenceImpl.c, but I
can devise a simple test for this:
#include
int main() {
_Alignas(8)
int i = 7;
printf("%i", i);
return 0;
}
`cl.exe -nologo -std:c11 -Fo:align.o align.c`
align.exe
7
The _Alignas specifier does the same thing as the __declspec(align()) one, so
there's no difference in which is used (which also means that the other places
where this is used being able to compile is proof of it working as well)
-
PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606579037
Re: RFR: 8310863: Build failure after JDK- 8305341
On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Build failure after JDK- 8305341 Okay I have it running through our tier1 builds at the moment. If that passes I will approve the PR. Thanks - PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606580347
Re: RFR: 8310863: Build failure after JDK- 8305341
On Mon, 26 Jun 2023 04:23:58 GMT, Julian Waters wrote: > as is evident in the tests for this PR You mean the GHA builds? They don't seem to be building the failing `jdk.jdwp.agent-static-libs` target. - PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606573575
Re: RFR: 8310863: Build failure after JDK- 8305341
On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Build failure after JDK- 8305341 How was the original change tested? How was this change tested? - PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606571300
Re: RFR: 8310863: Build failure after JDK- 8305341
On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Build failure after JDK- 8305341 _Alignas does work on Microsoft Visual C, fortunately - PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606570803
Re: RFR: 8310863: Build failure after JDK- 8305341
On Mon, 26 Jun 2023 04:15:09 GMT, David Holmes wrote: > https://learn.microsoft.com/en-us/cpp/standard-library/cstdalign?view=msvc-170 :/ > How was the original change tested? How was this change tested? I made the mistake of testing the original on gcc instead of the native compiler for Windows, I recompiled this one with the microsoft toolchain before writing the fix, which fortunately passes the compile step as is evident in the tests for this PR Sorry for the goof :( - PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606570640 PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606572218
Re: RFR: 8310863: Build failure after JDK- 8305341
On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Microsoft, your C "conformance" is garbage https://learn.microsoft.com/en-us/cpp/standard-library/cstdalign?view=msvc-170 - PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606567568
Re: RFR: 8310863: Build failure after JDK- 8305341
On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Microsoft, your C "conformance" is garbage @dholmes-ora - PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606505881
RFR: 8310863: Build failure after JDK- 8305341
Microsoft, your C "conformance" is garbage - Commit messages: - ArrayReferenceImpl.c - GSSLibStub.c - 8310863 Changes: https://git.openjdk.org/jdk/pull/14645/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14645=00 Issue: https://bugs.openjdk.org/browse/JDK-8310863 Stats: 11 lines in 3 files changed: 0 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14645.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14645/head:pull/14645 PR: https://git.openjdk.org/jdk/pull/14645
Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v6]
On Fri, 23 Jun 2023 02:43:38 GMT, Julian Waters wrote: >> C11 has been stable for a long time on all platforms, so native code can use >> the standard alignas operator for alignment requirements > > Julian Waters has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'openjdk:master' into patch-6 > - Whitespace > - Revert > - _MSC_VER > - Restore visCPP > - Restore gcc attribute > - Revert gcc > - Revert > - Semicolon > - gcc offset_of > - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3 Filed: [JDK-8310863](https://bugs.openjdk.org/browse/JDK-8310863) - PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1606362416
Integrated: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes
On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote: > C11 has been stable for a long time on all platforms, so native code can use > the standard alignas operator for alignment requirements This pull request has now been integrated. Changeset: 78c38317 Author:Julian Waters URL: https://git.openjdk.org/jdk/commit/78c3831701667069e7e048cd56b534ae2d8d15a1 Stats: 11 lines in 3 files changed: 5 ins; 0 del; 6 mod 8305341: Alignment should be enforced by alignas instead of compiler specific attributes Reviewed-by: mdoerr - PR: https://git.openjdk.org/jdk/pull/13258
Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v6]
On Sun, 25 Jun 2023 15:58:06 GMT, Julian Waters wrote: >> Julian Waters has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 18 commits: >> >> - Merge branch 'openjdk:master' into patch-6 >> - Whitespace >> - Revert >> - _MSC_VER >> - Restore visCPP >> - Restore gcc attribute >> - Revert gcc >> - Revert >> - Semicolon >> - gcc offset_of >> - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3 > > Bumping @TheShermanTanker this is causing build failures in our CI in tier1: c:\sb\prod\1687737602\workspace\open\src\jdk.jdwp.agent\share\native\libjdwp\ArrayReferenceImpl.c(26): fatal error C1083: Cannot open include file: 'stdalign.h': No such file or directory - PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1606360752
Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v6]
On Fri, 23 Jun 2023 02:43:38 GMT, Julian Waters wrote: >> C11 has been stable for a long time on all platforms, so native code can use >> the standard alignas operator for alignment requirements > > Julian Waters has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'openjdk:master' into patch-6 > - Whitespace > - Revert > - _MSC_VER > - Restore visCPP > - Restore gcc attribute > - Revert gcc > - Revert > - Semicolon > - gcc offset_of > - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3 Marked as reviewed by mdoerr (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/13258#pullrequestreview-1497130480
Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v6]
On Fri, 23 Jun 2023 02:43:38 GMT, Julian Waters wrote: >> C11 has been stable for a long time on all platforms, so native code can use >> the standard alignas operator for alignment requirements > > Julian Waters has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'openjdk:master' into patch-6 > - Whitespace > - Revert > - _MSC_VER > - Restore visCPP > - Restore gcc attribute > - Revert gcc > - Revert > - Semicolon > - gcc offset_of > - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3 Bumping - PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1606141758
RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in ExceptionTranslation::doit
The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps. Loading it lazily can result in a loading exception, obscuring the exception being translated. To avoid this, VMSupport is loaded eagerly along with the other vmClasses. - Commit messages: - resolve VMSupport at bootstrap to avoid nested exception in ExceptionTranslation::doit Changes: https://git.openjdk.org/jdk/pull/14641/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14641=00 Issue: https://bugs.openjdk.org/browse/JDK-8310829 Stats: 19 lines in 5 files changed: 1 ins; 11 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14641.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14641/head:pull/14641 PR: https://git.openjdk.org/jdk/pull/14641
