search for: frontendactions

Kostya, all, I'm trying to build my project by clang 3.8rc1 with enabled asan (clang itself is address sanitized) and it fails on several files from my project (ISPC, https://github.com/ispc/ispc). I've reproduced this on MacOS and Linux. Please let me know if you need any other info. How to reproduce: 1) Build address sanitized clang 3.8rc1: cd /path-to-working-dir svn co

Hello, I'm having this error and couldn't find a resolution from online, any help would be greatly appreciated: clang: /export/home/hzhang86/chapel/chapel-llvm36/chapel/third-party/llvm/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:839: void llvm::DwarfUnit::addType(llvm::DIE&, llvm::DIType, llvm::dwarf::Attribute): Assertion `Ty && "Trying to add a type that doesn't

Hi, I am learning to write LLVM modules. I am using IRBuilder to insert calls to an existing function. The call is to be inserted at a random location in every function in the code. The call does get inserted, however, the module crashes later (after doFinalization()). The crash happens only sometimes, not always. These are the kind of instructions that I see in the generated code. %callins =

I think this is https://llvm.org/bugs/show_bug.cgi?id=16846 On Jun 4, 2015 12:04 PM, "Hui Zhang" <wayne.huizhang at gmail.com> wrote: > Is there any clue for this error ? > > Thanks > > On Tue, Jun 2, 2015 at 5:47 PM, Hui Zhang <wayne.huizhang at gmail.com> > wrote: > >> Hello, >> >> I'm having this error and couldn't find a

Hello. I'm getting the following error after adding some extra instrumentation in a module (LoopVectorize.cpp ) due to a bug in Value::replaceAllUsesWith (see more comments of mine below): Value::replaceAllUsesWith(New = i16* inttoptr (i16 51 to i16*)), this = %VectorGep = getelementptr i16, i16* inttoptr (i16 51 to i16*), <128 x i64> zeroinitializer, !dbg !17 ; this

Upgrade clang? I can't reproduce it with trunk. On 4 June 2015 at 14:48, Hui Zhang <wayne.huizhang at gmail.com> wrote: > Yes, I found this link, but what's the solution?? > > On Thu, Jun 4, 2015 at 1:09 PM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >> >> I think this is https://llvm.org/bugs/show_bug.cgi?id=16846 >> >> On

In a pass I’m working on, I’ve done some manipulation of several functions, replacing them with new copies with different types, etc. The LLVM IR passes the verifier, but when I have debug symbols enabled (“-g”), I get the following error when Clang generates the Dwarf info (using a very recent build of LLVM/Clang from Git mirror): > Assertion failed: (TheCU && "Unable to find

On Wed, 2018-02-07 at 06:20 +0000, Chandler Carruth wrote: > I've landed the patch in r324449. > > Before we merge this into two different Clang release branches and > almost immediately release one of them, I would really like someone > to confirm that this patch works well with the Linux kernel. David, > if you're up for that, it would be great. Alternatively, Guenter

Thanks for the suggestion. I tried your fix. It worked for my particular case, but then I got a following error: clang-3.5: /home/rail/projects/escala_llvm/trunk/llvm-or1k/lib/CodeGen/RegisterPressure.cpp:39: void decreaseSetPressure(std::vector<unsigned int>&, llvm::PSetIterator): Assertion `CurrSetPressure[*PSetI] >= Weight && "register pressure underflow"'

Hi, On the OpenMandriva side, x86_64 passes all checks. We're having some problems with other architectures though (see below): x86_64 succeeded, packages are here: https://abf.openmandriva.org/build_lists/76792 i586 fails to build, but this seems to be an issue with 3.8.1 (which we're using to build 3.9): /usr/bin/clang++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS

Hi, I do not get your result. Do I miss something? $COMP_ROOT/clang++ --target=arm-arm-eabihf -march=armv8.2a+fp16 arm.cpp -S -o - -O3 .text .syntax unified .eabi_attribute 67, "2.09" .eabi_attribute 6, 14 .eabi_attribute 7, 65 .eabi_attribute 8, 1 .eabi_attribute 9, 2 .fpu crypto-neon-fp-armv8 .eabi_attribute 12, 4

While attempting to reduce a ubsan-specific bug, I stumbled upon the following. [I would have filed a bug report, but don't have an account, and so requested one per https://bugs.llvm.org/ about 7 hours ago -- but still no response, so am sending this instead. ] Using clang built from latest master of about 5 hours ago: $ echo struct a typename a | clang -x c++ - <stdin>:1:19: error:

I've landed the patch in r324449. Before we merge this into two different Clang release branches and almost immediately release one of them, I would really like someone to confirm that this patch works well with the Linux kernel. David, if you're up for that, it would be great. Alternatively, Guenter or someone else here can help. On Tue, Feb 6, 2018 at 5:59 PM Chandler Carruth

On Tue, Dec 3, 2013 at 9:04 PM, Brandon Holt <bholt at cs.washington.edu> wrote: > In a pass I’m working on, I’ve done some manipulation of several functions, replacing them with new copies with different types, etc. > > The LLVM IR passes the verifier, but when I have debug symbols enabled (“-g”), I get the following error when Clang generates the Dwarf info (using a very recent

Apologies if my questions sound dumb. They are provided below. On Wed, Apr 27, 2016 at 2:43 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > Are there any instructions (other than COPY) that use hardware > (allocatable) registers? > How do I find that out? > Could you show the instructions in the scheduling range? > How can I see instructions in the current

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

Adding cfe-dev, since this is a clang issue. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Jim Meyering via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: Jim Meyering <jim at meyering.net> Date: Monday, April 2, 2018 at 8:40 PM To: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> Subject: [llvm-dev] trivial input provokes failed

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

Thanks for the quick response. I wrote some code to search “llvm.dbg.cu” for the function (right before the failed assertion): if (TheCU == nullptr) { errs() << "compile unit: " << TheCU << "\n scopeNode(" << FnScope->getScopeNode() << ") => " << *FnScope->getScopeNode() << "\n"; auto fn =