> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
On Mon, 25 Mar 2024 09:02:22 GMT, Magnus Ihse Bursie wrote:
> > The only thing I'm uncertain about is the pData local, which I don't see
> > much benefit in removing since the null check associated with it still has
> > to remain for code semantics to be correct
>
> The point is that you can
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
On Mon, 25 Mar 2024 08:59:08 GMT, Magnus Ihse Bursie wrote:
>> I don't think I can commit this as there are 3 backticks at the end there :P
>
> Apologies. The point was that this was formatting changes that were not
> needed and should be reverted.
I know, I did want to commit your change
On Mon, 25 Mar 2024 09:15:21 GMT, Magnus Ihse Bursie wrote:
> > A question about the licensing: how long does it take to finish the legal
> > process of the sleef licence?
>
> I am not sure this is a relevant question anymore. As I said, the libsleef
> build system seems virtually impossible
On Mon, 25 Mar 2024 09:24:16 GMT, Magnus Ihse Bursie wrote:
> > > But that raises an interesting question. What happens if you try to load
> > > a library compiled with `-march=armv8-a+sve` on a non-SVE system? Is the
> > > ELF flagged to require SVE so it will fail to load? I'm hoping this is
On Mon, 25 Mar 2024 15:40:45 GMT, Aleksey Shipilev wrote:
> When doing [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960), I
> missed the case when sysroot would be restored from the cache. This would
> skip the configure and build steps, because it would only consult the status
> for
On Mon, 25 Mar 2024 15:40:45 GMT, Aleksey Shipilev wrote:
> When doing [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960), I
> missed the case when sysroot would be restored from the cache. This would
> skip the configure and build steps, because it would only consult the status
> for
On Mon, 25 Mar 2024 15:40:45 GMT, Aleksey Shipilev wrote:
> When doing [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960), I
> missed the case when sysroot would be restored from the cache. This would
> skip the configure and build steps, because it would only consult the status
> for
On Mon, 25 Mar 2024 15:40:45 GMT, Aleksey Shipilev wrote:
> When doing [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960), I
> missed the case when sysroot would be restored from the cache. This would
> skip the configure and build steps, because it would only consult the status
> for
On Mon, 25 Mar 2024 15:40:45 GMT, Aleksey Shipilev wrote:
> When doing [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960), I
> missed the case when sysroot would be restored from the cache. This would
> skip the configure and build steps, because it would only consult the status
> for
When doing [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960), I missed
the case when sysroot would be restored from the cache. This would skip the
configure and build steps, because it would only consult the status for
create-sysroot job. This is only a problem when PR gets tested the
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1], then added
>> some minor changes
On Fri, 22 Mar 2024 17:09:16 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8328680](https://bugs.openjdk.org/browse/JDK-8328680), making the same
> kind of cleanup to java.base. Some code needed more special treatment here,
> so there is some additional effects outside of the
On Fri, 22 Mar 2024 17:09:16 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8328680](https://bugs.openjdk.org/browse/JDK-8328680), making the same
> kind of cleanup to java.base. Some code needed more special treatment here,
> so there is some additional effects outside of the
On Thu, 21 Mar 2024 06:58:43 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any use of the "DLL_ENTRY", so I removed it.
>>
>>
On Thu, 21 Mar 2024 06:58:43 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any use of the "DLL_ENTRY", so I removed it.
>>
>>
On Thu, 21 Mar 2024 16:57:40 GMT, Aleksey Shipilev wrote:
> Noticed this while fixing other GHA issues.
>
> We pass build JDK to cross-compilation jobs, which makes them dependent on
> Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS
> there is no need for build JDK,
On Fri, 22 Mar 2024 14:18:39 GMT, Aleksey Shipilev wrote:
>> Noticed this while fixing other GHA issues.
>>
>> We pass build JDK to cross-compilation jobs, which makes them dependent on
>> Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS
>> there is no need for build
On Fri, 22 Mar 2024 14:18:39 GMT, Aleksey Shipilev wrote:
>> Noticed this while fixing other GHA issues.
>>
>> We pass build JDK to cross-compilation jobs, which makes them dependent on
>> Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS
>> there is no need for build
On Mon, 25 Mar 2024 11:27:17 GMT, Robbin Ehn wrote:
> src/java.base/share/native/libzip/zlib/zconf.h:# define ZEXPORT
> __declspec(dllexport)
zlib is third party source that is copied into our repo. I did not mean that
what I said for that applies to it. (Also, we should not really export
On Mon, 25 Mar 2024 09:12:19 GMT, Magnus Ihse Bursie wrote:
> (In fact, I think we have a problem everywhere in the code base where someone
> is using `__declspec(dllexport)` directly)
src/java.base/share/native/libzip/zlib/zconf.h:# define ZEXPORT
__declspec(dllexport)
ZEXPORT is
On Fri, 22 Mar 2024 14:18:39 GMT, Aleksey Shipilev wrote:
>> Noticed this while fixing other GHA issues.
>>
>> We pass build JDK to cross-compilation jobs, which makes them dependent on
>> Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS
>> there is no need for build
On Fri, 22 Mar 2024 15:30:35 GMT, Hamlin Li wrote:
> > But that raises an interesting question. What happens if you try to load a
> > library compiled with `-march=armv8-a+sve` on a non-SVE system? Is the ELF
> > flagged to require SVE so it will fail to load? I'm hoping this is the case
> >
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1], then added
>> some minor changes
On Fri, 22 Mar 2024 15:27:07 GMT, Hamlin Li wrote:
> A question about the licensing: how long does it take to finish the legal
> process of the sleef licence?
I am not sure this is a relevant question anymore. As I said, the libsleef
build system seems virtually impossible to integrate into
On Fri, 22 Mar 2024 15:22:57 GMT, Hamlin Li wrote:
> For ACLE, it's supported in [10.1](https://gcc.gnu.org/gcc-10/changes.html)
Do this PR require ACLE?
-
PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2017530218
On Sat, 23 Mar 2024 09:42:33 GMT, Andrew Haley wrote:
> And neither should we compile or link it with "-fvisibility=hidden". That is
> the root of this problem.
If you suggest that we should not compile hsdis with hidden visibility, I
disagree. I have been working hard on unifying build of
On Thu, 21 Mar 2024 06:58:43 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any use of the "DLL_ENTRY", so I removed it.
>>
>>
On Mon, 25 Mar 2024 05:56:52 GMT, Julian Waters wrote:
> The only thing I'm uncertain about is the pData local, which I don't see much
> benefit in removing since the null check associated with it still has to
> remain for code semantics to be correct
The point is that you can do the null
On Mon, 25 Mar 2024 05:58:41 GMT, Julian Waters wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 1230:
>>
>>> 1228: jdouble imgY = (jdouble) ((yPixelOrg * 72)/(jdouble) yPixelRes);
>>> 1229: jdouble imgWid = (jdouble) ((imgPixelWid * 72)/(jdouble)
>>>
On Fri, 22 Mar 2024 12:27:31 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Revert Formatting in awt_Component.cpp
>> - Revert Formatting in awt_Window.cpp
>
>
On Wed, 20 Mar 2024 06:38:59 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
36 matches
Mail list logo
