Re: test suite for gcc frontend parser?

"Ira Baxter" <idbaxter@semdesigns.com>
4 Sep 2003 22:43:34 -0400

          From comp.compilers

Related articles
test suite for gcc frontend parser? rizwan@transitive.com (Rizwan Mian) (2003-08-23)
Re: test suite for gcc frontend parser? lex@cc.gatech.edu (Lex Spoon) (2003-09-04)
Re: test suite for gcc frontend parser? idbaxter@semdesigns.com (Ira Baxter) (2003-09-04)
| List of all articles for this month |

From: "Ira Baxter" <idbaxter@semdesigns.com>
Newsgroups: gnu.gcc,comp.compilers
Date: 4 Sep 2003 22:43:34 -0400
Organization: Compilers Central
References: 03-08-072
Keywords: testing, C++
Posted-Date: 04 Sep 2003 22:43:34 EDT

"Rizwan Mian" <rizwan@transitive.com> wrote in message
> I am writing some perl scripts to instrument C++ control flow
> constructs (e.g. functions, if-then-elses etc.) to dump out code
> coverage information.


That sounds painful. In practice, it is hard to get a reliable parse
of a complex language (esp something like C++) unless you essentially
sit down and build a real parser.


> Now, I have the following questions:
> 1. Where can I find the test suite/c++ source files that stresses out
gcc's
> parser for all possible syntax variations when piped through gcc.


No help here.


> 2. Is it all possible that I could use gcc's parser and integrate that
into
> my scripts. Has anybody ever tried that?


I don't know about "tried that", but I thought that there was an
execution-counting tool from the GNU boyz. I didn't look into how it
worked, but my guess was it used the GCC parser. I'd look there.


> 3. Does anybody know of an existing perl c++ parser?


No help here. I'd bet against a robust one existing.
There aren't that many real C++ parsers in the world.


> 4. Can anyone suggest a code coverage tool that is compiler and
architecture
> independent?


Here I can help.
See http://www.semdesigns.com/Products/TestCoverage/TestCoverage.pdf
for how to instrument source code to extract this information.
That is, the basic idea and the machinery are completely independent
of the actual compiler and target architecture.
(We build a whole set of test coverage tools based on this idea).
You can't get out of handling compiler-specific dialect issues.
For instance, MSVC6 has an assembly-langauge
inclusion construct. You have to (conservatively) assume
that the assembly language blob contains a branch, which
implies you must put a test coverage probe following it.
So, your tool has to know the compiler's effective grammer.


> Thanks in advance for your help
> Rizwan


--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.