On Mon, Jul 25, 2016 at 01:08:43PM +0200, Martin Liška wrote: > On 07/15/2016 10:37 AM, Bin.Cheng wrote: > > On Thu, Jul 14, 2016 at 11:33 PM, Andi Kleen <a...@firstfloor.org> wrote: > >>>>> I haven't seen that. Unstable in what way? > >>>> For GCC doesn't support FDO, it run below tests as you said: > >>>> > >>>> PASS: gcc.dg/tree-prof/20041218-1.c compilation, -g > >>>> UNSUPPORTED: gcc.dg/tree-prof/20041218-1.c: Cannot run create_gcov > >>>> --binary /data/work/trunk/build/gcc/testsuite/gcc/20041218-1.gcda > >>>> > >>>> Normally, it doesn't create gcov data file, thus the next test is > >>>> unsupported. I guess in parallel test, the second test picks up gcov > >>>> data files from other process, which results in random pass. > >>>> Is it possible to not have these when fdo is supported? > >>> Hmm, typo: s/supported/not supported/. > >> > >> I don't see how this can happen: as you can see the .gcda file name > >> is unique for each test case. > >> > >> I think there may be problems with the perf.data, could add a postfix. > >> But you should only see that with real autofdo. > > Don't know. I only configured/built GCC on x86_64 with below command lines: > > > > $ ../gcc/configure --prefix=... > > --enable-languages=c,c++,fortran,go,java,lto,objc,obj-c++ > > --with-build-config=bootstrap-O3 --disable-werror > > $ make && make install > > > > Not sure what the status for autofdo is in this case. "make check -k" > > is stable for me, but "make check -k -j#" gives unstable result in > > tree-prof.exp tests. Anything I did wrong? > > > > Thanks, > > bin > > > > I can confirm that I see the same problem on a Xeon machine (../configure && > make && make check -k -jX). > I see many: > > g++.dg/tree-prof/pr35545.C: Cannot run create_gcov --binary > /home/marxin/Programming/gcc/objdir/gcc/testsuite/g++/pr35545.x01 > --profile=perf.data -gcov_version=1 > --gcov=/home/marxin/Programming/gcc/objdir/gcc/testsuite/g++/pr35545.gcda
Well that's expected if you don't have autofdo installed or perf with lbrs is not working. The test case will be UNSUP in this case. But it's not expected that it is not deterministic, so that it changes run to run. Do you see that? Or some other problem? Please describe it exactly. If yes, did it start before r238320 or only afer? -Andi