Ah, my mistake. So this already works. I guess that bug is out of date, since this feature works already. -- John Harrison On Wed, Feb 6, 2013 at 10:00 AM, Joshua Cranmer <pidgeot18 at gmail.com> wrote:> On 2/6/2013 11:43 AM, John Harrison wrote: > >> 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. >> > > __gcov_flush is added by the GCOVProfiling.cpp pass by > GCOVProfiler::insertFlush. > > -- > Joshua Cranmer > News submodule owner > DXR coauthor > > > ______________________________**_________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130206/c0b6bf71/attachment.html>
Why does __gcov_flush only flush the current compilation unit? For gcc __gcov_flush flushes all of the loaded files. Is there a way to have __gcov_flush flush everything? -- John Harrison On Wed, Feb 6, 2013 at 10:24 AM, John Harrison <ash.gti at gmail.com> wrote:> Ah, my mistake. So this already works. I guess that bug is out of date, > since this feature works already. > > -- > John Harrison > > > On Wed, Feb 6, 2013 at 10:00 AM, Joshua Cranmer <pidgeot18 at gmail.com>wrote: > >> On 2/6/2013 11:43 AM, John Harrison wrote: >> >>> 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. >>> >> >> __gcov_flush is added by the GCOVProfiling.cpp pass by >> GCOVProfiler::insertFlush. >> >> -- >> Joshua Cranmer >> News submodule owner >> DXR coauthor >> >> >> ______________________________**_________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130206/a71a69b3/attachment.html>
The reason was due to how gcc uses the __gcov_flush function. I haven't looked at the code in a while, but it might be doable to flush all CUs... -bw On Feb 6, 2013, at 12:05 PM, John Harrison <ash.gti at gmail.com> wrote:> Why does __gcov_flush only flush the current compilation unit? For gcc __gcov_flush flushes all of the loaded files. > > Is there a way to have __gcov_flush flush everything? > > -- > John Harrison > > > On Wed, Feb 6, 2013 at 10:24 AM, John Harrison <ash.gti at gmail.com> wrote: > Ah, my mistake. So this already works. I guess that bug is out of date, since this feature works already. > > -- > John Harrison > > > On Wed, Feb 6, 2013 at 10:00 AM, Joshua Cranmer <pidgeot18 at gmail.com> wrote: > On 2/6/2013 11:43 AM, John Harrison wrote: > 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. > > __gcov_flush is added by the GCOVProfiling.cpp pass by GCOVProfiler::insertFlush. > > -- > Joshua Cranmer > News submodule owner > DXR coauthor > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Yikes! It only flushes the counts for the current compilation unit? That sounds like a terrible bug. Can you file a bugzilla report, please? On Feb 6, 2013, at 12:05 PM, John Harrison <ash.gti at gmail.com> wrote:> Why does __gcov_flush only flush the current compilation unit? For gcc __gcov_flush flushes all of the loaded files. > > Is there a way to have __gcov_flush flush everything? > > -- > John Harrison > > > On Wed, Feb 6, 2013 at 10:24 AM, John Harrison <ash.gti at gmail.com> wrote: > Ah, my mistake. So this already works. I guess that bug is out of date, since this feature works already. > > -- > John Harrison > > > On Wed, Feb 6, 2013 at 10:00 AM, Joshua Cranmer <pidgeot18 at gmail.com> wrote: > On 2/6/2013 11:43 AM, John Harrison wrote: > 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. > > __gcov_flush is added by the GCOVProfiling.cpp pass by GCOVProfiler::insertFlush. > > -- > Joshua Cranmer > News submodule owner > DXR coauthor > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130206/7ed3ea7a/attachment.html>