https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724
--- Comment #9 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #5)
> I tried this today with a recent-ish gcc trunk build, and
> there's been a regression.
>
> Now:
>
> barimba. gcc --syntax-only r.c
> r.c: In function ‘docall’:
> r.c:7:10: warning: passing argument 3 of ‘callf’ from incompatible pointer
> type
> return callf (23, 72,
> ^
> r.c:3:5: note: expected ‘int (*)(double *)’ but argument is of type ‘int
> (*)(int *)’
> int callf (int, int, int (*)(double *));
> ^
>
>
> Note how the first warning now points to "callf", whereas
> in comment #0 it pointed to the actual argument causing the diagnostic.
>
> The new situation is much worse for me as it prevents automated
> rewriting...
That is not a regression; previously it didn't point to the actual argument,
but it used input_location, so it pointed to the start of the line. In the
previous testcase it only looks like it's pointing to the last argument. E.g.
on this
int f (int *);
int callf (int, int, int (*)(double *));
int docall(void)
{
return callf (23,
72, f);
}
it will point to "72".
I hope I will have the cycles to look into this this week.
