On 1/10/21 3:29 AM, Matthias Klose wrote:
On 1/9/21 11:22 PM, Jakub Jelinek wrote:
On Sat, Jan 09, 2021 at 07:44:31PM +0100, Matthias Klose wrote:
These warnings, including the suggested fixes are seen on power*-linux builds.

warning: misspelled term 'builtin function' in format; use 'bult-in function'

Are you sure it printed bult-in ?

      fatal_error (input_location,
-                "internal error: builtin function %qs already processed",
+                "internal error: builtin-function %qs already processed",

It meant built-in function instead of builtin-function I'm pretty sure.

                 name);
rs6000_builtin_decls[(int)code] = t =
@@ -11219,7 +11219,7 @@ altivec_expand_builtin (tree exp, rtx target, bool 
*expandedp)
        {
          size_t uns_fcode = (size_t) fcode;
          const char *name = rs6000_builtin_info[uns_fcode].name;
-         error ("Second argument of %qs must be in the range [0, 3].", name);
+         error ("Second argument of %qs must be in the range [0, 3]", name);

Diagnostics shouldn't start with capital letter either, so it should be
"second ..."
-                "internal error: builtin function %qs had an unexpected "
+                "internal error: builtin-function %qs had an unexpected "
                 "return type %qs", name, GET_MODE_NAME (h.mode[0]));
-                    "internal error: builtin function %qs, argument %d "
+                    "internal error: builtin-function %qs, argument %d "

See above.

ahh, my bad. verschlimmbessert ...

fixed version attached. While looking at all -Wformat-diag warnings ...

../../src/gcc/emit-rtl.c: In function 'rtx_insn* make_insn_raw(rtx)':
../../src/gcc/emit-rtl.c:4038:25: warning: unquoted identifier or keyword
'emit_insn' in format [-Wformat-diag]
  4038 |       warning (0, "ICE: emit_insn used where emit_jump_insn 
needed:\n");
       |                         ^~~~~~~~~
../../src/gcc/emit-rtl.c:4038:46: warning: unquoted identifier or keyword
'emit_jump_insn' in format [-Wformat-diag]
  4038 |       warning (0, "ICE: emit_insn used where emit_jump_insn 
needed:\n");
       |                                              ^~~~~~~~~~~~~~
../../src/gcc/emit-rtl.c:4038:68: warning: unquoted whitespace character '\x0a'
in format [-Wformat-diag]
  4038 |       warning (0, "ICE: emit_insn used where emit_jump_insn 
needed:\n");
       |

genautomata has `%s' hardcoded, while other places have %q+F. What is the
preferred way?

is the newline intended? It's followed by a debug_rtx call.

To avoid the warning there shouldn't be any trailing punctuation
or whitespace in the message.  The GCC quoting directives should
be preferred over the literal characters (as per GCC Coding
Conventions).  %qc and %qs are preferable to %<%c%>.

Symbols/identifiers should be formatted using the appropriate
directives or quoted in %< %>.  Underscores in words like
emit_insn are taken as indicators that the word is an identifier
and to trigger warnings.



../../src/gcc/rtl.c:860:42: warning: unquoted sequence of 2 consecutive
punctuation characters '',' in format [-Wformat-diag]
   860 |     ("RTL check: expected elt %d type '%c', have '%c' (rtx %s) in %s, 
at
%s:%d",

`%c', or some %q quoting?

The purpose of the -Wformat-diag warnings is to improve the consistency
of user-visible messages and make them easier to translate.  There was
a discussion some time back about whether internal errors should fall
into this category.  I'm not sure if it reached a conclusion one way
or the other but in similar situations elsewhere in GCC we have
suppressed the warning via #pragma GCC diagnostic.  If it takes too
much effort to clean them up it might make sense to do the same here
(the downside is that it doesn't help translators).  Otherwise,
the messages are not really phrased in a way that's comprehensible
either to users or to tranlators (acronyms like elt or rtx aren't universally understood).


../../src/gcc/config/rs6000/rs6000.c: In function 'void rs6000_emit_move(rtx,
rtx, machine_mode)':
../../src/gcc/config/rs6000/rs6000.c:10330:16: warning: contraction 'can't' in
format; use 'cannot' instead [-Wformat-diag]
10330 |         error ("%qs is an opaque type, and you can't set it to other
values.",
       |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../src/gcc/config/rs6000/rs6000.c:10330:16: warning: spurious trailing
punctuation sequence '.' in format [-Wformat-diag]
../../src/gcc/config/rs6000/rs6000.c: In function 'tree_node*
rs6000_handle_altivec_attribute(tree_node**, tree, tree, int, bool*)':
../../src/gcc/config/rs6000/rs6000.c:19811:12: warning: misspelled term
'floating point' in format; use 'floating-point' instead [-Wformat-diag]
19811 |     error ("use of decimal floating point types in AltiVec types is
invalid");
       |            
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../src/gcc/config/rs6000/rs6000.c: In function 'tree_node*
rs6000_get_function_versions_dispatcher(void*)':
../../src/gcc/config/rs6000/rs6000.c:24597:17: warning: unquoted keyword 'ifunc'
in format [-Wformat-diag]
24597 |                 "multiversioning needs ifunc which is not supported "
       |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
24598 |                 "on this target");


again, `' quotes, or some %q option?


The latter: %qs with an argument is best in general (it can reduce
translation effort between repeated messages parameterized on
the quoted string).

Martin

Reply via email to