On Tue, 27 Oct 2020 06:29:54 GMT, Aleksey Shipilev wrote:
>>> My rationale is simple: I am playing the whack-a-mole against the ongoing
>>> x86_32 regressions here
>>
>> Would it be possible that we add a Travis hook so that commits get tested
>> once before they are merged?
>>
>> Travis supp
> John Paul Adrian Glaubitz mentions "x32" is actually the designation for
> "x86_64 with 32-bit pointers". Let's rename "Linux x32" to "Linux x86". I
> also realized that JDK-8254282 missed "Linux x32" for the platform selection.
> While you can guess it is accepted from reading the workflow, i
On Tue, 27 Oct 2020 06:24:32 GMT, John Paul Adrian Glaubitz
wrote:
> > My rationale is simple: I am playing the whack-a-mole against the ongoing
> > x86_32 regressions here
>
> Would it be possible that we add a Travis hook so that commits get tested
> once before they are merged?
Maybe, but
On Tue, 27 Oct 2020 05:48:49 GMT, Aleksey Shipilev wrote:
> My rationale is simple: I am playing the whack-a-mole against the ongoing
> x86_32 regressions here
Would it be possible that we add a Travis hook so that commits get tested once
before they are merged?
Travis supports all of the imp
On Mon, 26 Oct 2020 22:16:50 GMT, Magnus Ihse Bursie wrote:
>> Following JDK-8254282, it seems useful to also run tier1 tests on 32-bit
>> platform, because that finds problems with runtime tests and internal
>> asserts. Those problems do not show up during the plain build. Again, while
>> x86
On Mon, 26 Oct 2020 22:14:24 GMT, Magnus Ihse Bursie wrote:
> And frankly, I don't understand why this is a separate bug, instead of a part
> of JDK-8255305. Can you please explain the rationale for that? If you just
> want to make additional changes to JDK-8255305, there is really no need to
On Fri, 23 Oct 2020 10:04:49 GMT, Aleksey Shipilev wrote:
> Following JDK-8254282, it seems useful to also run tier1 tests on 32-bit
> platform, because that finds problems with runtime tests and internal
> asserts. Those problems do not show up during the plain build. Again, while
> x86_32 mi
On Mon, 26 Oct 2020 18:53:53 GMT, John Paul Adrian Glaubitz
wrote:
>> I realized that JDK-8254282 missed "Linux x32" for the platform selection.
>> While you can guess it is accepted from reading the workflow, it would be
>> more convenient to have it in the default argument list.
>
> Note tha
On Mon, 26 Oct 2020 18:45:31 GMT, Aleksey Shipilev wrote:
> I realized that JDK-8254282 missed "Linux x32" for the platform selection.
> While you can guess it is accepted from reading the workflow, it would be
> more convenient to have it in the default argument list.
Note that "Linux x32" is
I realized that JDK-8254282 missed "Linux x32" for the platform selection.
While you can guess it is accepted from reading the workflow, it would be more
convenient to have it in the default argument list.
-
Commit messages:
- 8255412: Add "Linux x32" to platform selection default
Following JDK-8254282, it seems useful to also run tier1 tests on 32-bit
platform, because that finds problems with runtime tests and internal asserts.
Those problems do not show up during the plain build. Again, while x86_32 might
not be widely deployed by itself, but 32/64 bit cleanliness dete
On Mon, 26 Oct 2020 09:45:16 GMT, Magnus Ihse Bursie wrote:
>> BTW the value of coreautolf flag is asked during the installation of Git for
>> windows, it is should be mentioned in the docs, since it is quite common
>> issue.
>
> @jddarcy Recommended new wording:
> Suggestion:
>
> * Clon
Sorry for being late on this one (I'm working through a huge backlog),
but it does not seem like the removal was complete.
ENABLE_INTREE_EC is still present in spec.gmk. And it is still checked
in modules/jdk.crypto.ec/Lib.gmk. In fact, this entire file should be
removed.
Anthony, can you pl
On Mon, 26 Oct 2020 11:37:52 GMT, Magnus Ihse Bursie wrote:
>> Since I found it close to impossible to review the changes when I could not
>> get a diff with the changes done to hsdis.c/cpp, I created a webrev which
>> shows these changes. I made this by renaming hsdis.cpp back to hsdis.c, and
On Mon, 26 Oct 2020 11:16:28 GMT, Magnus Ihse Bursie wrote:
>>> @navyxliu
>>>
>>> > @luhenry I tried to build it with LLVM10.0.1
>>> > on my x86_64, ubuntu, I ran into a small problem. here is how I build.
>>> > $make ARCH=amd64 CC=/opt/llvm/bin/clang CXX=/opt/llvm/bin/clang++
>>> > LLVM=/opt/l
On Fri, 23 Oct 2020 17:18:57 GMT, Aleksey Shipilev wrote:
> Currently, we are only archiving `build/*/test-results`. But hs_errs,
> replays, and test outputs are actually in `build/*/test-support`! Which means
> once any test fails, we only have the summary of the run, not the bits that
> woul
On Thu, 8 Oct 2020 20:40:50 GMT, Xin Liu wrote:
>> @navyxliu
>>
>>> @luhenry I tried to build it with LLVM10.0.1
>>> on my x86_64, ubuntu, I ran into a small problem. here is how I build.
>>> $make ARCH=amd64 CC=/opt/llvm/bin/clang CXX=/opt/llvm/bin/clang++
>>> LLVM=/opt/llvm/
>>>
>>> I can't
On Sat, 24 Oct 2020 08:35:31 GMT, Aleksey Shipilev wrote:
> The output for the `prerequisites` step is `bundle_id: ${{
> steps.check_bundle_id.outputs.bundle_id }}`, but there is no
> `check_bundle_id` step name to properly reference. Then `artifacts` should
> actually need `prerequisites` to
On Fri, 23 Oct 2020 16:21:53 GMT, Jan Lahoda wrote:
>> This is an update to javac and javadoc, to introduce support for Preview
>> APIs, and generally improve javac and javadoc behavior to more closely
>> adhere to JEP 12.
>>
>> The notable changes are:
>>
>> * adding support for Preview API
On Sat, 24 Oct 2020 08:35:31 GMT, Aleksey Shipilev wrote:
> The output for the `prerequisites` step is `bundle_id: ${{
> steps.check_bundle_id.outputs.bundle_id }}`, but there is no
> `check_bundle_id` step name to properly reference. Then `artifacts` should
> actually need `prerequisites` to
On Mon, 7 Sep 2020 10:05:25 GMT, Sergey Bylokhov wrote:
>> doc/building.md line 92:
>>
>>> 90: spaces and/or mixed upper and lower case letters.
>>> 91:
>>> 92: * Clone the JDK repository using [Git for
>>> Windows](https://gitforwindows.org).
>>
>> I think I said before, this i
On Mon, 19 Oct 2020 10:34:32 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the third incubation round
>> of the foreign memory access API incubation (see JEP 393 [1]). This
>> iteration focus on improving the usability of the API in 3 main ways:
>>
>> * f
On Mon, 26 Oct 2020 08:22:47 GMT, Aleksey Shipilev wrote:
>> Currently, we are only archiving `build/*/test-results`. But hs_errs,
>> replays, and test outputs are actually in `build/*/test-support`! Which
>> means once any test fails, we only have the summary of the run, not the bits
>> that
> Currently, we are only archiving `build/*/test-results`. But hs_errs,
> replays, and test outputs are actually in `build/*/test-support`! Which means
> once any test fails, we only have the summary of the run, not the bits that
> would actually help to diagnose the problem.
>
> Archiving the
On Mon, 26 Oct 2020 08:11:47 GMT, Robin Westberg wrote:
>> Aleksey Shipilev has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove duplicate PATH item
>>
>>Co-authored-by: Robin Westberg
>> - Remove duplicate PATH item
>>
On Fri, 23 Oct 2020 17:18:57 GMT, Aleksey Shipilev wrote:
> Currently, we are only archiving `build/*/test-results`. But hs_errs,
> replays, and test outputs are actually in `build/*/test-support`! Which means
> once any test fails, we only have the summary of the run, not the bits that
> woul
On Sat, 24 Oct 2020 08:35:31 GMT, Aleksey Shipilev wrote:
> The output for the `prerequisites` step is `bundle_id: ${{
> steps.check_bundle_id.outputs.bundle_id }}`, but there is no
> `check_bundle_id` step name to properly reference. Then `artifacts` should
> actually need `prerequisites` to
27 matches
Mail list logo
