similar to: Clang 3.8 fails with asan enabled

Hi Duncan, I came across something like the following recently which I guess might be related to your recent work. Any ideas? $ clang++-tot -cc1 crash_on_invalid.cpp -g -emit-obj -fexceptions -fcxx-exceptions crash_on_invalid.cpp:13:1: error: C++ requires a type specifier for all declarations x; ^ 1 error generated. *** Error in `clang++-tot': corrupted double-linked list: 0x000000000754f340

On Wed, Jan 14, 2015 at 9:05 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015 Jan 14, at 07:58, Duncan P. N. Exon Smith <dexonsmith at apple.com> > wrote: > > > >> > >> On 2015 Jan 13, at 23:59, David Blaikie <dblaikie at gmail.com> wrote: > >> > >> > >> > >> On Tue, Jan 13, 2015

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,

Greetings, Lang and other JITters, Last week I moved our Orc v2-based app from top-of-tree to the new 11.x branch, and it no longer handles C++ code containing OpenMP directives correctly. More specifically, if I JIT compile a function containing OpenMP parallel/for pragmas, using a release version of LLVM, the code compiles and seems to work, but if I try to write the module's bitcode to

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

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

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

> > 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 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? >>

llvm[1]: Compiling APFloat.cpp for Release+Asserts build clang: TargetInfo.cpp:1778: llvm::Type *GetX86_64ByValArgumentPair(llvm::Type *, llvm::Type *, const llvm::TargetData &): Assertion `Lo->isIntegerTy() && "Invalid/unknown lo type"' failed. 0 clang 0x0000000001c132ef 1 clang 0x0000000001c13804 2 libpthread.so.0 0x00002ba7d7eaec60 3

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"

Nadav, You are absolutely right, it's ISPC workload. I've checked SSE4 and it's also severely affected. We use intrinsics only for conversion <N x i32> <=> i32, i.e. movmsk.ps. For the rest we use general LLVM instructions. And I actually would really like to stick this way. We rely on LLVM's ability to produce efficient code from general LLVM IR. Relying on

Nadav, Could you please have a look at bug #16941 and let us know what you think about it? It's performance regression after one of your commits. Thanks. Dmitry. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131021/036e81d6/attachment.html>

Nadav, The problem appears only for vectors longer than available hardware register (in doubleword elements, i.e. more than 4 on SSE4 and more than 8 on AVX). Select does weird thing. <8 x i1> mask comes as two XMM registers, select converts them to a single XMM registers (i.e. 8 x 16 bit), immediately after it converts back to two XMM registers and does blend. Conversion forth and back has

Hi Nadav, ISPC is generating long vectors (on corresponding ISPC targets) this way since the every beginning of ISPC as far as I know. There's no such things in official LLVM documents as "illegal vectors", so people do expect that arbitrary long vectors are supported and generated reasonably well. Note, not super-optimal, but reasonably well. Keeping it this way allows considering

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

Hi Dmitry, Yes, this is a known problem with legalizing vector masks. The type <8 x i1> is legalized to 8 x i16, on SSE, but your operands are legalized to <4 x i32>. Type-legalization is performed per-node and we don’t have a good way to support instructions that mix the mask and operand type. Why does ISPC generate illegal vector types ? Does ISPC rely on the LLVM codegen to

Hi Dmitry, ISPC does some instruction selection as part of vectorization (on ASTs!) by placing intrinsics for specific operations. The SEXT to i32 pattern was implemented because LLVM did not support vector-selects when this code was written. Can you submit a small SSE4 test case that demonstrates the problem? Select is the canonical form of this operations, and SEXT is usually more