On Thu, 29 Jan 2015, Mike Stump wrote:
> @@ -5587,6 +5600,12 @@ c_parser_for_statement (c_parser *parser
> "%<GCC ivdep%> pragma");
> cond = error_mark_node;
> }
> + else if (unroll)
> + {
> + c_parser_error (parser, "missing loop condition in loop with "
> + "%<GCC unroll%> pragma");
c_parser_error is for errors with " before <token>" added to them.
It's not clear that's appropriate with this message; it's generally for
"expected <token>" type messages, not for messages where something has
been parsed but is semantically wrong. (Actually, with carets and column
numbers, it's not clear how useful that style of message from the C and
C++ parsers is at all now, and it's not i18n-friendly; see bug 18248. It
may be something that, like reconstructing text approximating a complex
expression in order to include it in a diagnostic, should now be phased
out in favour of other approaches.)
> + {
> + char msgid[150];
> + char num[10];
> + strcpy (msgid, "%<#pragma GCC unroll%> requires an
> assignment-expression"
> + " that evaluates to a non-negative integral constant less than"
> + " or equal to ");
> + sprintf (num, "%u", USHRT_MAX);
> + strcat (msgid, num);
> + c_parser_error (parser, msgid);
In this case, it seems clearly inappropriate, and the building up a
message with sprintf is a further i18n problem. Use error_at, and %u
directly in the format.
> + c_parser_error (parser, "for, while or do statement expected");
This is the sort of case where c_parser_error *is* appropriate (as long as
we use that error style).
--
Joseph S. Myers
jos...@codesourcery.com
