similar to: Orc JIT v2 breaks OpenMP in 11.x branch?

Hi Geoff, Nothing in that backtrace leaps out at me. Based on the stack trace and description my first guess would be a clang misconfiguration rather than a JIT bug. How is that clang invocation being made? Is it from inside a callback from ORC, or is it before you add your module to the JIT? -- Lang. On Mon, Aug 3, 2020 at 5:41 AM Geoff Levner <glevner at gmail.com> wrote: > Here,

Hi, That patch was from an ongoing effort to consolidate OpenMP generation in clang. If memory serves the implementation there is still a little incomplete. It's supposed to use types from OMPConstants rather than ones it defined itself and the methods used to create the functions shouldn't need to be static. However attempting this caused a lot of errors so there might be an underlying

Thanks, Joseph and Johannes. I have not merged in anything, I am using the code from the repository as is. What is this -debug-only option, and to whom would I pass it? I am running our own JIT application, which uses clang to compile modules on the fly via clang::CompilerInstance::ExecuteAction(). Working on the assumption that there is a mismatch in the declared type of an OpenMP runtime

Yep, it happens three times, then crashes afterwards, since I removed the assert... arg 0: expected %struct.ident_t* got %struct.ident_t.21* value @0 = private unnamed_addr global %struct.ident_t.21 { i32 0, i32 514, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* @.str, i32 0, i32 0) }, align 8 arg 0: expected %struct.ident_t* got %struct.ident_t.21* value @1 = private

Yeah, I remember encountering that error before when getting it to pass the libomp test suite. If you have a struct named "ident_t" somewhere the compiler will rename it because of the conflict with the runtime declaration. This should be solved by casting the usage to the function type found in the definition (i.e. bitcasting a struct.ident_t.21 to struct.ident_t) which solved the

So, when performing expression evaluation, lldb trips over an assert in clang/lib/AST/RecordLayoutBuilder because ExternalFieldOffsets doesn't contain a FieldDecl that updateExternalFieldOffset expected. I found that the assert occurs when both static and non-static member variables are present. For instance, with the following, the lldb command 'expr my_test.length()' does not

FYI, this turned out to be an error of omission in LLDB in SymbolFileDWARF, because the case of a non-defining external (i.e. a static member variable) wasn't being handled with a variable lookup to dig up the location. I'll put a patch together for lldb-commits, - Ashok From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Thirumurthi, Ashok

I ran into an LLVM/Clang crash when attempting to do the following: 1. Build Clang from the release/9.x branch source. 2. Use the Clang from (1) to build clangd on the release/9.x branch, with LLVM_ENABLE_MODULES=On. I wrote a script to reproduce the crash: https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608 At the above URL, you'll find a script `repro.sh` that reproduces

Hi Chandler, That's embarrassing how weird this part of clang is. I have a provisional patch which fixes the problem but underlines clang's problems. I will submit it tonight for comments. суббота, 18 октября 2014 г. пользователь Chandler Carruth написал: > > On Fri, Oct 17, 2014 at 7:51 AM, Anton Korobeynikov < > anton at korobeynikov.info >

Johannes, This patch seems to be causing test failures when I just do "ninja check", without running "ninja" or "ninja all" first. $ CC=clang CXX=clang++ cmake -G Ninja ~/git/llvm-project/llvm -DLLVM_USE_LINKER=lld -DLLVM_PARALLEL_LINK_JOBS=4 -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 && ninja check [...] FAIL: LLVM ::

This seems to be happening to me, too. I think this happens for me on "ninja check-llvm" in a clean build. Let me know if you need more info. On Tue, Dec 10, 2019 at 2:22 PM Doerfert, Johannes via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Jay, > > I am not sure why this happens. > Can you give me some information so I can reproduce it: > Is this happens

Jay, Hiroshi, did [0] resolve the problem you've seen. [0] https://github.com/llvm/llvm-project/commit/d23c61490c282a7a8f29aaa5c021cbfdaf87fb6f On 12/10, Doerfert, Johannes wrote: > I think the problem is that only clang has a dependence on the new > library and when you check LLVM without building clang it does not exist > yet. I will commit a LLVM patch today that will cause LLVM

I want to write a simple backend-specific instrinsic that will just call an instruction. How should I do that? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180924/7faeeb3d/attachment.html>

Hello Pedro, As others have said we're assuming that you're using Clang as the frontend, the MSP430TargetInfo class inside lib/Basic/Targets.cpp (clang codebase) set ints to be 16 bits wide, so you should get 16bit mults straight away without promotion. But anyways for 8bit multiplicantions you can do the following to bypass argument promotion: 1) go to the lib/CodeGen/TargetInfo.cpp

> > ok, I now have a problem in the code generator. > > Let's say I want to set a breakpoint somewhere in > > clang/lib/CodeGen/CGExprScalar.cpp > > > > What do I have to do in order to trigger breakpoints, see > > backtraces and so on? > > You set a breakpoint and ask to see a backtrace? > > -eric haha, OK, I think I should be more specific.

On Apr 20, 2012, at 6:35 PM, Roland Leißa <leissa at cs.uni-saarland.de> wrote: > ok, I now have a problem in the code generator. > Let's say I want to set a breakpoint somewhere in > clang/lib/CodeGen/CGExprScalar.cpp > > What do I have to do in order to trigger breakpoints, see backtraces and so on? You set a breakpoint and ask to see a backtrace? -eric

ok, I now have a problem in the code generator. Let's say I want to set a breakpoint somewhere in clang/lib/CodeGen/CGExprScalar.cpp What do I have to do in order to trigger breakpoints, see backtraces and so on? -- Roland ----- Original Message ----- > From: "Eric Christopher" <echristo at apple.com> > To: "Roland Leißa" <leissa at cs.uni-saarland.de>

All, This buildbot is getting lots of assertion failures in the test suite. They were probably caused by my commit: ------------------------------------------------------------------------ r151049 | foad | 2012-02-21 09:25:52 +0000 (Tue, 21 Feb 2012) | 6 lines Changed paths: M /llvm/trunk/lib/VMCore/LLVMContextImpl.h M /llvm/trunk/lib/VMCore/Type.cpp PR1210: make uniquing of struct and

On Apr 23, 2012, at 2:14 PM, Roland Leißa <leissa at cs.uni-saarland.de> wrote: >>> ok, I now have a problem in the code generator. >>> Let's say I want to set a breakpoint somewhere in >>> clang/lib/CodeGen/CGExprScalar.cpp >>> >>> What do I have to do in order to trigger breakpoints, see >>> backtraces and so on? >>

Hi Jim, thanks for replying. As mentioned in my earlier mail, I have to specify -emit-obj along with -cc1 in order to trigger codegen. This solves the problem for me. As I learned from the last email, specifying -v is a good starting point in order to see what actually is happening and tackle such problems. -- Roland ----- Original Message ----- > From: "Jim Grosbach"