On Thu, 16 Feb 2017, Thomas Schwinge wrote:
> On Mon, 9 Jan 2017 17:21:41 +0100, I wrote:
> > On Thu, 29 Dec 2016 16:15:01 +0100, Jakub Jelinek <ja...@redhat.com> wrote:
> > > PR translation/78745
> > > * exgettext: Handle multi-line help texts in *.opt files.
> >
> > With this committed in r243981, I noticed the following new snippet in
> > gcc/po/gcc.pot:
> >
> > +#: config/nvptx/nvptx.c:1132
> > +msgid "tid.y;"
> > +msgstr ""
> >
> > gcc/config/nvptx/nvptx.c:
> >
> > 1126 #define ENTRY_TEMPLATE(PS, PS_BYTES, MAD_PS_32) "\
> > 1127 (.param.u" PS " %arg, .param.u" PS " %stack, .param.u" PS " %sz)\n\
> > 1128 {\n\
> > 1129 .reg.u32 %r<3>;\n\
> > 1130 .reg.u" PS " %R<4>;\n\
> > 1131 mov.u32 %r0, %tid.y;\n\
> > 1132 mov.u32 %r1, %ntid.y;\n\
> > 1133 mov.u32 %r2, %ctaid.x;\n\
> > [...]
> >
> > As I understand it, this is because of the special handling to collect
> > "all %e and %n strings from driver specs, so those can be translated too"
> > (function spec_error_string). Probably harmless enough to just ignore
> > it?
>
> Well, this got reported as part of PR79332. OK to address as follows?
I'm unfamiliar with exgettext (and not objecting to the patch), but from a
quick git-grep it appears that specs strings where this %n/%e capturing needs
to take place only appear in gcc.c and a few .h files. And on the other hand,
there's already a few other .c files under gcc/config/ that use %n/%e in
non-specs context, so I guess there's a risk of false positives elsewhere too.
Would it be acceptable to future-proof it a bit by calling spec_error_string
in exgettext only on *.h files and gcc.c?
Thanks.
Alexander
