https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #12 from Marek Polacek ---
Author: mpolacek
Date: Wed Jun 25 12:43:05 2014
New Revision: 211978
URL: https://gcc.gnu.org/viewcvs?rev=211978&root=gcc&view=rev
Log:
PR c/61162
* c-parser.c (c_parser_statement_after_labels): Pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #11 from Marek Polacek ---
Not marking this as fixed yet, we should probably address the column info for
return stmts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #10 from Marek Polacek ---
Author: mpolacek
Date: Tue May 13 17:41:12 2014
New Revision: 210393
URL: http://gcc.gnu.org/viewcvs?rev=210393&root=gcc&view=rev
Log:
PR c/61162
* c-typeck.c (convert_for_assignment): Pass location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #9 from Tom Tromey ---
(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 l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #7 from Tom Tromey ---
(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 th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #6 from Marek Polacek ---
(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 poi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #5 from Tom Tromey ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #4 from Tom Tromey ---
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 conversio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #3 from Marek Polacek ---
I posted a patch, but the location for a return stmt will need more surgery
than that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #2 from Tom Tromey ---
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: warnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
13 matches
Mail list logo
