https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #16 from Jason Merrill ---
Author: jason
Date: Thu Jul 21 06:05:39 2016
New Revision: 238560
URL: https://gcc.gnu.org/viewcvs?rev=238560&root=gcc&view=rev
Log:
PR c++/65168 - -Waddress in unevaluated context.
gcc/c-family/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
Patrick Palka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
Manuel López-Ibáñez changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #13 from Patrick Palka ---
Author: ppalka
Date: Sat Jun 13 16:11:15 2015
New Revision: 224455
URL: https://gcc.gnu.org/viewcvs?rev=224455&root=gcc&view=rev
Log:
Emit -Waddress warnings for comparing address of reference against NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #12 from Manuel López-Ibáñez ---
(In reply to Jonathan Wakely from comment #11)
> Great, then my suggestion would be to use exactly the same wording for
> references.
I guess the Clang devs added their wording because someone mistake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #11 from Jonathan Wakely ---
Great, then my suggestion would be to use exactly the same wording for
references.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Jonathan Wakely from comment #9)
> > What about "the address of the object bound to 'r' may be assumed to always
> > convert to true"?
>
> Why only warn about references, and not also for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #9 from Jonathan Wakely ---
(In reply to Manuel López-Ibáñez from comment #8)
> Sure, I was trying to make the Clang message a bit more understandable. I
> got completely confused by "pointer may be assumed to always convert to
> true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Jonathan Wakely from comment #7)
> The diagnostic needs rewording, &r is not the address of a reference, it's
> the address of whatever the reference is bound to. Please don't add
> diagnos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #7 from Jonathan Wakely ---
The diagnostic needs rewording, &r is not the address of a reference, it's the
address of whatever the reference is bound to. Please don't add diagnostics
that talk about something that has no meaning in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||patch
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #5 from Jan Kratochvil ---
(In reply to Manuel López-Ibáñez from comment #3)
> Does this patch work in your real-world code?
There were just many tests like:
if (!&r)
return 0;
So it should really work, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #4 from Manuel López-Ibáñez ---
Or even:
int fii(int p) {
int &r=p;
return !&r;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #3 from Manuel López-Ibáñez ---
I got confused by Clang's message. The problem is not the pointer or NULL. The
problem is converting the address of a reference to bool:
int fii(int *p) {
int &r=*p;
return !&r;
}
This is trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #2 from Jan Kratochvil ---
It should check the '!&r' condition which makes no sense. The variable
initialization in real world programs is too complicated to be able to figure
out it may be NULL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
Manuel López-Ibáñez changed:
What|Removed |Added
Target|x86_64-linux-gnu|
Status|UNCONFIRMED
17 matches
Mail list logo
