similar to: [LLVMdev] GCC compatibility code coverage issue .

Hi Justin , Thank you for the confirmation and we would like to know that ,going forward the clang has the support the gcc gcov format or use the -fprofile-instr-generate -fcoverage-mapping and get ride of gcov format . We are planing to customize the clang code coverage for embedded world ,before we start tweaking the gcov / -fprofile-instr-generate code-base ,we would like to take feedback

Umesh Kalappa <umesh.kalappa0 at gmail.com> writes: > Hi Justin , > > Thank you for the confirmation and we would like to know that ,going > forward the clang has the support the gcc gcov format or use the > -fprofile-instr-generate -fcoverage-mapping and get ride of gcov > format . Going forward, the -fprofile-instr-generate -fcoverage-mapping (which I'll refer to as

Hi Everyone, I have uploaded a patch that allows one to successfully gather gcov/gcda coverage information on programs which unload shared libraries. It¹s a simple fix, just adding a few COMPILER_RT_VISIBILITY (i.e. __attribute__((visibility("hidden")))) in GCDAProfiling.c. Now, I¹d like to include a test program to demonstrate the fix. AFAICT, there seems to be a single test for

rkotler at mipsswbrd006-le:~/caviumllvm/build/test$ make Making LLVM 'lit.site.cfg' file... Making LLVM unittest 'lit.site.cfg' file... ( ulimit -t 600 ; ulimit -d 512000 ; ulimit -m 512000 ; ulimit -s 8192 ; \ /usr/bin/python /home/rkotler/workspace/llvm/utils/lit/lit.py -s -v . ) XPASS: LLVM :: tools/llvm-cov/llvm-cov.test (8916 of 9784) ******************** TEST

Updated set of patches for coverage. Changes: - change copyright lines - use gcov: instead of cover: in commit comment - use #ifdef in xen/common/sysctl.c instead of dummy inline function - added base documentation in docs/misc - added -h option to xencov

Try using $PWD/test.cpp on the clang command line. I am seeing the duplicate DIFile entries, but not yet able to reproduce a .debug_line section with multiple directory entries. --paulr From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Tomar, Sourabh Singh via llvm-dev Sent: Tuesday, September 1, 2020 1:07 PM To: Umesh Kalappa <umesh.kalappa0 at gmail.com>; cfe-dev at

Hi All, We have populated info in the Clang Sema i.e class Sema (include/clang/Sema/Sema.h) and like to propagate the same to Clang Codegen . Currently we are propagating through ASTContext ,where we have duplicating fields info and operation in the Sema and ASTContext . Any better way of doing the same ? Thank you ~Umesh

> On May 29, 2016, at 5:44 PM, Shi, Steven <steven.shi at intel.com> wrote: > > (And I doubt the GNU linker supports LTO with LLVM). > [Steven]: I’ve pushed GNU Binutils ld to support LLVM gold plugin, see detail in this bug https://sourceware.org/bugzilla/show_bug.cgi?id=20070 <https://sourceware.org/bugzilla/show_bug.cgi?id=20070>. The new GNU ld linker works well with

Hi, I ran into the bug/feature request that you cannot flush gcov buffers while the app is running. They are only called when you exit the program, since the flush functions are registered with atexit(). This is the bug report: http://llvm.org/bugs/show_bug.cgi?id=12144 I have what I think is a basic implementation of the `__gcov_flush` call, although I called this version `__llvm_gcov_flush`.

We do have a gcov "flush" implementation. It should be emitted with the normal coverage code. Is it not showing up? -bw On Feb 5, 2013, at 4:20 PM, John Harrison <ash.gti at gmail.com> wrote: > Hi, > > I ran into the bug/feature request that you cannot flush gcov buffers while the app is running. They are only called when you exit the program, since the flush functions

> On May 29, 2016, at 5:10 PM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > GCC LTO seems support large code model in my side as below, if the code model is linker specific, does the GCC LTO use a special linker which is different from the one in GNU Binutils? I don't know anything about GCC. (And I doubt the GNU linker supports LTO with LLVM). > I’m a

Hi Mehdi, Should I apply your attached patch on my llvm3.8 source firstly? Or should I use the latest llvm SVN trunk instead? Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Monday, May 30, 2016 2:13 PM To: Shi, Steven <steven.shi at intel.com> Cc: Umesh Kalappa <umesh.kalappa0 at

Edited the Subject. On Fri, Jul 20, 2018 at 5:50 PM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > Hi All , > > We are looking at the C sample i.e > > extern int i,j; > > int test() > { > while(1) > { i++; > j=20; > } > return 0; > } > > command used :(clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) > ) > clang

Dear Andrew and the Group, I’m trying come up with a SchedMachineModel for the AMD bulldozer http://en.wikipedia.org/wiki/Bulldozer_(microarchitecture). The model is not exist for the same .Please correct me if am i wrong here. I was going through your reference @ https://llvm.org/svn/llvm-project/llvm/trunk/include/llvm/Target/TargetSchedule.td . But I couldn’t model some of the

Hi Steven, > On May 29, 2016, at 11:28 PM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > Should I apply your attached patch on my llvm3.8 source firstly? Or should I use the latest llvm SVN trunk instead? I wrote it on trunk, but I expect it to be fairly easy to port on 3.8. This is really just quickly plumbing an option on the TargetMachine creation. --

Hi, > On May 29, 2016, at 7:36 AM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > After deeper debug, I found my firmware LTO wrong code issue is related to X64 code model (-mcmodel=large) is always overridden as small (-mcmodel=small) if LTO build. And I don't know how to correctly specific the large code model for my X64 firmware LTO build. Appreciate if

Hi andrea, R11 treated as frame pointer at arm backend , which is fixed again . Thanks Umesh On Tuesday, October 15, 2013, Andrea Mucignat <andrea at nestlabs.com> wrote: > Umesh, > Makes some sort of sense to me, OTOH: > If instead of choosing r11 as a "dummy" to align the stack we had chosen some other register in the range r0-r7 then we could have emitted the PUSH

On 7 June 2016 at 10:54, Shi, Steven <steven.shi at intel.com> wrote: > Hi Rafael, > I finally enable the clang LTO build with small code model and PIE, and my clang LTO Uefi firmware works now. Thank you! But I have one more issue on the clang normal build (without LTO) now. I find the small code model + "-fpie" build option will let clang generate some R_X86_64_GOTPCREL

> On May 17, 2016, at 11:21 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > > Steven, > > As mehdi stated , the optimisation level is specific to linker and it > enables Inter-Pro opts passes ,please refer function To be very clear: the -O option may trigger *linker* optimizations as well, independently of LTO. -- Mehdi > >

The way `-ftest-coverage -fprofile-arcs` works at the moment it only flushes via `atexit()`. This patch allows you to flush the coverage at any point by calling `__llvm_gcov_flush` the same way `__gcov_flush` works for gcc. If there is another way of doing this, I might of missed it but I was looking for `__gcov_flush` and I did not find the equivalent in llvm at the moment. -- John Harrison