Date: Fri, 26 Feb 2016 19:17:24 +0100
On 02/26/2016 01:58 PM, Robert Haberlach wrote:
> On 02/26/2016 12:45 PM, Jens Maurer wrote:
>> On 02/26/2016 01:12 PM, Robert Haberlach wrote:
>>> I apologize in advance if this was discussed before; I didn't check the entire archive. Consider
>>>
>>> static_assert(alignof(float) >= alignof(int) && sizeof(float) >= sizeof(int));
>>> int foo(float f) {
>>> return *std::launder(reinterpret_cast<int*>(&f)); }
>>>
>>> As it stands, invocation of foo is undefined, as the argument to launder is not pointing to an object of type int (or similar) within its lifetime,
>>> violating launder's requirement.
>>>
>>> launder is designed to inhibit address propagation analysis, which is the only concerning optimization. Moreover, as long as all usual conditions are
>>> met (alignment, size & trap values), this should be fine on any implementation. If so, can we make the above formally well-defined?
>>> Being able to use launder in such scenarios would render circumlocutions via memcpy superfluous.
>>
>> That the suggested approach not enough to make this work; see 3.10p10.
>
> Sorry if I was unclear; I didn't (yet) mean to suggest any specific strategy to make this defined. Clearly, more than just the specification of
> launder needs to be adjusted. My question is rather whether allowing the shown code itself is sensible.
I don't think so. It seriously pessimizes type-based alias analysis
for the compiler.
Jens
> On 02/26/2016 12:45 PM, Jens Maurer wrote:
>> On 02/26/2016 01:12 PM, Robert Haberlach wrote:
>>> I apologize in advance if this was discussed before; I didn't check the entire archive. Consider
>>>
>>> static_assert(alignof(float) >= alignof(int) && sizeof(float) >= sizeof(int));
>>> int foo(float f) {
>>> return *std::launder(reinterpret_cast<int*>(&f)); }
>>>
>>> As it stands, invocation of foo is undefined, as the argument to launder is not pointing to an object of type int (or similar) within its lifetime,
>>> violating launder's requirement.
>>>
>>> launder is designed to inhibit address propagation analysis, which is the only concerning optimization. Moreover, as long as all usual conditions are
>>> met (alignment, size & trap values), this should be fine on any implementation. If so, can we make the above formally well-defined?
>>> Being able to use launder in such scenarios would render circumlocutions via memcpy superfluous.
>>
>> That the suggested approach not enough to make this work; see 3.10p10.
>
> Sorry if I was unclear; I didn't (yet) mean to suggest any specific strategy to make this defined. Clearly, more than just the specification of
> launder needs to be adjusted. My question is rather whether allowing the shown code itself is sensible.
I don't think so. It seriously pessimizes type-based alias analysis
for the compiler.
Jens
Received on 2016-02-26 19:23:14