On Wed, 23 Nov 2022 04:58:38 GMT, Kim Barrett wrote:
>> Out of curiosity, is there a way to get the discussion on approving the use
>> of alignas back up? I've read through 8250269 briefly and unlike the issues
>> that come with C++ attributes, alignas looks relatively straightforward to
>> sw
On Tue, 29 Nov 2022 17:07:02 GMT, Julian Waters wrote:
>> Digging into this some more, the friend declaration exists to provide access
>> to the private `os::win32::enum Ept`.
>>
>> One obvious and cheap solution to that would be to make that enum public. I
>> think that would be an improveme
On Wed, 23 Nov 2022 21:36:24 GMT, Kim Barrett wrote:
>> I think the problem here is the friend declaration, which doesn't look like
>> it's needed and could be deleted.
>
> Digging into this some more, the friend declaration exists to provide access
> to the private `os::win32::enum Ept`.
>
>
On Wed, 23 Nov 2022 05:22:10 GMT, Kim Barrett wrote:
>> It's to avoid redefining the linkage as static in os_windows.cpp (where it's
>> implemented) after an extern declaration (inside the class), which is
>> forbidden by C++11:
>>
>>> The linkages implied by successive declarations for a give
On Mon, 14 Nov 2022 12:20:54 GMT, Julian Waters wrote:
>> Sorry my eyes must be playing tricks on me. ??
>>
>> Why did you need to add this here?
>
> It's to avoid redefining the linkage as static in os_windows.cpp (where it's
> implemented) after an extern declaration (inside the class), which
On Mon, 21 Nov 2022 02:43:12 GMT, Julian Waters wrote:
> Out of curiosity, is there a way to get the discussion on approving the use
> of alignas back up? [...]
A PR to address JDK-8252584 would be welcomed by me. Just do the process for
Style Guide changes (see the Style Guide or previous PRs
On Tue, 15 Nov 2022 06:33:00 GMT, Kim Barrett wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert to using simpler solution similar to the original 8274980
>
> src/hotspot/share/utilities/globalDefinitions.hpp
On Mon, 14 Nov 2022 16:12:48 GMT, Julian Waters wrote:
>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
>> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
>> code across the JDK can be replaced and simplified with cleaner language
>> features t
On Mon, 14 Nov 2022 13:06:28 GMT, Kim Barrett wrote:
>> Yep, just something that C++ does a little neater, at least in my view
>
> We (the HotSpot Group) have not discussed or approved the use of the new C++
> attribute syntax, whether for standard attributes or compiler-specific ones.
> That
On Tue, 15 Nov 2022 06:12:52 GMT, Kim Barrett wrote:
>> Reverted to use the original, less intrusive solution from
>> [8274980](https://github.com/openjdk/jdk/pull/11081/commits/83ed3deb29d7344bbc95a3831f2388d077bc59e9)
>> that initially could not work with the older Visual C++ compiler (With a
On Mon, 14 Nov 2022 08:02:49 GMT, David Holmes wrote:
>> Yep, it was renamed since the file is also named VISCPP, and I felt that
>> matching the names was a good style change
>
> I think it is the file that has the "bad" name in this case. :( But okay.
I also think the macro name should be lef
On Tue, 15 Nov 2022 00:49:59 GMT, Julian Waters wrote:
>> make/hotspot/lib/CompileJvm.gmk line 67:
>>
>>> 65: # Hotspot cannot handle an empty build number
>>> 66: VERSION_BUILD := 0
>>> 67: endif
>>
>> I think the proposed "solution" is *much* worse than this.
>
> Reverted to use the origi
On Mon, 14 Nov 2022 16:12:48 GMT, Julian Waters wrote:
>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
>> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
>> code across the JDK can be replaced and simplified with cleaner language
>> features t
On Mon, 14 Nov 2022 13:08:56 GMT, Kim Barrett wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert to using simpler solution similar to the original 8274980
>
> make/hotspot/lib/CompileJvm.gmk line 67:
>
>> 65:
> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
> code across the JDK can be replaced and simplified with cleaner language
> features that were previously not available due to required compatibili
15 matches
Mail list logo
