https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
Sam Varshavchik changed:
What|Removed |Added
CC||mr...@courier-mta.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #14 from Martin Liška ---
(In reply to Marek Polacek from comment #13)
> I would really not like to do that, the false positives rate is pretty low.
You right! I noticed the warning for about 3 packages of 3300 we have in a
testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #13 from Marek Polacek ---
I would really not like to do that, the false positives rate is pretty low.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #12 from Martin Liška ---
(In reply to Marek Polacek from comment #11)
> No, because as Comment 9 says, there's no good way to suppress the warning.
> I'm currently leaning towards closing the BZ and suggesting adding a #pragma
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #11 from Marek Polacek ---
No, because as Comment 9 says, there's no good way to suppress the warning.
I'm currently leaning towards closing the BZ and suggesting adding a #pragma to
disable the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #10 from Martin Liška ---
@Marek, is there any progress on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #9 from Marek Polacek ---
But even that won't work for Wdangling-reference6.C where the argtype is int
but the rettype is std::pair.
Really, all I could do is to warn only when all the arguments to the function
returning a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #8 from Marek Polacek ---
(For std::any et al I guess we also have to look for void*.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #7 from Marek Polacek ---
Sure, I could (lookup_member?). It's still just guessing but maybe it would be
worth it. Let me try...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #5 from Marek Polacek ---
Sorry, I'm not sure if the false positive in comment 0 can be fixed. I can't
simply compare the type of the temporary argument and the return type, because
we may be returning a subobject of the temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #4 from Jonathan Wakely ---
(In reply to Romain Geissler from comment #3)
> In my real life case B was std::string and used a "string literal" at call
> site, and I guess using the implicit conversion from const char[] to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #3 from Romain Geissler ---
In my real life case B was std::string and used a "string literal" at call
site, and I guess using the implicit conversion from const char[] to
std::string is something that might happen in many call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #2 from Andrew Pinski ---
or is it because of the different types? GCC does not look into that either and
does not look into if they are castable either ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #1 from Andrew Pinski ---
So at the warning is not flow sensitive at all and does not take into account
the definition of f; only the call location of f is taken into account.
In this case, the call site of f has a temporary and
17 matches
Mail list logo
