http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59304
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-11-27
CC| |dj at redhat dot com,
| |jsm28 at gcc dot gnu.org,
| |manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Hi DJ,
Do you remember how the push/pop was supposed to work?
I see that push saves
context->push_list[context->n_push ++] = context->n_classification_history;
which is just zero.
Then, the "pragma diagnostic warning" calls control_warning_option which
changes the option flag (enabling it).
The pop operation simply stores one more item in history pointing to item 0,
but it does not modify the option flag.
Then, diagnostic_report_diagnostic simply checks the global option, then
searches the history, finds the pop, which points to zero, so the search stops.
Since nothing has modified diagnostic->kind, then the warning is printed (and
the option is still enabled).
Perhaps the "pop" operation needs to reset whatever was changed since the push.
Or perhaps after a pop that reaches the command-line, we need to check the
original value of the options instead of the current value. I am not sure what
is the best way to do this.
Note that it is not enough to look through the history and undo the changes,
since control_warning_option may have enabled a cascade of options which are
not recorded in the classification history.
Joseph, what do you think can be done here?
