Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v4]
On Wed, 12 Apr 2023 07:12:10 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 incrementally with four additional > commits since the last revision: > > - Restore visCPP > - Restore gcc attribute > - Revert gcc > - Revert Bumping - PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1598236477
Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v4]
On Wed, 12 Apr 2023 07:12:10 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 incrementally with four additional > commits since the last revision: > > - Restore visCPP > - Restore gcc attribute > - Revert gcc > - Revert Anyone? - PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1582065715
Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v4]
On Wed, 12 Apr 2023 07:12:10 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 incrementally with four additional > commits since the last revision: > > - Restore visCPP > - Restore gcc attribute > - Revert gcc > - Revert Bumping - PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1578994674
Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v4]
On Wed, 12 Apr 2023 07:12:10 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 incrementally with four additional > commits since the last revision: > > - Restore visCPP > - Restore gcc attribute > - Revert gcc > - Revert Well, that's unfortunate - PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1542279520
Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v4]
On Wed, 12 Apr 2023 07:12:10 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 incrementally with four additional > commits since the last revision: > > - Restore visCPP > - Restore gcc attribute > - Revert gcc > - Revert > What is the purpose of removing `defined(_MSC_VER)` from the conditionals? Is > this to allow for other compilers that similarly only ensure 4 byte alignment > of the stack? If so, it would have been nice to mention that separate concern > in the PR description, rather than making reviewers guess. And do such > compilers actually exist? A bit of research suggests gcc (at least) maintains > 16 byte alignment (and may warrant the use of -mstackrealign or other hoops). > See, for example, [uTox/uTox#1304](https://github.com/uTox/uTox/issues/1304). Admittedly I wasn't sure what the alignment specifier here was for either, but assumed that it was something that was simply required for Windows code, and since _MSC_VER is always the only compiler (for now) that can compile Windows code, the check seemed pretty pointless. It seemed logical then that even if another compiler was added to the mix Windows code would still be under said ABI restrictions, hence the removal of that conditional. I'm now no longer as certain that this is always the case and can revert those changes if that check turns out to be correct > Is `defined(_WIN32)` really the right conditional? That's true for pretty > much any Visual Studio supported target, both 32bit and 64bit. But the > alignment spec is effectively a nop for 64bit platforms, so harmless. Perhaps, since this pretty much specifies that only Windows code should be affected by the alignment (Irrespective of this change). Others might disagree here, though > I was pretty confused by the C changes for a while, since I didn't know or > had forgotten that the 32bit Windows ABI only guarantees 4 byte stack > alignment, and permits "misaligned" local variables for types such as long > long and double. (And I failed to find any definitive documentation for > that.) Yuck! Haha, that's Microsoft for you ;) - PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1504786534
Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v4]
> 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 incrementally with four additional commits since the last revision: - Restore visCPP - Restore gcc attribute - Revert gcc - Revert - Changes: - all: https://git.openjdk.org/jdk/pull/13258/files - new: https://git.openjdk.org/jdk/pull/13258/files/07f5c702..e63d5938 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=02-03 Stats: 9 lines in 3 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13258/head:pull/13258 PR: https://git.openjdk.org/jdk/pull/13258
