What is the macro to test POSIX IO on host? The guard uses TARGET_POSIX_IO which is not right.
David On Fri, Jul 11, 2014 at 1:12 AM, Christophe Lyon <christophe.l...@linaro.org> wrote: > On 11 July 2014 10:07, Richard Biener <richard.guent...@gmail.com> wrote: >> On Mon, May 5, 2014 at 7:17 PM, Rong Xu <x...@google.com> wrote: >>> Here is the updated patch. The difference with patch set 3 is >>> (1) use the gcov-counter.def for scaling operation. >>> (2) fix wrong scaling function for time-profiler. >>> >>> passed with bootstrap, profiledboostrap and SPEC2006. >> >> One of the patches breaks bootstrap for me: >> >> /space/rguenther/src/svn/trunk/gcc/../libgcc/libgcov.h:184: error: ISO >> C++ forbids zero-size array ‘ctrs’ >> make[3]: *** [libgcov-util.o] Error 1 >> >> host compiler is gcc 4.3.4 >> >> Richard. >> > > On my side, commit 212448 breaks the cross-build of GCC for targets > using newlib: > * arm-none-eabi > * aarch64-none-elf > /usr/include/sys/stat.h: In function <80><98>void > gcov_output_files(const char*, gcov_info*)<80><99>: > /usr/include/sys/stat.h:317: error: too few arguments to function > <80><98>int mkdir(const char*, __mode_t)<80><99> > /tmp/1392958_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gcov-tool.c:96: > error: at this point in file > make[2]: *** [gcov-tool.o] Error 1 > > Christophe. > >>> Thanks, >>> >>> -Rong >>> >>> On Thu, May 1, 2014 at 3:37 PM, Rong Xu <x...@google.com> wrote: >>>> Hi, Honza, >>>> >>>> Please find the new patch in the attachment. This patch integrated >>>> your earlier suggestions. The noticeable changes are: >>>> (1) build specialized object for libgcov-driver.c and libgcov-merge.c >>>> and link into gcov-tool, rather including the source file. >>>> (2) split some gcov counter definition code to gcov-counter.def to >>>> avoid code duplication. >>>> (3) use a macro for gcov_read_counter(), so gcov-tool can use existing >>>> code in libgcov-merge.c with minimal change. >>>> >>>> This patch does not address the suggestion of creating a new directory >>>> for libgcov. I agree with you that's a much better >>>> and cleaner structure we should go for. We can do that in follow-up >>>> patches. >>>> >>>> I tested this patch with boostrap and profiledbootstrap. Other tests >>>> are on-going. >>>> >>>> Thanks, >>>> >>>> -Rong >>>> >>>> On Wed, Apr 16, 2014 at 8:34 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >>>>>> GCOT_TOOL needs to use this function to read the string in gcda file >>>>>> to memory to construct gcov_info objects. >>>>>> As you noticed, gcov runtime does not need this interface. But >>>>>> gcov-tool links with gcov runtime and it also uses the function. >>>>>> We could make it available in gcov_runtime, but that will slightly >>>>>> increase the memory footprint. >>>>> >>>>> Yep, it is not really pretty. I wrote bellow some plan how things may be >>>>> structured in more convenient way. Any work in that direction would be >>>>> welcome. >>>>>> >>>>>> The planned new functions for trunk version is: (1) overlap score b/w >>>>>> two profiles (2) better dumping (top hot objects/function/counters) >>>>>> and statistics. >>>>>> Once this basic version is in, we can start to add the new functionality. >>>>> >>>>> Sounds good. I assume the autoFDO does not go via gcov tool but rather >>>>> uses >>>>> custom reader of profile data at GCC side? >>>>> I wonder, are there any recent overview papers/slides/text of design of >>>>> AutoFDO >>>>> and other features to be merged? >>>>> I remember the talk from GCC Summit and I did read some of pre-LTO LIPO >>>>> sources & papers, but it would be nice to have somethin up to date. >>>>>> >>>>>> libgcov-util.o is built in gcc/ directory, rather in libgcc. >>>>>> It's directly linked to gcov-tool. >>>>>> So libgcov-util.o is built for HOST, not TARGET. >>>>>> With makefile changes, we can built HOST version of libgcov-driver.o >>>>>> and libgcov-merge.o. >>>>>> I also need to make some static functions/variables public. >>>>> >>>>> I suppose that can go with IN_GCOV_TOOL ifdef. >>>>> >>>>> So we currently have basic gcov io handling in gcc/gcov-io.c that is >>>>> borrowed >>>>> by libgcc/libgcov* code. We also will get libgcov-util.c in libgcc >>>>> directory >>>>> that is actually borrowed by by gcc/gcov-tool.c code. >>>>> >>>>> We now have one runtime using STDIO for streaming and kernel has custom >>>>> version >>>>> that goes via /proc interface (last time I looked). We added some >>>>> abstraction >>>>> into libgcov-interface that is the part that relies on STDIO, partly via >>>>> gcov-io.c >>>>> code and now we have in-memory handling code in libgcov-util. >>>>> >>>>> I guess it would make most sentse to put all the gcov code into a new >>>>> directory >>>>> (libgcov) and make it stand-alone library that can be configured >>>>> 1) for stdio based runtime as we do not >>>>> 2) for runtime missing the interface and relyin on user providing it >>>>> 3) for use within gcov file manipulation tools with reorg of >>>>> GCC/gcov/gcov-dump/gcov-tool to all use the same low-level interfaces. >>>>> In a longer term, I would like to make FDO profiling intstrumentation to >>>>> happen >>>>> at linktime. For that I need to make the instrumentation code (minimal >>>>> spaning >>>>> tree & friends) to work w/o cgraph that would ideally be done in a shared >>>>> implementation >>>>>> > Won't this get wrong answer when counters[0] is not the same? >>>>>> > I would expected the merging code to compare the counters first. >>>>>> > Similarly for delta counter. >>>>>> >>>>>> These *_op functions are for scaling only. So there is only one >>>>>> profile involved (thus there is no comparison). >>>>>> The merge handles are in libgcov-merge.c which have the code to handle >>>>>> mismatched profile targets. >>>>> >>>>> I see, OK then. >>>>>> > >>>>>> > Adding correct rounding may actually make difference for Martin's >>>>>> > startup time work. >>>>>> >>>>>> Do you mean to use something like in RDIV macro? >>>>> >>>>> Yes. >>>>> >>>>> Honza
