Making the conversion explicit would fix it.
Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.
Therefore clang-8 and clang-9 are not affected. The flag with similar
functionality in gcc is '-Wfloat-conversion', but it is not enabled by
'-Wall' or '-Wextra'. That's why this wa
> 1. '-Wdeprecated-copy'
> As specified in C++11 [1], "the generation of the implicitly-defined
> copy constructor is deprecated if T has a user-defined destructor or
> user-defined copy assignment operator". The rationale behind is the
> well-known Rule of Three [2].
>
> Introduced since gcc-9 [3
On Mon, 4 Jan 2021 10:15:27 GMT, Hao Sun
wrote:
>> That's true on the first assignment of `t2`. But what if `t2` is reassigned
>> to some other iterator. That assignment sees `_vdui` true, and keeps the old
>> value of `_last` rather than updating the value from that other iterator. Is
>> that r
On Wed, 6 Jan 2021 03:14:48 GMT, Hao Sun
wrote:
>> node.hpp changes seems fine.
>> Passed tier1 builds and testing.
>
>> > I think the two issues described here are distinct and should be dealt
>> > with in separate bugs and PRs. Their only relation is that both arise
>> > with using clang-10. B
On Tue, 5 Jan 2021 18:35:07 GMT, Vladimir Kozlov wrote:
>> Hao Sun has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update the copy constructors for class DUIterator, DUIterator_Fast and
>> DUIterator_Last
>>
>> 1. Update copyright
On Wed, 6 Jan 2021 02:19:51 GMT, Joe Darcy wrote:
> Updating to the symbol files for JDK 16 b30; change generated with the script
>
> make/scripts/generate-symbol-data.sh
>
> The change to the java.desktop module looks to be for JDK-8258373.
Marked as reviewed by iris (Reviewer).
---
Updating to the symbol files for JDK 16 b30; change generated with the script
make/scripts/generate-symbol-data.sh
The change to the java.desktop module looks to be for JDK-8258373.
-
Commit messages:
- 8258143: Update --release 16 symbol information for JDK 16 build 30 or later
This patch changes how the docs-reference make target behaves to better support
the requirements for it. This target is used to generate javadocs in a more
stable way between releases, so that they those docs are better suited for
generating diffs between releases. Currently we use the boot JDK
On Tue, 5 Jan 2021 03:44:10 GMT, Hao Sun
wrote:
>> 1. '-Wdeprecated-copy'
>> As specified in C++11 [1], "the generation of the implicitly-defined
>> copy constructor is deprecated if T has a user-defined destructor or
>> user-defined copy assignment operator". The rationale behind is the
>> well
On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun
wrote:
> From the error log we can see the root cause is that, develop_pd flag
> 'pd_CICompileOSR' is undeclared in zero build.
>
> Where this flag is used?
> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
> of 'compiler_globals.
On Tue, 5 Jan 2021 14:28:14 GMT, Hao Sun
wrote:
>> Marked as reviewed by jiefu (Committer).
>
> Thanks for your reviews! @DamonFool @iklam @shipilev
>
> The pre-submit tests were passed except the GC one which is not related to
> this patch. I suppose this patch is ready to be merged now.
Sp
On Tue, 5 Jan 2021 12:03:05 GMT, Jie Fu wrote:
>> Hao Sun has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Header 'runtime/globals_shared.hpp' should be kept
>>
>> Header 'runtime/globals_shared.hpp' is kept even though
>> 'compile
On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun
wrote:
>> From the error log we can see the root cause is that, develop_pd flag
>> 'pd_CICompileOSR' is undeclared in zero build.
>>
>> Where this flag is used?
>> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
>> of 'compiler_glo
On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun
wrote:
>> From the error log we can see the root cause is that, develop_pd flag
>> 'pd_CICompileOSR' is undeclared in zero build.
>>
>> Where this flag is used?
>> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
>> of 'compiler_glo
On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun
wrote:
>> From the error log we can see the root cause is that, develop_pd flag
>> 'pd_CICompileOSR' is undeclared in zero build.
>>
>> Where this flag is used?
>> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
>> of 'compiler_glo
On Tue, 5 Jan 2021 00:12:58 GMT, Ioi Lam wrote:
>>> `#include "runtime/globals_shared.hpp"` should not be removed.
>>> compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by
>>> globals_shared.hpp.
>>
>> Since globals_shared.hpp is included in compiler_globals_pd.hpp, I think
On Tue, 5 Jan 2021 12:03:39 GMT, Hao Sun
wrote:
>> From the error log we can see the root cause is that, develop_pd flag
>> 'pd_CICompileOSR' is undeclared in zero build.
>>
>> Where this flag is used?
>> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
>> of 'compiler_glo
> From the error log we can see the root cause is that, develop_pd flag
> 'pd_CICompileOSR' is undeclared in zero build.
>
> Where this flag is used?
> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'.
>
On Tue, 5 Jan 2021 04:54:32 GMT, Hao Sun
wrote:
> The tests were finished but one of them failed. I found that this failure
> existed for several days (in other PRs) and I suppose it's not related to our
> patch.
Yes, the failure you caught does not look related to this PR.
-
PR
On Tue, 5 Jan 2021 00:12:58 GMT, Ioi Lam wrote:
>>> `#include "runtime/globals_shared.hpp"` should not be removed.
>>> compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by
>>> globals_shared.hpp.
>>
>> Since globals_shared.hpp is included in compiler_globals_pd.hpp, I think
20 matches
Mail list logo
