similar to: [LLVMdev] Effect of weak symbols on llvm tools/clang startup time

This probably just works around a layering violation. Can you provide the cmake line that produces a broken build? Cheers, Rafael On Jun 18, 2016 7:34 AM, "Nicolai Hähnle" <llvm-dev at lists.llvm.org> wrote: Hi, since recently I'm getting linker failures in debug builds. The root cause is that -fvisibility-inlines-hidden causes inline functions in explicit template

Good afternoon, We are running callgrind and cg_annotate version 3.6.1 on Centos Linux Version 5.5 x86_32. One month ago Mr. Josef Weidenorfer issued a special patch that fixed callgrind on Centos Linux Version 5.5 x86_32. We can now profile complex C++ programs which use our own shared library libmdMatchup.so. However, when we use version 3.6.1 cg_annotate callgrind.out.22533 --auto = yes

Hi, For the last day or two I having been trying to get Valgrind/Callgrind 3.6.1 to work on Centos Linux 5.5 using a simple Fibonacci C++ program(shown below). After compiling the program using g++ -g -o MatchUpAccurate MatchUpAccurate.cpp, we run: /home/frankc/DQTTest/valgrind-3.6.1/coregrind/valgrind --tool=callgrind --dump-instr=yes --simulate-cache=yes --collect-jumps=yes

On Thu, Mar 17, 2016 at 11:45 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > On Thu, Mar 17, 2016 at 10:05 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: >> On Mon, Mar 14, 2016 at 5:30 PM, Chris Bieneman <cbieneman at apple.com> wrote: >> [ brutal-snip ] >> ... >>> [ TODO#S: Before doing a 2nd build (and in a 3rd run using more >>>

George Karpenkov <ekarpenkov at apple.com> writes: > OK so with Kuba’s help I’ve found the error: with optimization, dead > stripping of produced libraries is enabled, > which removes coverage instrumentation. > > However, this has nothing to do with the move to compiler-rt, so I’m > quite skeptical on whether it has worked > beforehand. > > A trivial fix is to do:

Olly Betts <olly at survex.com> wrote: > On Mon, Aug 24, 2020 at 05:58:02AM +0000, Eric Wong wrote: > > Olly Betts <olly at survex.com> wrote: > > > Can prof report time for a function including things it calls? > > > > callgraph? Attached is a profile the output of "perf report -g" > > with callgraph info. I'm no perf expert,

On Mon, Aug 24, 2020 at 05:58:02AM +0000, Eric Wong wrote: > Olly Betts <olly at survex.com> wrote: > > Can prof report time for a function including things it calls? > > callgraph? Attached is a profile the output of "perf report -g" > with callgraph info. I'm no perf expert, either, but slowly > learning more as I go along... The list seems to have

Tru Huynh, Thank you for your reply. When I enter uname -a I obtain the following output: Linux localhost.localdomain 2.6.18-194.26.1.el5PAE #1 SMP Tue Nov 9 13:34:42 EST 2010 i686 i686 i386 GNU/Linux. This information indicates we are using x86_32 architecture rather than a x86_64 architecture. Also, when I enter rpm -q glibc glibc-devel, I obtain the following output: glibc-2.5.49.el5_57

I think the simplest fix is something like this: diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp index c6f0d17f8fe..e81957ab80a 100644 --- a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp +++ b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp @@ -256,6 +256,7 @@ SanitizerCoverageModule::CreateSecStartEnd(Module

> On Dec 20, 2016, at 5:49 AM, Carsten Mattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ​Hi again, Teresa. > > Looks like I had forgotten to report back with success > when finally building 3.9.0 in ThinLTO linker mode > back in October. Sorry about that and thanks for > helping me out. I know how important it is to get > success reports as well, as a

> On Aug 24, 2017, at 2:55 PM, Kostya Serebryany <kcc at google.com> wrote: > > Interesting. > This is a relatively new addition (fsanitize-coverage=pc-tables, which is now a part of -fsanitize=fuzzer). > The tests worked (did they? On Mac?) so I thought everything is ok. For tests we never compile the tested target with -O3 (and that wouldn’t be sufficient), and for

Which version of CMake? On Tue, Jan 21, 2014 at 10:06 AM, Chandler Carruth <chandlerc at gmail.com>wrote: > Maybe, I'll have to debug. It does seem quite bizarre. > > > On Tue, Jan 21, 2014 at 10:03 AM, Renato Golin <renato.golin at linaro.org>wrote: > >> Chandler, >> >> I may be doing this wrong, but I'm getting a weird error in building

Chandler, I may be doing this wrong, but I'm getting a weird error in building LLVM with Clang via CMake. On x86_64: $ CC=clang CXX=clang++ cmake -G Ninja ../../src/llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_TESTS=True -DLLVM_ENABLE_ASSERTIONS=True On ARM: $ CC=clang CXX=clang++ cmake -G Ninja ../src/ -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=../install

No, it has the wrong value. I tried it with cmake 2.8.9 and 2.8.12.2. Both of them set the variable to “.so”. On Feb 12, 2014, at 5:29 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Juergen, > > Thanks to let me know. I guess r200762 (and r200763) might affect. > > Although I won't check this on darwin box, I suspect the line in > HandleLLVMOptions.cmake;

Should be fixed in r199756. Let me know. On Tue, Jan 21, 2014 at 10:08 AM, Chandler Carruth <chandlerc at gmail.com>wrote: > Never mind, I see the bug. Working on a fix. > > > On Tue, Jan 21, 2014 at 10:07 AM, Chandler Carruth <chandlerc at gmail.com>wrote: > >> Which version of CMake? >> >> >> On Tue, Jan 21, 2014 at 10:06 AM, Chandler Carruth

On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Thu, Aug 24, 2017 at 3:20

On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Aug 24, 2017 at 3:20 PM, Justin Bogner <mail at justinbogner.com> > wrote: > >> I think the simplest fix is something like this: >> >> diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp >>

[Was initially posted on cfe-users, sorry.] Hi, I'm sorry my message is quite long, the TL;DR version is "g++ and clang++ seem to have different opinions on how RTTI, templates, and ELF visibility should interact". I can't tell whether this is a bug or not: I have found no relevant documentation that could help me decide whether this behavior is meant, or not. All I can say

With gcc >= 4 and ELF, set default visibility to hidden and make visible only the symbols with FLAC_API or FLACPP_API. A convenience libFLAC-static.la is created for test_libFLAC as it depends on the hidden symbols. --- configure.ac | 8 +++++++- include/FLAC++/export.h | 13 +++++++++---- include/FLAC/export.h | 13 +++++++++---- src/libFLAC/Makefile.am | 10

On Sun, Nov 25, 2012 at 3:19 PM, Joe Abbey <jabbey at arxan.com> wrote: > If cmake happens to detect GCC for the C compiler and Clang for the C++ > compiler, then a manual override of either the C compiler or > SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG is required. This has been happening > on my Darwin build environments: > > -- The C compiler identification is GNU 4.2.1 >