C++ PATCH for c++/71913 (copy elision choices)

Jason Merrill jason@redhat.com
Mon Jul 25 18:07:00 GMT 2016


On Mon, Jul 25, 2016 at 7:15 AM, Renlin Li <renlin.li@foss.arm.com> wrote:
> Hi Jason,
>
> On 22/07/16 04:01, Jason Merrill wrote:
>>
>> 71913 is a case where unsafe_copy_elision_p was being too
>> conservative. We can allow copy elision in a new expression; the only
>> way we could end up initializing a base subobject without knowing it
>> would be through a placement new, in which case we would already be
>> using the wrong (complete object) constructor, so copy elision doesn't
>> make it any worse.
>>
>
>> diff --git a/gcc/testsuite/g++.dg/init/elide5.C
>> b/gcc/testsuite/g++.dg/init/elide5.C
>> new file mode 100644
>> index 0000000..0a9978c
>> --- /dev/null
>> +++ b/gcc/testsuite/g++.dg/init/elide5.C
>> @@ -0,0 +1,27 @@
>> +// PR c++/71913
>> +// { dg-do link { target c++11 } }
>> +
>> +void* operator new(unsigned long, void* p) { return p; }
>
>
> g++.dg/init/elide5.C fails on target whose SIZE_TYPE is not "long unsigned
> int".
>
> testsuite/g++.dg/init/elide5.C:4:42: error: 'operator new' takes type
> 'size_t' ('unsigned int') as first parameter [-fpermissive]
>
> I have checked, for most 32 bit architectures or ABI, the SIZE_TYPE is
> "unsigned int". arm is one of them.
>
> To make this test case portable, will __SIZE_TYPE__ be better in this case,
> instead of "unsigned long" as first argument of new operator?

Thanks, I'll fix that shortly.

Jason



More information about the Gcc-patches mailing list