similar to: jump table crash with x64 JIT

Hi! Here i a patch for support platform independent threading. (needed for clang server (clang distcc project)). Cheers, Csaba Hruska -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080810/47f6f0c1/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hi! Essential Haskell Compiler (EHC) also has llvm backend. http://www.cs.uu.nl/wiki/bin/view/Ehc/WebHome http://www.cs.uu.nl/wiki/bin/view/Stc/CompilingHaskellToLLVM Cheers, Csaba -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090118/33489dd6/attachment.html>

Hi all, After updating llvm+clang to r174701 by issuing make -j8 happiness The build fails with: ... make[2]: Entering directory `/local/csaba/LLVM/build-release/tools/llvm-diff' llvm[2]: Compiling DiffConsumer.cpp for Release+Asserts build llvm[2]: Linking Release+Asserts executable lli (without symbols) llvm[2]: Compiling CrashDebugger.cpp for Release+Asserts build

Hello! I've discovered that `CallSiteSplitting` optimization doesn't support musttail calls. The easiest fix as it stands is disabling it for such call sites: https://reviews.llvm.org/D43729 . However, I'm not happy with such contribution. My more sophisticated attempt has failed due to my poor understanding of llvm internals. Here is the attempted patch:

clang version 2.9 (trunk 123166) Target: x86_64-unknown-linux-gnu Thread model: posix Fails to compile ctags 5.8 (also 5.6), specifically eiffel.c: $ clang -v -c e.c -O2 -Wno-unused-value clang version 2.9 (trunk 123166) Target: x86_64-unknown-linux-gnu Thread model: posix "/home/csaba/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name e.c

Hi everyone, I'm running into a problem using JIT compilation on Linux x86-64. LLVM revision is 62079. I've installed a lazy function creator using InstallLazyFunctionCreator(). I return the value 0x5ce64e from my lazyFunctionCreator function. However, the disassembled JIT'd function looks like this: 0x00007f45ef2b6018: sub $0x8,%rsp 0x00007f45ef2b601c: mov

Skykill Skyoverside <skyoverside at live.fr> writes: [snip] My guess is that you are hitting a VS C++ ABI missing feature in Clang. Ask in the Clang mailing list for a confirmation, but IIRC there are still missing pieces on either object construction/destrucion, parameter passing, returning classes and C++ exception support.

Thank, i have posted a mail about that. What i don't understand, is why it only work on x64, it should be more logical that it work only on x86, since most library focus first on working x86 before x64. The function getMethodPointer come from here http://stackoverflow.com/questions/3104389/can-i-bind-an-existing-method-to-a-llvm-function-and-use-it-from-jitted-code they said "that

Hi Skykill, > Hello everyone, i’m using LLVM (updated to 3.1 after seeing that bug, but it’s > the same with 3.0) for running a bitcode on a C++ program, and Clang for > compiling it. My code work perfectly, as expected on x64, but crash on x86. I’m > on Windows 7 x64 and LLVM + Clang was compiled using Visual Studio 2010 (tested > in both Release and Debug build). Project was make

On Thu, Dec 8, 2011 at 11:46 PM, Richard Pennington wrote: > On Thursday, December 08, 2011 02:46:39 AM Csaba Raduly wrote: >> On Wed, Dec 7, 2011 at 9:43 PM, Richard Pennington  wrote: >> > I compiled a program and standard library using clang/LLVM and found the >> > results interesting: >> > >> >   text    data     bss     dec     hex filename

Hi, so yes assertions are enabled by default in Debug from what i could see in the CMakeLists.txt if( uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE" ) option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF) else() option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON) endif() Without assertions enabled, when i'm running the program without the debugger, it

Update: I was able to make progress on it today ( See https://reviews.llvm.org/D43729 ). Apparently my problems were: * Iterating through the instruction/block list after erasing block/instruction * Trying to split block after removing one predecessor Regarding the latter, it appears that semantics of `DuplicateInstructionsInSplitBetween` change significantly in such case, and it starts to loop

On Thursday, December 08, 2011 02:46:39 AM Csaba Raduly wrote: > On Wed, Dec 7, 2011 at 9:43 PM, Richard Pennington wrote: > > I compiled a program and standard library using clang/LLVM and found the > > results interesting: > > > > text data bss dec hex filename > > 141312 4076 16668 162056 27908 bzip2.arm > > 131764 4076

Hi all. My dovecot setup: pf at vulcan:~ ? dovecot --version 2.3.0 (c8b89eb) on Arch Linux, x86_64 (full config here: [0]) uses sieve plugin to train rspamd system as described in the wiki [1]. It used to work fine prior to 2.3.0/0.5.0 update, but now "imap" process crashes when I move spam letters from the inbox to the junk folder. I've recompiled both dovecot and pigeonhole

Hi, I've been trying to migrate some of my CentOS 7 KVM hypervisors to CentOS 8, and I have encountered the following issue while trying to load my network config: virsh:     error: Failed to start network test1     error: internal error: Network is already in use by interface virbr2 journalctl:     error : networkCheckRouteCollision:123 : internal error: Network is already in use by

On Thu, May 16, 2013 at 11:30 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 16 May 2013 09:01, Csaba Raduly <rcsaba at gmail.com> wrote: >> >> "s390x--linux-gnu" seems wrong: either there's a dash too many or a >> word too few. > > > Nope, this triple is correct. The canonicalization of the triple (actually a > quadruple)

Hello Csaba, Thanks for the heads up. I am the one who wrote that test. I'll look into that shortly. Sorry about the trouble. pl On Mon, 16 Apr 2018 at 11:56, Csaba Raduly via llvm-dev < llvm-dev at lists.llvm.org> wrote: > ******************** > FAIL: LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s (38881 of 41794) > ******************** TEST 'LLVM :: >

Good evening, Csaba! I think rather, Cygwin does not need to know what PATHEXT would be. A patch(0001) is attached. Another patch is for unittests. Lit does not find *Tests.exe in unittests on ToT. 2010/12/24 Csaba Raduly <rcsaba at gmail.com>: > P.S. > With the above change, "make check-all" starts to run. Estimated run > time: 40 hours on my 1.8GHz single-core

r330121 should fix that. Let me know if you still run into any issues. cheers, pl On Mon, 16 Apr 2018 at 12:07, Pavel Labath <labath at google.com> wrote: > Hello Csaba, > Thanks for the heads up. I am the one who wrote that test. I'll look into > that shortly. Sorry about the trouble. > pl > On Mon, 16 Apr 2018 at 11:56, Csaba Raduly via llvm-dev < > llvm-dev at

Hello, I'm finally getting back to getting JIT debugging work for MCJIT. This has worked for ELF for a while in LLVM and support in lldb was added in January (for ELF). I'm now trying to add support for Mach-O and would appreciate some feedback (though I'm fighting my way through learning the format, I'm still just a novice). My current patchset for llvm is here: