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