On Wed, Apr 25, 2012 at 10:20 AM, Dodji Seketeli <do...@redhat.com> wrote: > Gabriel Dos Reis <g...@integrable-solutions.net> writes: > >> On Wed, Apr 25, 2012 at 9:04 AM, Dodji Seketeli <do...@redhat.com> wrote: >>> In gcc/testsuite/gcc.dg/pr30457.c, the first warning was not being >>> emitted because the relevant location was inside the var_start macro >>> defined in a system header. It can even point to a token for a >>> builtin macro there. This patch unwinds to the first token in real >>> source code in that case. >> >> While you are at it, could you also use a non-zero value for the second >> argument argument to warning_at? > > I couldn't find any obvious value for it. I am thinking maybe it would > make sense to introduction a new -Wva_start to warn about possible > dangerous uses of the va_start macro and use that as the second argument > for the relevant warnings emitted by fold_builtin_next_arg. What do you > think?
or -Wvarargs? > > In any case, this topic seems logically unrelated to the purpose of > enable -ftrack-macro-expansion by default, so IMHO it would be better to > do this in a separate self contain patch. Among other things, this > would ease possible future back-ports. Would you agree? OK. -- Gaby
