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
On Mon, 14 Nov 2022 01:42:40 GMT, Julian Waters wrote:
>> make/autoconf/flags-cflags.m4 line 632:
>>
>>> 630: if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" =
>>> xclang; then
>>> 631: STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections
>>> -fdata-sections \
>>> 632
On Mon, 14 Nov 2022 04:14:24 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 08:01:27 GMT, David Holmes wrote:
>> I'm not sure I follow, I didn't remove anything here?
>
> 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) aft
On Mon, 14 Nov 2022 08:08:40 GMT, David Holmes wrote:
>> The ATTRIBUTE_PRINTF macros are still there, just moved in front of the
>> methods
>
> Wow I'm really having eyesight problems today! Sorry about that.
Haha, no worries
-
PR: https://git.openjdk.org/jdk/pull/11081
On Mon, 14 Nov 2022 08:28:04 GMT, Thomas Stuefe wrote:
> unfortunately, your patch will make backporting more difficult. We cannot
> downport it to older releases compiled with older compilers. But since it
> touches a lot of files it will sit smack in the middle of patch sequences,
> requirin
On Mon, 14 Nov 2022 04:14:24 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 01:39:17 GMT, Julian Waters wrote:
>> src/hotspot/share/utilities/debug.hpp line 172:
>>
>>> 170: int status, const char* detail);
>>> 171: ATTRIBUTE_PRINTF(4, 5)
>>> 172: void report_fatal(VMErrorType error_type, const char* file, int line,
>>> c
On Mon, 14 Nov 2022 01:17:38 GMT, Julian Waters wrote:
>> src/hotspot/os/windows/os_windows.hpp line 35:
>>
>>> 33: class Thread;
>>> 34:
>>> 35: static unsigned __stdcall thread_native_entry(Thread*);
>>
>> Why was this removed? This is needed to correctly specify the call sequence
>> for th
On Sun, 13 Nov 2022 22:58:11 GMT, David Holmes wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> ATTRIBUTE_SCANF
>
> src/hotspot/os/linux/os_perf_linux.cpp line 233:
>
>> 231: * Ensure that 'fmt' does _NOT_ conta
> 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
On Sun, 13 Nov 2022 23:16:47 GMT, David Holmes 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 th
On Sun, 13 Nov 2022 23:08:53 GMT, David Holmes 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 th
On Sun, 13 Nov 2022 23:07:35 GMT, David Holmes 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 th
On Sun, 13 Nov 2022 22:59:01 GMT, David Holmes 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 th
On Thu, 10 Nov 2022 06:20:41 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 that
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 compatibility with
31 matches
Mail list logo
