Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update configure scripts for RISC-V in OMR (part1/misc) #4431

Merged
merged 1 commit into from Dec 7, 2019

Conversation

@ChengJin01
Copy link
Contributor

ChengJin01 commented Oct 10, 2019

The changes mainly include configure scripts
to enable RISC-V 64bit from the OMR perspective.

Issue: #4426

Signed-off-by: Cheng Jin jincheng@ca.ibm.com

@ChengJin01

This comment has been minimized.

Copy link
Contributor Author

ChengJin01 commented Oct 10, 2019

Already verified the compilation on Fedora_Linux/QEMU.

Reviewer: @keithc-ca , @pshipton , @DanHeidinga

README.md Outdated Show resolved Hide resolved
@ChengJin01 ChengJin01 force-pushed the ChengJin01:riscv_omr_part1_misc1 branch from 030aed3 to f555644 Oct 17, 2019
doc/GuideForCommitters.md Outdated Show resolved Hide resolved
AC_PROG_CXX()
# Note: Compilers have already been set up for cross-compiling in the case of RISC-V.
# Thus, the corresponding detection tests are invalid.
if test "x$OMR_CROSS_CONFIGURE" != "xyes" -o "x$OMR_HOST_ARCH" != "xriscv";

This comment has been minimized.

Copy link
@rwy0717

rwy0717 Oct 17, 2019

Member

I don't understand why it was necessary to add this test around AC_PROG_CC/CXX. As far as I know, the macros below should work fine with the risc-v cross-compile toolchain. Was there an actual issue that this is solving?

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 17, 2019

Author Contributor

I don't understand why it was necessary to add this test around AC_PROG_CC/CXX. As far as I know, the macros below should work fine with the risc-v cross-compile toolchain. Was there an actual issue that this is solving?

As explained at eclipse/openj9#5058 (comment)
This check is useless and misleading in cross-compilation as it has been checked previously in configure and there is no need to do twice.

/usr/bin/make -C omr -f run_configure.mk 'SPEC=linux_riscv64_cmprssptrs_cross' 'OMRGLUE=../gc_glue_java' 'CONFIG_INCL_DIR=../gc_glue_java/configure_includes' 'OMRGLUE_INCLUDES=../oti ../include ../gc_base ../gc_include ../gc_stats ../gc_structs ../gc_base ../include ../oti ../nls ../gc_include ../gc_structs ../gc_stats ../gc_modron_standard ../gc_realtime ../gc_trace ../gc_vlhgc' 'EXTRA_CONFIGURE_ARGS='
make[5]: Entering directory '/root/jchau/temp/RISCV_OPENJ9_v2/openj9-openjdk-jdk11/build/linux-riscv64-normal-server-release/vm/omr'
sh configure --disable-auto-build-flag 'OMRGLUE=../gc_glue_java' 'SPEC=linux_riscv64_cmprssptrs_cross'  --enable-OMRPORT_OMRSIG_SUPPORT --enable-OMR_GC --enable-OMR_PORT --enable-OMR_THREAD --enable-OMR_OMRSIG --enable-tracegen --enable-OMR_GC_ARRAYLETS --enable-OMR_GC_DYNAMIC_CLASS_UNLOADING --enable-OMR_GC_MODRON_COMPACTION --enable-OMR_GC_MODRON_CONCURRENT_MARK --enable-OMR_GC_MODRON_SCAVENGER --enable-OMR_GC_CONCURRENT_SWEEP --enable-OMR_GC_SEGREGATED_HEAP --enable-OMR_GC_HYBRID_ARRAYLETS --enable-OMR_GC_LEAF_BITS --enable-OMR_GC_REALTIME --enable-OMR_GC_VLHGC --enable-OMR_PORT_ASYNC_HANDLER --enable-OMR_THR_CUSTOM_SPIN_OPTIONS --enable-OMR_NOTIFY_POLICY_CONTROL --disable-debug 'lib_output_dir=$(top_srcdir)/../lib' 'exe_output_dir=$(top_srcdir)/..' 'GLOBAL_INCLUDES=$(top_srcdir)/../include' --enable-debug --enable-OMR_THR_THREE_TIER_LOCKING --enable-OMR_THR_YIELD_ALG --enable-OMR_THR_SPIN_WAKE_CONTROL --enable-OMRTHREAD_LIB_UNIX --enable-OMR_ARCH_RISCV --enable-OMR_ENV_LITTLE_ENDIAN --enable-OMR_PORT_CAN_RESERVE_SPECIFIC_ADDRESS --enable-OMR_GC_IDLE_HEAP_MANAGER --enable-OMR_GC_TLH_PREFETCH_FTA --enable-OMR_GC_CONCURRENT_SCAVENGER --enable-OMR_GC_ARRAYLETS --host=riscv64-unknown-linux-gnu --enable-OMR_ENV_DATA64 'OMR_TARGET_DATASIZE=64' --enable-OMR_GC_COMPRESSED_POINTERS --enable-OMR_INTERP_COMPRESSED_OBJECT_HEADER --enable-OMR_INTERP_SMALL_MONITOR_SLOT --build=x86_64-pc-linux-gnu 'OMR_CROSS_CONFIGURE=yes' 'AR=riscv64-unknown-linux-gnu-ar' 'AS=riscv64-unknown-linux-gnu-as' 'CC=riscv64-unknown-linux-gnu-gcc --sysroot=/opt/riscv_gnu_toolchain_glibc2.27_v3/sysroot' 'CXX=riscv64-unknown-linux-gnu-g++ --sysroot=/opt/riscv_gnu_toolchain_glibc2.27_v3/sysroot' 'OBJCOPY=riscv64-unknown-linux-gnu-objcopy' libprefix=lib exeext= solibext=.so arlibext=.a objext=.o 'CCLINKEXE=$(CC)' 'CCLINKSHARED=$(CC)' 'CXXLINKEXE=$(CXX)' 'CXXLINKSHARED=$(CXX)' 'OMR_HOST_OS=linux' 'OMR_HOST_ARCH=riscv' 'OMR_TOOLCHAIN=gcc' 'OMR_BUILD_TOOLCHAIN=gcc' 'OMR_TOOLS_CC=gcc' 'OMR_TOOLS_CXX=g++' 'OMR_BUILD_DATASIZE=64' 
checking build system type... x86_64-pc-linux-gnu
checking host system type... riscv64-unknown-linux-gnu
checking OMR_HOST_OS... linux
checking OMR_HOST_ARCH... riscv
checking OMR_TARGET_DATASIZE... 64
checking OMR_TOOLCHAIN... gcc
checking for riscv64-unknown-linux-gnu-gcc... (cached) /opt/riscv_gnu_toolchain_glibc2.27_v3/bin/riscv64-unknown-linux-gnu-gcc
checking whether we are using the GNU C compiler... no  <-------- wrong
checking whether /opt/riscv_gnu_toolchain_glibc2.27_v3/bin/riscv64-unknown-linux-gnu-gcc accepts -g... no
checking for /opt/riscv_gnu_toolchain_glibc2.27_v3/bin/riscv64-unknown-linux-gnu-gcc option to accept ISO C89... unsupported
checking whether we are using the GNU C++ compiler... no  <------ wrong
checking whether riscv64-unknown-linux-gnu-g++ --sysroot=/opt/riscv_gnu_toolchain_glibc2.27_v3/sysroot accepts -g... no
checking for numa.h... no

Secondly, there is no easy to modify the code inside AC_PROG_CC/CXX to fix the misleading messages above as the check code there is automatically generated. So, it never hurts to remove the check in this cross-compilation.

This comment has been minimized.

Copy link
@rwy0717

rwy0717 Oct 25, 2019

Member

OK, I would rather find a way to fix the error, rather than disable the tests. can you provide some configure logs from a bad build?

When you say that cc/cxx is being tested twice, is the first test located in openj9/openjdk?

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 25, 2019

Author Contributor

When you say that cc/cxx is being tested twice, is the first test located in openj9/openjdk?

Yes, it shows up when running configure before make

checking resolved symbolic links for CC... no symlink
configure: Using gcc C compiler version 9.2.0 [riscv64-unknown-linux-gnu-gcc (GCC) 9.2.0]
checking for riscv64-unknown-linux-gnu-/opt/riscv_gnu_toolchain_master/bin/riscv64-unknown-linux-gnu-gcc... /opt/riscv_gnu_toolchain_master/bin/riscv64-unknown-linux-gnu-gcc
checking whether the C compiler works... yes <----
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes  <-----
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes <-----
checking whether /opt/riscv_gnu_toolchain_master/bin/riscv64-unknown-linux-gnu-gcc accepts -g... yes
checking for /opt/riscv_gnu_toolchain_master/bin/riscv64-unknown-linux-gnu-gcc option to accept ISO C89... none needed
checking for riscv64-unknown-linux-gnu-g++... /opt/riscv_gnu_toolchain_master/bin/riscv64-unknown-linux-gnu-g++
checking resolved symbolic links for CXX... no symlink
configure: Using gcc C++ compiler version 9.2.0 [riscv64-unknown-linux-gnu-g++ (GCC) 9.2.0]
checking whether we are using the GNU C++ compiler... yes

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 25, 2019

Author Contributor

OK, I would rather find a way to fix the error, rather than disable the tests. can you provide some configure logs from a bad build?

I am unable to drop the config.log somehow when enabling AC_PROG_CC/CXX in OMR.
But the comparison with the code dealing with AC_PROG_CC/CXX in jdk11 at openj9-openjdk-jdk11/make/autoconf/toolchain.m4 shows it calls TOOLCHAIN_FIND_COMPILER before AC_PROG_CC/CXX.

AC_DEFUN_ONCE([TOOLCHAIN_DETECT_TOOLCHAIN_CORE],
[
  #
  # Setup the compilers (CC and CXX)
  #
  TOOLCHAIN_FIND_COMPILER([CC], [C], $TOOLCHAIN_CC_BINARY) <---
  # Now that we have resolved CC ourself, let autoconf have its go at it
  AC_PROG_CC([$CC])

  TOOLCHAIN_FIND_COMPILER([CXX], [C++], $TOOLCHAIN_CXX_BINARY) <---
  # Now that we have resolved CXX ourself, let autoconf have its go at it
  AC_PROG_CXX([$CXX])

where TOOLCHAIN_DETECT_TOOLCHAIN_CORE (implemented in jdk11) is to validate C/C++ compiler in the path.

# Try to locate the given C or C++ compiler in the path, or otherwise.
#
# $1 = compiler to test (CC or CXX)
# $2 = human readable name of compiler (C or C++)
# $3 = compiler name to search for
AC_DEFUN([TOOLCHAIN_FIND_COMPILER],
[
...

Given that we already picked up the correct cross-compilers in previous configuration, the duplicate check in omr comparably useless for the cross-compilation in our case unless we are forced to implement something similar with TOOLCHAIN_DETECT_TOOLCHAIN_CORE to achieve this.

This comment has been minimized.

Copy link
@rwy0717

rwy0717 Oct 25, 2019

Member

OK, can you try compiling this test program by hand with the riscv toolchain? What's the compilation error? Does the error go away with the sysroot option?

We shouldn't disable OMR's toolchain detection, because the build system needs to work outside of J9.

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 25, 2019

Author Contributor

OK, can you try compiling this test program by hand with the riscv toolchain? What's the compilation error? Does the error go away with the sysroot option?

There is no difference between with and without --sysroot.

root@JCHLNXSVL1:~/jchau/temp# /opt/riscv_gnu_toolchain_master/bin/riscv64-unknown-linux-gnu-gcc  
--sysroot=/root/jchau/temp/RISCV_OPENJ9_v2/fedora_riscv/fedora_40G/fedora_riscv_mnt 
conftest.c
root@JCHLNXSVL1:~/jchau/temp# echo $?
0 <---
root@JCHLNXSVL1:~/jchau/temp# /opt/riscv_gnu_toolchain_master/bin/riscv64-unknown-linux-gnu-gcc 
 conftest.c 
root@JCHLNXSVL1:~/jchau/temp# echo $?
0 <---

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 25, 2019

Author Contributor

We shouldn't disable OMR's toolchain detection, because the build system needs to work outside of J9.

We only disabled it in RISCV during the cross-compilation. So it is still enabled in all other cases.

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 25, 2019

Author Contributor

Already talked to @rwy0717, we just keep the original check here as it never hurts the cross-compilation except the misleading check information generated from OMR (already verified the cross-build with the check enabled on Fedora/QEMU). It looks like there is problem in validating the cross-compilers in the configure script. Robert will double-check that to see whether there is any solution to the weird issue.

This comment has been minimized.

Copy link
@rwy0717

rwy0717 Nov 4, 2019

Member

An update: I haven't been able to reproduce this issue on OSX, and I don't have a linux VM set up yet. However, I have found some suspicious behaviour in the configure script.

tools/configure Show resolved Hide resolved
@@ -136,6 +139,9 @@
#elif defined(__aarch64__)
# define HOST_ARCH ARCH_ARM64
# define TR_HOST_64BIT 1
#elif defined(__riscv) && defined(J9RISCV64)

This comment has been minimized.

Copy link
@rwy0717

rwy0717 Oct 17, 2019

Member

We shouldn't test a J9 flag in OMR. Maybe testing for __64BIT__, as above, would be better?

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 17, 2019

Author Contributor

__64BIT__ doesn't exist in the prefined macro list in GCC compiler on RISC-V.
OMR_ENV_DATA64 might be an alternative but there is no fundamental difference as compared to J9RISCV64. To keep OMR independent from OpenJ9, I agree to change to OMR_ENV_DATA64.

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 17, 2019

Author Contributor

cmake/modules/platform/arch/riscv.cmake already defined (by one of OMR/JIT external contributor on RISCV-V)

if(OMR_ENV_DATA64)
	list(APPEND TR_COMPILE_DEFINITIONS -DTR_HOST_64BIT -DTR_TARGET_64BIT -DBITVECTOR_64BIT)

	set(TR_HOST_SUBARCH riscv64)
	set(TR_HOST_BITS    64)
else()

but they are in cmake and doesn't work in our case. We are currently still using UMA to compile the build.

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 17, 2019

Author Contributor

Already changed to OMR_ENV_DATA64.

This comment has been minimized.

Copy link
@rwy0717

rwy0717 Oct 18, 2019

Member

Unfortunately, OMR_ENV_DATA64 is defined in omrcfg.h, which this header doesn't use (although, I don't know why it's this way). Maybe you can use __SIZEOF_POINTER__ == 8.

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 18, 2019

Author Contributor

Then we can just change it to RISCV64 (already used in all changes).

This comment has been minimized.

Copy link
@rwy0717

rwy0717 Oct 25, 2019

Member

OK, where is RISCV64 being defined?

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 25, 2019

Author Contributor

RISC64 is passed in as global flags on the command line.

The corresponding changes are included in omrmakefiles/rules.linux.mk at #4433

...
else ifeq (riscv,$(OMR_HOST_ARCH))
        ifeq (1,$(OMR_ENV_DATA64))
             GLOBAL_CFLAGS  +=-DRISCV64 -Wno-error=stringop-truncation -Wno-error=stringop-overflow
             GLOBAL_CXXFLAGS+=-DRISCV64 -Wno-error=stringop-truncation -Wno-error=stringop-overflow
             GLOBAL_CPPFLAGS+=-DRISCV64 -Wno-error=stringop-truncation -Wno-error=stringop-overflow
        else
@ChengJin01 ChengJin01 force-pushed the ChengJin01:riscv_omr_part1_misc1 branch 4 times, most recently from e07fb55 to 553e98f Oct 17, 2019
@ChengJin01 ChengJin01 force-pushed the ChengJin01:riscv_omr_part1_misc1 branch from 553e98f to 01344fb Oct 25, 2019
@@ -136,6 +139,9 @@
#elif defined(__aarch64__)
# define HOST_ARCH ARCH_ARM64
# define TR_HOST_64BIT 1
#elif defined(__riscv) && defined(RISCV64)
# define HOST_ARCH ARCH_RISCV64
# define TR_HOST_64BIT 1

This comment has been minimized.

Copy link
@janvrany

janvrany Oct 29, 2019

Contributor

Sorry for jumping on this little late.

I think we should align this code with changes done in PR #3907. See https://github.com/eclipse/omr/pull/3907/files#diff-9cf243719c23dca420e7d19d55be39cc

There we have this:

# elif defined(__riscv)
#  define HOST_ARCH ARCH_RISCV
#  if __riscv_xlen == 32
#    define TR_HOST_32BIT 1
#  elif __riscv_xlen == 64
#    define TR_HOST_64BIT 1
#  else
#    error "defines.h: unknown word size"
#  endif

I'll do a pass on this and send a aligning patch later this week.

This comment has been minimized.

Copy link
@rwy0717

rwy0717 Oct 29, 2019

Member

That sounds good, thanks!

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 29, 2019

Author Contributor

I already changed to __riscv_xlen (already changed yesterday but just merged now). In addition, I will still keep ARCH_RISCV64 there

#elif (defined(__riscv) && (64 == __riscv_xlen))
#  define HOST_ARCH ARCH_RISCV64
# define TR_HOST_64BIT 1

as we don't think we will support 32bit for now.

This comment has been minimized.

Copy link
@janvrany

janvrany Oct 29, 2019

Contributor

I must say that I would still prefer "my" version:
(i) RV32 is not supported now and maybe not interesting for you and maybe not for J9, but I can (for)see others interested in OMR on RV32. Dunno about any specific need as of now, though.
(ii) Using ARCH_RISCV (as opposed to ARCH_RISCV64) is consistent with other archs already supported - see ARCH_POWER or ARCH_X86 (note, that ARM and AArch64 are really a different achitectures, so using ARCH_ARM64 makes sense).

We may (should?) add an explicit #error "RV32 not yet supported" somewhere to make the compilation to fail when run on RV32 (for now)

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Oct 29, 2019

Author Contributor

There are too many restrictions on 32bit (memory, OS support/specific to linux, etc), in which case we won't consider that for the moment unless there are strong motivation or business requirements. I personally don't object to ARCH_RISCV (I am using it somewhere in OpenJ9) but there should be no conflict with ARCH_RISCV64 as ARCH_RISCV64 represents 2 things: riscv and 64bit . so there is no need to check everywhere with both __riscv and __riscv_xlen or equivalent to determine whether it is RISCV 64bit or not.

This comment has been minimized.

Copy link
@rwy0717

rwy0717 Nov 1, 2019

Member

I think @janvrany is right, we should use ARCH_RISCV, but I'm sure @0xdaryl can tell us which way to go.

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Nov 4, 2019

Author Contributor

Already discussed with @DanHeidinga, we will change to ARCH_RISCV to align with code being merged to the OMR but there is no intention to do 32bit on OpenJ9 in the future. To avoid any conflict when merging to OMR, only my changes involved will be modified accordingly.

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Nov 4, 2019

Author Contributor

I've updated everywhere to support ARCH_RISCV after veriying the cross-build on RISC-V.

This comment has been minimized.

Copy link
@janvrany

janvrany Nov 5, 2019

Contributor

@ChengJin01 Cool, thanks! May I kindly ask you to also include this change:

--- a/cmake/modules/platform/arch/riscv.cmake
+++ b/cmake/modules/platform/arch/riscv.cmake
@@ -21,11 +21,13 @@
 
 if(OMR_ENV_DATA64)
        list(APPEND OMR_PLATFORM_DEFINITIONS
-               -D_RISCV64_
+               -DRISCV
+               -DRISCV64
        )
 else()
        list(APPEND OMR_PLATFORM_DEFINITIONS
-               -D_RISCV32_
+               -DRISCV
+               -DRISCV32
        )
 endif()
 

This aligns my code with yours, I don't know why I put underscores there - clearly no other platform has them so it seems right to remove them.

This comment has been minimized.

Copy link
@ChengJin01

ChengJin01 Nov 5, 2019

Author Contributor

@janvrany , your change without the underscores has been added at cmake/modules/platform/arch/riscv.cmake.

@ChengJin01 ChengJin01 force-pushed the ChengJin01:riscv_omr_part1_misc1 branch from 01344fb to 361855d Oct 29, 2019
@janvrany

This comment has been minimized.

Copy link
Contributor

janvrany commented Nov 4, 2019

Here I have attached a patch that aligns definitions with what I used (and with what is partly already commited in master). The patch is based on commit b297f0f. J9 compiles with this.

0001-RISC-V-align-RISC-V-definitions-for-CMake-and-autoto.patch.txt

@ChengJin01 ChengJin01 force-pushed the ChengJin01:riscv_omr_part1_misc1 branch 4 times, most recently from 111d0e7 to b36e4ef Nov 4, 2019
@ChengJin01 ChengJin01 requested a review from youngar as a code owner Nov 5, 2019
@rwy0717
rwy0717 approved these changes Dec 5, 2019
@rwy0717

This comment has been minimized.

Copy link
Member

rwy0717 commented Dec 5, 2019

I'm happy with this PR, but @ChengJin01 you have a merge conflict that needs to be resolved. #4532 was accepted, so hopefully you see more correct output from the configure script.

@rwy0717 rwy0717 self-assigned this Dec 5, 2019
@rwy0717

This comment has been minimized.

Copy link
Member

rwy0717 commented Dec 5, 2019

Given that there is significant overlap with #3907
I'll wait for the other PR to be accepted and we'll see what's still here.

@ChengJin01 ChengJin01 force-pushed the ChengJin01:riscv_omr_part1_misc1 branch from b36e4ef to 634da6c Dec 5, 2019
@ChengJin01

This comment has been minimized.

Copy link
Contributor Author

ChengJin01 commented Dec 5, 2019

I'm happy with this PR, but @ChengJin01 you have a merge conflict that needs to be resolved. #4532 was accepted, so hopefully you see more correct output from the configure script.

@rwy0717, the conflict here has been resolved.

@0xdaryl

This comment has been minimized.

Copy link
Contributor

0xdaryl commented Dec 5, 2019

Given that there is significant overlap with #3907
I'll wait for the other PR to be accepted and we'll see what's still here.

@rwy0717 : I'm hoping to merge #3907 this evening. I have a couple of admin tasks to do first.

@0xdaryl

This comment has been minimized.

Copy link
Contributor

0xdaryl commented Dec 6, 2019

@rwy0717 : #3907 has landed!

@ChengJin01 ChengJin01 force-pushed the ChengJin01:riscv_omr_part1_misc1 branch from 634da6c to ab94ec4 Dec 6, 2019
The changes mainly include configure scripts
to enable RISC-V 64bit from the OMR perspective.

Issue: #4426

Signed-off-by: Cheng Jin <jincheng@ca.ibm.com>
@ChengJin01 ChengJin01 force-pushed the ChengJin01:riscv_omr_part1_misc1 branch from ab94ec4 to c00692b Dec 6, 2019
@ChengJin01

This comment has been minimized.

Copy link
Contributor Author

ChengJin01 commented Dec 6, 2019

@rwy0717 , I've already rebased my changes on the top of #3907 and there is no merge conflict detected.

@rwy0717

This comment has been minimized.

Copy link
Member

rwy0717 commented Dec 6, 2019

@genie-omr build all

@rwy0717
rwy0717 approved these changes Dec 6, 2019
@rwy0717 rwy0717 merged commit e7951e0 into eclipse:master Dec 7, 2019
14 checks passed
14 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/eclipse-omr/pr/aix_ppc-64 Build finished.
Details
continuous-integration/eclipse-omr/pr/linux_390-64 Build finished.
Details
continuous-integration/eclipse-omr/pr/linux_aarch64 Build finished.
Details
continuous-integration/eclipse-omr/pr/linux_arm Build finished.
Details
continuous-integration/eclipse-omr/pr/linux_ppc-64_le_gcc Build finished.
Details
continuous-integration/eclipse-omr/pr/linux_x86 Build finished.
Details
continuous-integration/eclipse-omr/pr/linux_x86-64 Build finished.
Details
continuous-integration/eclipse-omr/pr/linux_x86-64_cmprssptrs Build finished.
Details
continuous-integration/eclipse-omr/pr/osx_x86-64 Build finished.
Details
continuous-integration/eclipse-omr/pr/win_x86-64 Build finished.
Details
continuous-integration/eclipse-omr/pr/zos_390-64 Build finished.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
eclipsefdn/eca The author(s) of the pull request is covered by necessary legal agreements in order to proceed!
Details
@rwy0717

This comment has been minimized.

Copy link
Member

rwy0717 commented Dec 7, 2019

Thank you @ChengJin01 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.