Hi Vegard,

On 03/13/2018 12:08 PM, Vegard Nossum wrote:

First of all, thanks for C-reduce! It's extremely useful and valuable.

I am trying to run C-reduce on a large number of (large-ish,
preprocessed) source files and I have run into the following problems
and/or minor annoyances:

Especially for sources that crash the compiler, programs often come
out with syntax errors and warnings, even though the syntax was fine
in the original program. One mitigation I have found that helps to a
certain degree is to test that the number of braces ("(", ")", "[",
"]", "{", "}", "<", ">") match up in the acceptance script, but this
breaks down if those characters are present and/or unbalanced, say, in
source comments or string literals.

There are other syntax errors which are introduced as well, for
example the removal of semicolons and return values (and return
statements). A mitigation for this is to count the number of warnings
in the original file, pass it to the acceptance script through, say,
an environment variable, and make sure that number never increases.
There are drawbacks, though: if there are any warnings to start with,
these could disappear and new ones be introduced (i.e. there is no
easy way to force this number to always go down). It also slows down
the whole reduction process by a ridiculous amount, going from maybe 1
minute to over 10 for the initial passes alone.

Another mitigation is of course passing -Werror to have those warnings
turned into errors, but again that only works if the original source
does not have those warnings to start with.

My final script uses a combination of brace counting, -Werror=
options, and stderr grepping, but it's far from perfect and it's
actually a huge slowdown compared to just using a dumb script and then
fixing up the resulting test case by hand (i.e. adding "void" or "int"
where the return type is missing, adding "return 0;" statements to the
end of functions, etc.).

I am not sure, but it seems like there might be a small number of
passes responsible for introducing the worst of these syntax errors.

Any hints, tips, or ideas for how to improve the situation? Could it
be possible to provide a command-line switch that will skip passes
that remove "too much"?

C-Reduce doesn't have a mode where it could only produce syntactically correct outputs or work towards producing less invalid outputs. There are quite a few passes that can introduce syntax-related errors. At the moment, I couldn't think of a better way to avoid that except massaging the script as you did.  Sorry for the inconvenience.

Another thing I noticed is that C-reduce often leaves superfluous
try...catch statements. I've often found the final output to contain a
try...catch that could simply be substituted by either just the
try-block, just the catch-block(s), just the catch-declaration(s), or
the concatenation of a combination of them (without the "try" and
"catch" themselves obviously).

Yes, this is a known issue. Currently, C-reduce doesn't have a specific pass for processing try/catch statements.

- Yang

Reply via email to