search for: clangs

I think that debug info is slowing a self-hosting build down. This build has been going for ages now and shows no sign of quitting. To reproduce, build a Release+Asserts build of clang. Then use that to build a Debug+Asserts version. Include all of the bells and whistles, like the clang-extras and compiler-rt libraries. The reason I suspect debug info is because of this stack trace: [morbo:llvm]

Hi Bill Is this a recent regression? I recently changed the debug info verifier to fix a bug. Thanks, Manman > On Nov 17, 2013, at 5:52 PM, Bill Wendling <isanbard at gmail.com> wrote: > > I think that debug info is slowing a self-hosting build down. This build has been going for ages now and shows no sign of quitting. To reproduce, build a Release+Asserts build of clang. Then

I think it might be. I’m attaching a preprocessed file that can show the problem. Compile it with ToT. $ clang++ -g -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -m64 -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcovered-switch-default -Wno-uninitialized -Wno-missing-field-initializers -c

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

hello everyone: On this boring weekend, I tried compile R-trunk on windows 11 arm64 using clangarm64+msys2 on macbook m1 , it surprisingly easy to compiled and run. more investigation and test and code modify need to be done ,but IMO this is a good beginning !! to compile R on windows 11 arm64 just need : 1 svn checkout R-trunk and add USE_LLVM=YES in MKRules.dist or Mkrules.local 2 install

Hi Bill, Thanks for the testing case. Most of the time is spent on debug info verifier. I fixed a bug in r194974, now it takes too long to run debug info verification. Debug info verifier is part of the verifier which is a Function Pass. Tot currently tries to pull all reachable debug info MDNodes in each function, which is too time-consuming. The correct fix seems to be separating debug info

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

...9G build/tools/clang/unittests/Frontend 1.6G build/tools/clang/unittests/Driver 1.5G build/tools/clang/unittests/ASTMatchers 1.4G build/tools/clang/lib/StaticAnalyzer 1.3G build/lib/CodeGen 1.1G build/tools/clang/unittests/StaticAnalyzer 1.0G build/tools/clang/lib/StaticAnalyzer/Checkers/CMakeFiles/clangStaticAnalyzerCheckers.dir 1.0G build/tools/clang/lib/StaticAnalyzer/Checkers/CMakeFiles 1.0G build/tools/clang/lib/StaticAnalyzer/Checkers 1.0G build/lib/Transforms 989M build/tools/clang/unittests/CodeGen 964M build/tools/clang/unittests/AST 880M build/lib/CodeGen/CMakeFiles/LLVMCodeGen.dir 880M bu...

On Sun, Nov 17, 2013 at 6:35 PM, Manman Ren <manman.ren at gmail.com> wrote: > Hi Bill, > > Thanks for the testing case. Most of the time is spent on debug info > verifier. > I fixed a bug in r194974, now it takes too long to run debug info > verification. > > Debug info verifier is part of the verifier which is a Function Pass. Tot > currently tries to pull all

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

Hello everyone! After I've checked out Clang and Compiler-RT repositories, I receive this error during compilation: llvm[5]: Compiling PathDiagnostic.cpp for Debug+Asserts build /media/data/dev/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp: In member function 'bool {anonymous}::CompareDiagnostics::operator()(const clang::ento::PathDiagnostic*, const

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

Hello, After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: (I know I should fill a bug report instead of posting here, but I don't get much time right now). Trying to compile the following simple code, clang asserts. ---------- round.c -------- #include <math.h> float test() { return llround(1); } -------------------- [MacPro:~/Desktop]

On Mon, Nov 18, 2013 at 10:55 AM, Eric Christopher <echristo at gmail.com>wrote: > On Sun, Nov 17, 2013 at 6:35 PM, Manman Ren <manman.ren at gmail.com> wrote: > > Hi Bill, > > > > Thanks for the testing case. Most of the time is spent on debug info > > verifier. > > I fixed a bug in r194974, now it takes too long to run debug info > >

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"

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

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, all, I am planning to add clang-tidy checkers for my company. How to add a new module for my company? Please help, thanks in advance. I try to copy files from cert module, and rename cert to Misra, then add a rule named "m-0-1-1" by ./add_new_checker.py. then I run ninja check-clang-tool, but my case is failed due to below error Running ['clang-tidy',

On Tue, Feb 21, 2012 at 2:51 AM, Jay Foad <jay.foad at gmail.com> wrote: > 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: >