This is the mail archive of the
mailing list for the GCC project.
Re: Understand GCC test process
- From: Martin Sebor <msebor at gmail dot com>
- To: Sabrina Souto <sabrinadfs at gmail dot com>, Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 07 Oct 2015 09:25:34 -0600
- Subject: Re: Understand GCC test process
- Authentication-results: sourceware.org; auth=none
- References: <CAA1wpi1MCPPBqmr2iCKmpdiG5gu5zL=MOAx+y1cEtfzxkMajLg at mail dot gmail dot com> <CAH6eHdSaqsn8xDSG46GwMvgVjGOoRoPtkXC5t+AbAvg=_jkkkA at mail dot gmail dot com> <CAA1wpi3y_SO8s_pjaZS-fC6GgfkuDCOnnaQNurDJkZi1kqJY7w at mail dot gmail dot com> <CAH6eHdTwhgLHWQhsdrB9ZUX3=LD3m-m=hBGXswmyT0c2+c5DHQ at mail dot gmail dot com> <CAA1wpi22TZ=awDNWRBtechjamK+T+Z3LiB7GnsnXO1sdMUxp2w at mail dot gmail dot com>
On 10/07/2015 07:57 AM, Sabrina Souto wrote:
I was seeing these files but I could not put the puzzle pieces
together in my mind, and after you explained, all pieces make sense
now. Thanks for the explanation, Jonathan.
The testing process is clear now, but I still not understanding what
can explain that amount of common functions (over 60%) across all
traces of the tests (that I analyzed) from gcc.dg test suite, could
you help me with this? I have some hypotheses:
(1) All tests run the compiler and there is a large "core" code that
is executed regardless of the compiler option?
(2) Since all tests run the same driver - dg.exp, I could say that
this great amount of common functions is due to what is specified in
the driver, and the remaining few different functions are related with
the particularity of each test?
(3) None of those. Do you have another explanation?
I'm not sure what you mean by "function" (compiler invocations?)
or "trace" (verbose DejaGnu output?) but perhaps what you are
referring to by "common functions across all traces" is the test
driver invoking the compiler and running tests to figure out what
features are supported on the target.
For example, running just the simple array-1.c test like so:
$ make RUNTESTFLAGS='dg.exp=array-1.c -v -v' check-gcc
will show something like:
check_compile tool: gcc for lto
Invoking the compiler as ...
check_compile tool: gcc for linker_plugin
Invoking the compiler as ...
Invoking the compiler as...
More involved tests (those with more complex DejaGnu directives)
might cause the driver to run other tests. The results of these
should be cached so subsequent tests that depend on the results
don't cause the same tests to be run again.
If by the "function" you mean a DejaGnu function, you need to look
at the .exp files to see what's invoked when: your local runtest.exp
which is invoked first, and then GCC's dg.exp (and anything in
between). You can see the pathnames of all the .exp files in the
DejaGnu verbose output (-v -v).
The best way to understand how it all works is to read the .exp
files and experiment with some increasingly more involved use cases,
study their verbose output and the .log files in the corresponding