similar to: Compiling OpenJDK8 with LLVM for mips64el

Hi Thomas, Thanks for your kind response! Please review my backport for hs25, thanks a lot! diff -r 3544d85cfe11 src/share/vm/opto/lcm.cpp --- a/src/share/vm/opto/lcm.cpp Thu Jul 19 10:00:36 2018 +0100 +++ b/src/share/vm/opto/lcm.cpp Fri Jul 20 10:06:37 2018 +0800 @@ -49,7 +49,7 @@ // Check whether val is not-null-decoded compressed oop, // i.e. will grab into the base of the heap

Hi Thomas, Looks good. Your changes in loopPredicate.cpp does not match original changes - they miss iff->is_RangeCheck() check [1]. But in JDK8 we did not have specialized RangeCheckNode class in C2. Suggested fix should be fine fro jdk 8u. Reviewed. Please, when sending RFA ( approval request) use original 8174050 bug id. Thanks, Vladimir [1]

Hi HotSpot and LLVM developers, I am building OpenJDK8[1] with LLVM toolchain[2] for mips64el, it failed to build: /home/loongson/jdk8-mips/hotspot/src/share/vm/opto/lcm.cpp:52:35: error: ordered comparison between pointer and zero ('address' (aka 'unsigned char *') and 'int') if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.

Hi Dimitry, Thanks for your kind response! Thanks for the commit message of Jung's patch, I found that the bug had been fixed in OpenJDK 12 by Zhengyu https://bugs.openjdk.java.net/browse/JDK-8205965 But only backported to 11. So Jung could backport it for OpenJDK 8, thanks a lot! But I argue that the root cause might be in the compiler side, why clang-3.9.1, gcc-6.4.1 couldn't

Hi all, OpenJDK8 jdk8u-dev[1] is just able to work after compiled with LLVM 3.9.1 for X86: $ ./build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/bin/java -version openjdk version "1.8.0-internal-debug" OpenJDK Runtime Environment (build 1.8.0-internal-debug-xiangzhai_2018_09_09_21_08-b00) OpenJDK 64-Bit Server VM (build 25.71-b00-debug, mixed mode) $ strings

Reported https://bugs.llvm.org/show_bug.cgi?id=38911 Thanks, Leslie Zhai 在 2018年09月11日 16:55, Dimitry Andric 写道: > Hi Leslie, > > The problem really lies in the OpenJDK code, as it is attempting to > write to a const object. If this seems to work with certain compiler(s) > and optimization settings, it is just luck. :-) > > Here is a reduced example, which shows the

Hi all, I met this error(title) when i was trying to compile llvm-gcc-4.2-2.7 on loongson2f,a mips compatible platform.I also failed to build a cross-compiler and the error message was the same . Is that means llvm-gcc cannot support mips back-end now? Thanks. Here is my configure options: $export TARGET=mips64el-unknown-linux-gnu $../../src/llvm-gcc-4.2-2.7.source/configure

Hi, I noticed a failure of mksh built with klibc on mips64el. The failing test, on a high level, is this: :>a sleep 2 :>b test a -nt b echo $? This is supposed to echo 1 (false) because a is not newer than b. The test code is roughly: // const char *opnd1 = "a"; // const char *opnd2 = "b"; // struct stat b1, b2; // int s; return (test_stat(opnd1, &b1) ==

On Jul 7, 2010, at 12:22 AM, 吴伟 wrote: > Hi all, > I met this error(title) when i was trying to compile llvm-gcc-4.2-2.7 on loongson2f,a mips compatible platform.I also failed to build a cross-compiler and the error message was the same . Is that means llvm-gcc cannot support mips back-end now? I don't think that LLVM supports mips64 yet... Bruno? -Chris > Thanks. >

Hi Ben, >Thorsten: I've attached a patch which I tested briefly in QEMU. Let me >know if this works for you. sorry for the delay. I was able to test this on eller today. To reproduce the issue, this was needed, because the value read was a nanosecond field and so the test didn?t always fail: (sid_mips64el-dchroot)tg at eller:~$ while sleep 0.1; do :>b; ./mksh -c 'test a -nt

Hi, On Wed, Jul 4, 2012 at 9:21 AM, ETANI NORIKO <noriko-e at fc.ritsumei.ac.jp> wrote: > Please advise me how to change a compiler from a host one to a target one. Suppose MIPS toolchain is installed in the $MIPS folder (i.e. mips-linux-gnu-gcc is in the $MIPS/bin folder). Note, if you want to generate little-endian code and/or 64-bit code, you have to create the following links in the

Rewrote the ABI example in terms of clang -cc1as which is a supported tool. Note that the same problems exist and that they are unrelated to the existence of TargetMachine or not since TargetMachine gets the relevant information from the Triple it holds. This information is incorrect, even as a starting point. Please do read the other examples in my previous email. It contains a number of

> > Note that the same problems exist and that they are unrelated to the existence > > of TargetMachine or not since TargetMachine gets the relevant information from > > the Triple it holds. This information is incorrect, even as a starting point. > > I believe we're going to disagree here as the TargetMachine does not get all of its > information from the Triple -

Hello, I was trying to compile a simple program with the CppBackend like so: $ clang str_arg.c -emit-llvm -S $ llc -march=cpp str_arg.ll It produces a file `str_arg.cpp` as expected, however it doesn't seem that the resulting file is correct. For once, it includes `<llvm/Analysis/Verifier.h>` which seems to have been moved to `llvm/IR/Verifier.h` as far back as 2013. My question is

Hi, I am wondering why we dont support PPC32 LE? Here is the output of llvm-mc --version, in which only PPC32, PPC64 & PPC64LE are supported. $ llvm-mc --version LLVM (http://llvm.org/): LLVM version 3.6.2 Optimized build with assertions. Built Aug 2 2015 (11:39:46). Default target: x86_64-apple-darwin15.4.0 Host CPU: core-avx2 Registered Targets: aarch64 - AArch64

> > The word 'all' is what still bothers me here. If any one piece of the information is derived from incorrect information in the triple, then the behaviour will likely be incorrect. > > If it's possible to be derived from the triple then it's going to be correct or the triple is incorrect. > If it's something that's overridden later because it can't be

I upgraded my versions of llvm, clang and compiler-rt to the top-of-tree versions from last night (r180162, April 24). I recompiled debug versions of llvm, clang and my code. I then regenerated my test case and the results were the same - I can list lines of dwarf1.lsp in lldb but I can't set break-points or do anything else (what else should I be able to do?). The updated file that

Yes, it's quite obviously dead and should be deleted. When I brought this up last time -- after realizing that it wasn't actually a backend that targetted c++ (which might be useful), but rather just something that emitted IR by calling llvm C++ functions (which really isn't IMO) -- someone also pointed out that it also really ought to be using IRBuilder...if anyone cared about it.

Eric Christopher echristo at gmail.com<mailto:echristo at gmail.com> writes: > The lack of a TargetMachine at the MC level was something I brought up a long time ago in this thread > with my proposed solutions. This is what needs to be fixed, especially given that targets can switch ISA, > ABI, floating point, etc within a single assemble action. I’ve been watching this thread in

I am seeing an assert when I compile the attached program with clang: $ clang -fno-strict-aliasing -target mips64el-unknown-linux -O3 -fomit-frame-pointer -S test1.c -o test1.ll -emit-llvm It asserts when LoopVectorize.cpp:506 is executed. It looks like it is complaining because it is trying to zero-extend an i64 (type Count->getType() returns i64) to an i32 (IdxTy). if (Count->getType()