[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #21 from David Malcolm --- gcc 8 now underlines the pertinent parameter (as of r253411 and r253096 for C/C++ respectively): C: $ ./xgcc -B. -c t.c t.c: In function ‘docall’: t.c:8:3: warning: passing argument 3 of ‘callf’ from incompatible pointer type [-Wincompatible-pointer-types] f); ^ t.c:3:22: note: expected ‘int (*)(double *)’ but argument is of type ‘int (*)(int *)’ int callf (int, int, int (*)(double *)); ^ C++ (which also now underlines the pertinent argument, as of r256448): $ ./xg++ -B. -c t.c t.c: In function ‘int docall()’: t.c:8:3: error: invalid conversion from ‘int (*)(int*)’ to ‘int (*)(double*)’ [-fpermissive] f); ^ t.c:3:22: note: initializing argument 3 of ‘int callf(int, int, int (*)(double*))’ int callf (int, int, int (*)(double *)); ^
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 Richard Biener changed: What|Removed |Added Target Milestone|5.3 |5.4 --- Comment #19 from Richard Biener --- GCC 5.3 is being released, adjusting target milestone.
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 Manuel López-Ibáñez changed: What|Removed |Added CC|manu at gcc dot gnu.org| Target Milestone|5.4 |--- --- Comment #20 from Manuel López-Ibáñez --- Only regressions have target milestone.
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.2 |5.3 --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org --- GCC 5.2 is being released, adjusting target milestone to 5.3.
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |5.2 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 5.1 has been released.
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #15 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Marek, is this fixed? Can we close it?
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #16 from Marek Polacek mpolacek at gcc dot gnu.org --- What's not fixed is this: r.c:3:5: note: expected ‘int (*)(double *)’ but argument is of type ‘int (*)(int *)’ int callf (int, int, int (*)(double *)); ^ we should point to the actual parameter. I think PR60129 is a dupe for this, though. We'll probably have to add some *location_t stuff into the function_decl or somewhere for this...
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #14 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Jun 5 09:35:05 2014 New Revision: 211261 URL: http://gcc.gnu.org/viewcvs?rev=211261root=gccview=rev Log: PR c/56724 * c-typeck.c (convert_for_assignment): Use expr_loc for ic_argpass. * gcc.dg/pr56724-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr56724-3.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724
--- Comment #12 from Tom Tromey tromey at gcc dot gnu.org ---
I noticed this patch today and tried it out on my current
test case, which uses -Wc++-compat... unfortunately it
still fails.
Test code:
extern void xfer (int, int, unsigned char *);
void call (int x, int y, void *arg)
{
xfer (x, y, arg);
}
barimba. gcc --syntax-only -Wc++-compat /tmp/r.c
/tmp/r.c: In function ‘call’:
/tmp/r.c:5:3: warning: request for implicit conversion from ‘void *’ to
‘unsigned char *’ not permitted in C++ [-Wc++-compat]
xfer (x, y, arg);
^
I think perhaps the problem is that the warning_at call in
convert_for_assignment that emits this warning should use
expr_loc rather than 'location'. I haven't tested this theory.
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #13 from Marek Polacek mpolacek at gcc dot gnu.org --- Yea, you're right, not everything has been fixed. I'll fix up this specific case in a bit, thanks for reporting it.
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #11 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue May 27 20:14:22 2014 New Revision: 210980 URL: http://gcc.gnu.org/viewcvs?rev=210980root=gccview=rev Log: PR c/56724 * c-typeck.c (convert_arguments): Get location of a parameter. Change error and warning calls to error_at and warning_at. Pass location of a parameter to it. Call warning_at with OPT_Wtraditional_conversion. (convert_for_assignment): Add parameter to WARN_FOR_ASSIGNMENT and WARN_FOR_QUALIFIERS. Pass expr_loc to those. * gcc.dg/pr56724-1.c: New test. * gcc.dg/pr56724-2.c: New test. * gcc.dg/wtr-conversion-1.c: Use -Wtraditional-conversion instead of -Wtraditional. * gcc.dg/dfp/wtr-conversion-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr56724-1.c trunk/gcc/testsuite/gcc.dg/pr56724-2.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/dfp/wtr-conversion-1.c trunk/gcc/testsuite/gcc.dg/wtr-conversion-1.c
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Version|unknown |4.10.0 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Taking now.
[Bug c/56724] sub-optimal location in error
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.
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #8 from Manuel López-Ibáñez manu 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. I think the problem is that convert_for_assignment uses location instead of expr_loc. The original issue is harder to fix. I am not sure we have locations for the different types in a function declaration, do we?
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #5 from Tom Tromey tromey at gcc dot gnu.org --- 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...
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Tom Tromey from comment #5) The new situation is much worse for me as it prevents automated rewriting... What automated rewriting? For 4.10/11, I would like to implement either fix-it hints or location ranges, and I wonder what would be the most useful of the two.
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #7 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #6) (In reply to Tom Tromey from comment #5) The new situation is much worse for me as it prevents automated rewriting... What automated rewriting? I'm experimenting with automated rewriting of C to C++ using -Wc++-compat and some scripts. https://github.com/tromey/gdb-refactoring-scripts It's fairly specific to gdb.
[Bug c/56724] sub-optimal location in error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-26 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. I though about tweaking this, too. I may look at it in next stage1, but not assigning right now.
[Bug c/56724] sub-optimal location in error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #1 from Tom Tromey tromey at gcc dot gnu.org 2013-03-25 18:44:37 UTC --- This affects g++ as well.
[Bug c/56724] sub-optimal location in error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-25 18:45:24 UTC --- (In reply to comment #0) t.c: In function ‘docall’: t.c:8:3: warning: passing argument 3 of ‘callf’ from incompatible pointer type [enabled by default] If you have many parameters, it can be hard to find the right one. Though it does say the 3rd argument though.
[Bug c/56724] sub-optimal location in error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #3 from Tom Tromey tromey at gcc dot gnu.org 2013-03-25 18:46:47 UTC --- (In reply to comment #2) Though it does say the 3rd argument though. Sure, it is just nicer if the compiler counts commas instead of me doing it.
