https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102223

--- Comment #6 from Federico Kircheis <federico.kircheis at gmail dot com> ---
> are you expecting this to go under an existing warning flag, or a new one?

Ideally -Wall, but there might already be some flags related to dangling
pointers and references.

> Your compiler explorer link doesn't enable optimizations.

That's true, but if you look at the assembly there is no function call to
std::move, thus I assumed that contrary to another (non-inline) function call,
a diagnostic would have been possible even without optimizations.
But there is no warning even with optimizations enabled.


> I assume you already know this, but the original testcase in comment 0 is 
> perfectly valid. The static_cast creates a new temporary, which *does* get 
> its lifetime extended.


Yes, should have made it clearer in comment #1, sorry.
Unfortunately I realized after I wrote the message that I copied the wrong
snippet (and typed thus a wrong explanation), and I could not edited it.

> With inlining, in theory it would be possible to diagnose the invalid access, 
> but other compilers don't do it either. It would be nice, but I'm not sure 
> it's likely to happen any time soon.

I noticed too that other compiler do not do this diagnostic.
Too bad.


> GCC doesn't even get it right in constexpr contexts, see PR 70331 and the 
> linked bugs in the See Also field.

Ouch.


> PR 96780 comment 2 could potentially help for the specific case of std::move, 
> but not the general case.


AS I had a discussion explicitly about std::move/xvalues and lifetime
extension, I'll say it's a good start.
And it confused me until I realized std::move is a function, and thus obviously
destroys lifetime extension in the example I gave, while the cast not.


> N.B AddressSanitizer will diagnose this at runtime.
+1

Reply via email to