search for: cvd3d6

Displaying 4 results from an estimated 4 matches for "cvd3d6".

2020 Oct 01
2
[EXTERNAL] Re: preferred way to return expected values
...d::unique_ptr<derived> d; return d; } That shows whether the compiler's treating the return of a temporary as movable, even when the types aren't an exact match. Clang 3.5 does not support this conversion: https://godbolt.org/z/5nsWM8 GCC 5.1 does support it: https://godbolt.org/z/cvd3d6 & I'm not sure which MSVC version on godbolt would be "MSVC 2017" that the LLVM docs refer to. > > If I understand the produced output correctly, then results are: > > gcc 7.5: creates a copy. > gcc 8.1: uses move. > > clang < 6.0: doesn't compile. &g...
2020 Oct 02
2
[EXTERNAL] Re: preferred way to return expected values
...return d; > } > > That shows whether the compiler's treating the return of a temporary as > movable, even when the types aren't an exact match. > > Clang 3.5 does not support this conversion: https://godbolt.org/z/5nsWM8 > GCC 5.1 does support it: https://godbolt.org/z/cvd3d6 > & I'm not sure which MSVC version on godbolt would be "MSVC 2017" that the > LLVM docs refer to. > > >> >> If I understand the produced output correctly, then results are: >> >> gcc 7.5: creates a copy. >> gcc 8.1: uses move. >> &g...
2020 Oct 02
2
[EXTERNAL] Re: preferred way to return expected values
...t; >> That shows whether the compiler's treating the return of a temporary as >> movable, even when the types aren't an exact match. >> >> Clang 3.5 does not support this conversion: https://godbolt.org/z/5nsWM8 >> GCC 5.1 does support it: https://godbolt.org/z/cvd3d6 >> & I'm not sure which MSVC version on godbolt would be "MSVC 2017" that >> the LLVM docs refer to. >> >> >>> >>> If I understand the produced output correctly, then results are: >>> >>> gcc 7.5: creates a copy. >>...
2020 Sep 28
2
preferred way to return expected values
Many thanks for the reply, right, this is what the discussion is about. On Mon, Sep 28, 2020 at 10:57 AM David Blaikie <dblaikie at gmail.com> wrote: > To clarify, this is a discussion around whether given some move-only type > X, implicitly convertible to Y and the code "Y func() { X x; return x; }" > is that valid in LLVM? (and, as a corollary, if the type isn't