[Bug other/94982] '-Wformat-diag' diagnostics building GCC

2020-11-25 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94982

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Martin Sebor  ---
With the patch committed in r11-5393 an x86_64-linux build should be free of
most if not all -Wformat-diag instances.  I'm going to resolve this as fixed. 
Let's track any outstanding instances or warnings on other targets as separate
bugs.

[Bug other/94982] '-Wformat-diag' diagnostics building GCC

2020-11-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94982

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:ca23341b28cd3af7985b83a6479107d9ea145a90

commit r11-5393-gca23341b28cd3af7985b83a6479107d9ea145a90
Author: Martin Sebor 
Date:   Wed Nov 25 14:05:01 2020 -0700

Clean up -Wformat-diag warnings (PR bootstrap/97622, PR bootstrap/94982)

gcc/c-family/ChangeLog:

PR bootstrap/94982
* c-attribs.c (handle_patchable_function_entry_attribute): Avoid
-Wformat-diag.

gcc/cp/ChangeLog:

PR bootstrap/94982
* constraint.cc (debug_argument_list): Avoid -Wformat-diag.
* error.c (function_category): Same.
(print_template_differences): Same.
* logic.cc (debug): Same.
* name-lookup.c (lookup_using_decl): Same.
* parser.c (maybe_add_cast_fixit): Same.
(cp_parser_template_introduction): Same.
* typeck.c (access_failure_info::add_fixit_hint): Same.

gcc/ChangeLog:

PR bootstrap/97622
PR bootstrap/94982
* config/i386/i386-options.c (ix86_valid_target_attribute_inner_p):
Avoid -Wformat-diag.
* digraph.cc (struct test_edge): Same.
* dumpfile.c (dump_loc): Same.
(dump_context::begin_scope): Same.
* edit-context.c (edited_file::print_diff): Same.
(edited_file::print_diff_hunk): Same.
* json.cc (object::print): Same.
* lto-wrapper.c (merge_and_complain): Same.
* reload.c (find_reloads): Same.
* tree-diagnostic-path.cc (print_path_summary_as_text): Same.
* ubsan.c (ubsan_type_descriptor): Same.

gcc/jit/ChangeLog:

PR bootstrap/94982
* jit-recording.c (recording::function::dump_to_dot): Avoid
-Wformat-diag.
(recording::block::dump_to_dot): Same.

gcc/testsuite/ChangeLog:

PR bootstrap/94982
* c-c++-common/patchable_function_entry-error-3.c: Adjust text
of expected warning.

[Bug other/94982] '-Wformat-diag' diagnostics building GCC

2020-11-24 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94982

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560129.html

[Bug other/94982] '-Wformat-diag' diagnostics building GCC

2020-05-07 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94982

Martin Sebor  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org
   Last reconfirmed||2020-05-07
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Sebor  ---
The breakdown of the -Wformat-diag warnings from a recent x86_64-linux build of
mine is below.  That's about 200.  Where do all the others come from in your
build?

The largest subset of them are coming from the analyzer.  Those I've looked at
are either for calls to logging functions, or to pp_xxx functions that don't
follow the expected format of GCC diagnostics.  I'm not familiar enough with
the analyzer to say what the right way to deal with all those is.  The messages
that are meant to be conform to the same formatting and spelling rules as
diagnostics should be cleaned up.  Those that are more like the output of
-ftree-dump-xxx options should be suppressed (e.g., by a #pragma or by adding a
new attribute to exempt them from the warning).

The second largest subset is in gcc/cp/error.c.  Those are caused by calls to
the pp_xxx functions that compose messages one piece at a time, with the
individual pieces not conforming to the expected format of complete diagnostic
messages.  These should be suppressed (again, either by a #pragma or by adding
a new attribute).

I haven't looked craefully at the rest but I suspect they're in the pp_xxx
category.

My hope and expectation when I introduced the warnings (and kept them from
causing errors) was that they would get cleaned up over the course of GCC 10
development by contributors to and maintainers of the affected areas. 
Unfortunately, not only has that not happened but the error suppression made it
possible for regressions to creep in.

Let me work on cleaning up those outside the analyzer and outside of back ends.
 I'll leave the analyzer to David.  I'm hoping back end maintainers will have
dealt with any warnings there by now however they feel is appropriate.  Once
the remaining instances are all cleaned up I'd like to remove the -Werror
suppression for -Wformat-diag to keep any more regressions from sneaking in
(that's always been the goal).

-Wformat-diag Instances:
  gcc/analyzer/analyzer-logging.cc:174
  gcc/analyzer/analyzer-logging.cc:79
  gcc/analyzer/call-string.cc:97
  gcc/analyzer/checker-path.cc:112
  gcc/analyzer/checker-path.cc:902
  gcc/analyzer/checker-path.cc:916
  gcc/analyzer/checker-path.cc:922
  gcc/analyzer/constraint-manager.cc:574
  gcc/analyzer/constraint-manager.cc:601
  gcc/analyzer/diagnostic-manager.cc:381
  gcc/analyzer/diagnostic-manager.cc:391
  gcc/analyzer/diagnostic-manager.cc:402
  gcc/analyzer/diagnostic-manager.cc:414
  gcc/analyzer/diagnostic-manager.cc:432
  gcc/analyzer/diagnostic-manager.cc:468
  gcc/analyzer/diagnostic-manager.cc:806
  gcc/analyzer/diagnostic-manager.cc:940
  gcc/analyzer/diagnostic-manager.cc:942
  gcc/analyzer/engine.cc:1496
  gcc/analyzer/engine.cc:1508
  gcc/analyzer/engine.cc:1532
  gcc/analyzer/engine.cc:1535
  gcc/analyzer/engine.cc:1536
  gcc/analyzer/engine.cc:2229
  gcc/analyzer/engine.cc:253
  gcc/analyzer/engine.cc:2557
  gcc/analyzer/engine.cc:2573
  gcc/analyzer/engine.cc:2728
  gcc/analyzer/engine.cc:2729
  gcc/analyzer/engine.cc:2730
  gcc/analyzer/engine.cc:2847
  gcc/analyzer/engine.cc:2877
  gcc/analyzer/engine.cc:2932
  gcc/analyzer/engine.cc:2953
  gcc/analyzer/engine.cc:3013
  gcc/analyzer/engine.cc:3016
  gcc/analyzer/engine.cc:3017
  gcc/analyzer/engine.cc:3027
  gcc/analyzer/engine.cc:3061
  gcc/analyzer/engine.cc:3064
  gcc/analyzer/engine.cc:3066
  gcc/analyzer/engine.cc:3067
  gcc/analyzer/engine.cc:3076
  gcc/analyzer/engine.cc:3446
  gcc/analyzer/engine.cc:3509
  gcc/analyzer/engine.cc:3520
  gcc/analyzer/engine.cc:3525
  gcc/analyzer/engine.cc:3540
  gcc/analyzer/engine.cc:3565
  gcc/analyzer/engine.cc:3577
  gcc/analyzer/engine.cc:3589
  gcc/analyzer/engine.cc:3622
  gcc/analyzer/engine.cc:3625
  gcc/analyzer/engine.cc:3769
  gcc/analyzer/engine.cc:389
  gcc/analyzer/engine.cc:416
  gcc/analyzer/engine.cc:572
  gcc/analyzer/engine.cc:846
  gcc/analyzer/engine.cc:871
  gcc/analyzer/engine.cc:903
  gcc/analyzer/program-point.cc:120
  gcc/analyzer/program-state.cc:1072
  gcc/analyzer/program-state.cc:173
  gcc/analyzer/program-state.cc:688
  gcc/analyzer/program-state.cc:69
  gcc/analyzer/program-state.cc:698
  gcc/analyzer/program-state.cc:717
  gcc/analyzer/program-state.cc:726
  gcc/analyzer/program-state.cc:74
  gcc/analyzer/program-state.cc:806
  gcc/analyzer/program-state.cc:928
  gcc/analyzer/region-model.cc:1246
  gcc/analyzer/region-model.cc:1300
  gcc/analyzer/region-model.cc:1306
  gcc/analyzer/region-model.cc:1488
  gcc/analyzer/region-model.cc:1493
  gcc/analyzer/region-model.c