On Thu, Feb 16, 2017 at 01:56:15PM +0300, Alexander Monakov wrote:
> 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?
Are you sure you can't have them in *.c file (e.g. by setting some variable
to a spec string or similar)?
I think it is better to scan all those files.
To avoid triggering this you can e.g. use
--- gcc/config/nvptx/nvptx.c.jj 2017-01-01 12:45:43.000000000 +0100
+++ gcc/config/nvptx/nvptx.c 2017-02-16 12:31:49.261550375 +0100
@@ -1129,7 +1129,7 @@ write_omp_entry (FILE *file, const char
.reg.u32 %r<3>;\n\
.reg.u" PS " %R<4>;\n\
mov.u32 %r0, %tid.y;\n\
- mov.u32 %r1, %ntid.y;\n\
+ mov.u32 %r1, %ntid.y;\n""\
mov.u32 %r2, %ctaid.x;\n\
cvt.u" PS ".u32 %R1, %r0;\n\
" MAD_PS_32 " %R1, %r1, %r2, %R1;\n\
or change the macro so that it doesn't use multi-line string and instead
has say:
"\n\t" "mov.u32 %r1, %ntid.y;"
"\n\t" "mov.u32 %r2, %ctaid.x;"
etc. style. or even just
" mov.u32 %r1, %ntid.y;\n"
" mov.u32 %r2, %ctaid.x;\n"
style.
Jakub
