On Tue, 5 Dec 2023 13:00:04 GMT, Magnus Ihse Bursie wrote:
> So you need to check both the flag and the header file? Oh well, then this is
> probably as good as it gets.
Yes, we have to check both the flag and the header file.
-
PR Comment:
On Tue, 5 Dec 2023 10:35:05 GMT, Magnus Ihse Bursie wrote:
> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
> their encoding of choice when they see this locale, but use an arbitrarily
> encoding, which might not properly handle all UTF-8 characters. Since in
>
On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa wrote:
>> The goal is to develop faster sort routines for x86_64 CPUs by taking
>> advantage of AVX2 instructions. This enhancement provides an order of
>> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>>
On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa wrote:
>> The goal is to develop faster sort routines for x86_64 CPUs by taking
>> advantage of AVX2 instructions. This enhancement provides an order of
>> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>>
On Tue, 5 Dec 2023 11:19:00 GMT, Magnus Ihse Bursie wrote:
>> Hi Marcus (@magicus), please see the updated code which added guards to
>> check for GCC version >= 7.5 in
>> `src/java.base/linux/native/libsimdsort/{avx2-linux-qsort.cpp,
>> avx512-linux-qsort.cpp}`. GCC >= 7.5 is needed to
On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda wrote:
> As part of:
> https://github.com/openjdk/jdk/pull/16505
>
> there are new symbol files for JDK 22, and @jddarcy noted the content looks
> weird.
>
> I was investigating, and found a few problems, some introduced by
>
> As part of:
> https://github.com/openjdk/jdk/pull/16505
>
> there are new symbol files for JDK 22, and @jddarcy noted the content looks
> weird.
>
> I was investigating, and found a few problems, some introduced by
>
To maybe clarify things a bit; the idea here is to allow for different
values for the CompanyName RC field and the rest of the places where
"vendor-name" is currently used.
You may be wondering why? The TL:DR is; we aim to make it easier to do a
binary comparison between builds from the same
Hi Magnus,
On 05/12/2023 13:58, Magnus Ihse Bursie wrote:
So this is really a "--with-jdk-rc-vendor-name", since it will use
that value instead of --with-jdk-vendor-name for the RC fields in
Windows binaries?
I don't have a strong opinion about the name, only the target RC field
in
On Tue, 5 Dec 2023 07:21:32 GMT, Xiaohong Gong wrote:
>> also, ideally, you will add the corresponding specific overrides like in ffi:
>>
>> AC_ARG_WITH(libffi-include, [AS_HELP_STRING([--with-libffi-include],
>> [specify directory for the libffi include files])])
>>
On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On 2023-12-05 12:30, Frederic Thevenet wrote:
Hi,
I would like to propose a small enhancement to the way the VersionInfo
resources[1] embedded into native exes and dlls on Windows are
populated by the JDK build for its native components, and more
specifically, the value for the property
Hi,
I would like to propose a small enhancement to the way the VersionInfo
resources[1] embedded into native exes and dlls on Windows are
populated by the JDK build for its native components, and more
specifically, the value for the property called "Company name".
It is currently always
On Mon, 4 Dec 2023 21:27:57 GMT, Jan Lahoda wrote:
>> As part of:
>> https://github.com/openjdk/jdk/pull/16505
>>
>> there are new symbol files for JDK 22, and @jddarcy noted the content looks
>> weird.
>>
>> I was investigating, and found a few problems, some introduced by
>>
On Mon, 4 Dec 2023 22:14:14 GMT, Srinivas Vamsi Parasa wrote:
>> Then you must add logic to check for this. Now the build will just fail if
>> building with an older gcc. That is not acceptable.
>
> Hi Marcus (@magicus), please see the updated code which added guards to check
> for GCC version
We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their
encoding of choice when they see this locale, but use an arbitrarily encoding,
which might not properly handle all UTF-8 characters. Since in practice, all
our encoding is utf8, we should tell our tools this as well.
On closer inspection, it would probably be more prudential to set the
value of LC_ALL to C.UTF-8 in the build. It will likely help you with
your problem. I have published a PR at
https://github.com/openjdk/jdk/pull/16971 (JDK-8321373).
/Magnus
On 2023-11-24 13:08, Magnus Ihse Bursie wrote:
On Mon, 4 Dec 2023 21:27:57 GMT, Jan Lahoda wrote:
>> As part of:
>> https://github.com/openjdk/jdk/pull/16505
>>
>> there are new symbol files for JDK 22, and @jddarcy noted the content looks
>> weird.
>>
>> I was investigating, and found a few problems, some introduced by
>>
18 matches
Mail list logo
