[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 --- Comment #12 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Jun 25 12:43:05 2014 New Revision: 211978 URL: https://gcc.gnu.org/viewcvs?rev=211978root=gccview=rev Log: PR c/61162 * c-parser.c (c_parser_statement_after_labels): Pass the location of the return expression to c_finish_return. * gcc.dg/pr61162.c: Adjust dg-warning. * gcc.dg/pr61162-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr61162-2.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr61162.c
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Marek Polacek mpolacek at gcc dot gnu.org --- Should be fixed now.
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #4 from Tom Tromey tromey at gcc dot gnu.org ---
Note that it is also wrong in the initializer case.
enum e f(void)
{
enum e result = 0;
return result;
}
barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:5:8: warning: enum conversion in initialization is invalid in C++
[-Wc++-compat]
enum e result = 0;
^
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #5 from Tom Tromey tromey at gcc dot gnu.org ---
But, curiously, in this case it points to the RHS of the assignment
(I still tend to think the = is the best location):
extern void *alloc (void);
int *f (void) {
int *r = alloc ();
return r;
}
barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:4:12: warning: request for implicit conversion from ‘void *’ to ‘int *’ not
permitted in C++ [-Wc++-compat]
int *r = alloc ();
^
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org ---
(In reply to Tom Tromey from comment #4)
Note that it is also wrong in the initializer case.
Right, my patch fixes this too.
(In reply to Tom Tromey from comment #5)
But, curiously, in this case it points to the RHS of the assignment
Yeah, this warning comes from a different spot than the previous ones.
(I still tend to think the = is the best location):
extern void *alloc (void);
int *f (void) {
int *r = alloc ();
return r;
}
barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:4:12: warning: request for implicit conversion from ‘void *’ to ‘int *’
not permitted in C++ [-Wc++-compat]
int *r = alloc ();
^
I'd prefer the RHS location here; it's the RHS that's being converted.
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 --- Comment #7 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Marek Polacek from comment #6) I'd prefer the RHS location here; it's the RHS that's being converted. I was hoping to automate some conversion from C to C++ using the error locations. So from this perspective, something relatively consistent would be nice. It could be the RHS or it could be the =, for my purposes they are equally good. I tend to think of the = as being the reason for the conversion, but I wouldn't want to make any claims for it beyond that.
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Tom Tromey from comment #7) (In reply to Marek Polacek from comment #6) I'd prefer the RHS location here; it's the RHS that's being converted. I was hoping to automate some conversion from C to C++ using the error locations. So from this perspective, something relatively consistent would be nice. It could be the RHS or it could be the =, for my purposes they are equally good. I tend to think of the = as being the reason for the conversion, but I wouldn't want to make any claims for it beyond that. If you point to '=', then the macro expansion note will not appear in your other example (PR61165).
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 --- Comment #9 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #8) If you point to '=', then the macro expansion note will not appear in your other example (PR61165). Yeah, I still think the '=' is preferable. I think it lets one know exactly where to insert a cast.
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue May 13 17:41:12 2014 New Revision: 210393 URL: http://gcc.gnu.org/viewcvs?rev=210393root=gccview=rev Log: PR c/61162 * c-typeck.c (convert_for_assignment): Pass location to WARN_FOR_ASSIGNMENT instead of input_location. * gcc.dg/pr61162.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr61162.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 --- Comment #11 from Marek Polacek mpolacek at gcc dot gnu.org --- Not marking this as fixed yet, we should probably address the column info for return stmts.
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-13 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Yep.
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #2 from Tom Tromey tromey at gcc dot gnu.org ---
Note that it is also wrong for a conversion diagnosed
in a return:
enum e { ZERO = 0, ONE };
enum e f(void)
{
return 0;
}
barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:5:3: warning: enum conversion in return is invalid in C++ [-Wc++-compat]
return 0;
^
I think it should point to the expression.
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- I posted a patch, but the location for a return stmt will need more surgery than that.
