This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Understand GCC test process

On 7 October 2015 at 16:45, Sabrina Souto <> wrote:
>> What exactly are you tracing, and how?
> I'm proposing an approach for testing configurable system in my
> research, and I'm trying to apply it to GCC. So, I instrumented the
> GCC function calls (in the first level of ..gcc-version-x.x/gcc/ and
> the dirs related to C/C++) and some options, in a semi-automatic way
> (I tried to use PIN, but it was very slow...).
>> Are you only tracing the 'gcc' driver? Or every process and child
>> process that gets spawned by 'make'?
> I'm tracing the 'gcc' driver.

OK, all that does is process some options and then call another
executable, which does the actual compilation.

To compile C code it calls cc1, to compile C++ code it calls cc1plus etc.

So if you're only tracing the 'gcc' driver then you are basically only
tracing the code for parsing command-line arguments and choosing which
compiler to execute.

>> Typically to run the testsuite you run 'make', which runs DejaGnu's
>> 'runtest' shell script, which runs the 'expect' program (written in
>> Tcl), which invokes the 'gcc' driver, which invokes the actual
>> compiler, 'cc1', to compile a testcase. So a lot of that is common to
>> every testcase.
> Do you mean, for example, that the compiler will always build the AST,
> translate to intermediary code representations, etc., regardless of
> the compilation option... and it corresponds to a lot of common code
> across all tests?

No, for example if it is run with -E it will only do preprocessing.

But you're not tracing the compiler anyway. The 'gcc' executable is
not the compiler.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]