On Fri, 15 Dec 2023 12:28:48 GMT, David Holmes wrote:
>From what version of glibc can we be sure that the non-64 version is exactly
>equivalent to the 64 version for all these functions?
Fortunately, support for `_FILE_OFFSET_BITS=64` making `off_t` 64-bit has been
supported for quite a long t
On Fri, 15 Dec 2023 08:08:10 GMT, Julian Waters wrote:
>> Implementation of [JEP draft: Compile the JDK as
>> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
>
> Julian Waters has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes t
On Fri, 15 Dec 2023 08:08:10 GMT, Julian Waters wrote:
>> Implementation of [JEP draft: Compile the JDK as
>> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
>
> Julian Waters has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes t
On Fri, 15 Dec 2023 08:08:10 GMT, Julian Waters wrote:
>> Implementation of [JEP draft: Compile the JDK as
>> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
>
> Julian Waters has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes t
On Fri, 15 Dec 2023 12:56:07 GMT, Julian Waters wrote:
>> It's not that it overrides the warning. They are different syntactic
>> constructs that just happen to have
>> a word in common. The joys of parsing C++ ...
>
> The keyword also happens to go in the same location as well. How
> coincid
On Fri, 15 Dec 2023 12:31:51 GMT, Kim Barrett wrote:
>> Ah, I was not aware that the asm specifications for explicit registers
>> overrides the warning about the register keyword, thanks!
>
> It's not that it overrides the warning. They are different syntactic
> constructs that just happen to
On Fri, 15 Dec 2023 11:25:24 GMT, Julian Waters wrote:
>> Looks like this change has also already been made, by JDK-8319440.
>>
>> All of the other non-comment uses of "register" I found in HotSpot are gcc
>> local variable register specifications:
>> https://gcc.gnu.org/onlinedocs/gcc-13.2.0/g
On Tue, 24 Oct 2023 01:36:32 GMT, Sam James wrote:
> The LFS64 symbols provided by glibc are not part of any standard and were
> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
> This commit replaces the usage of LFS64 symbols with their regular
> counterparts and de
On Fri, 15 Dec 2023 09:05:37 GMT, Kim Barrett wrote:
>> There are, strangely, many more register keywords in the JDK codebase than
>> just this one, but none of them throw the same errors, only this one does
>
> Looks like this change has also already been made, by JDK-8319440.
>
> All of the o
On Fri, 15 Dec 2023 08:12:47 GMT, Julian Waters wrote:
>> No problem!
>
> There are, strangely, many more register keywords in the JDK codebase than
> just this one, but none of them throw the same errors, only this one does
Looks like this change has also already been made, by JDK-8319440.
Al
On Fri, 15 Dec 2023 08:03:45 GMT, Julian Waters wrote:
>> src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp line 77:
>>
>>> 75: #define read_csr(csr) \
>>> 76: ({ \
>>> 77: unsi
> Implementation of [JEP draft: Compile the JDK as
> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull r
On Fri, 15 Dec 2023 07:48:46 GMT, Kim Barrett wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains five additional
>> commits
13 matches
Mail list logo
