Re: [creduce-dev] Avoiding syntax warnings and errors
Hi Moritz, Thanks for the prompt patch! On 2018-03-15 02:52, Moritz Pflanzer wrote: Hi John, On 14 Mar 2018, at 14:53, John Regehr wrote: Regarding try-catch, yes, we'd like to have a pass for that. I added a note about this to our TODO list, but mostly we're too busy for adding new stuff these days. I quickly created a simple clang_delta pass to remove/simplify try-catch constructs. For more details have a look at the pull request: https://github.com/csmith-project/creduce/pull/157 For now it is fairly simple but I think it should help already against useless try-catch blocks. Later we could have a more advanced pass to keep only catch-blocks or to concatenate them with the try-block. I will take a look at it today if I can find some time. Otherwise, I will go through it over the weekend. - Yang
Re: [creduce-dev] Avoiding syntax warnings and errors
Hi John, > On 14 Mar 2018, at 14:53, John Regehr wrote: > > Regarding try-catch, yes, we'd like to have a pass for that. I added a note > about this to our TODO list, but mostly we're too busy for adding new stuff > these days. I quickly created a simple clang_delta pass to remove/simplify try-catch constructs. For more details have a look at the pull request: https://github.com/csmith-project/creduce/pull/157 For now it is fairly simple but I think it should help already against useless try-catch blocks. Later we could have a more advanced pass to keep only catch-blocks or to concatenate them with the try-block. Let me know what you think. Moritz
Re: [creduce-dev] Avoiding syntax warnings and errors
Hi Vegard, I'll agree with Yang that the point of C-Reduce is basically
to *not* worry about any of the things you mention, deferring those
problems to the interestingness test.
I typically include some tests for warnings in the interestingness test,
or else just manually fix up the warnings at the end, once reduction
finishes. If the final output is less than a couple hundred bytes, this
is usually easy.
Those things said, you can probably disable some of the problematic
passes, but I don't think any of us has ever tried to do that.
Regarding try-catch, yes, we'd like to have a pass for that. I added a
note about this to our TODO list, but mostly we're too busy for adding
new stuff these days.
John
On 3/14/18 12:47 AM, Yang Chen wrote:
Hi Vegard,
On 03/13/2018 12:08 PM, Vegard Nossum wrote:
Hi,
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
Re: [creduce-dev] Avoiding syntax warnings and errors
Hi Vegard,
On 03/13/2018 12:08 PM, Vegard Nossum wrote:
Hi,
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
