[PATCH RFA (construct_at)] c++: new-expr clobber of constant-size array

[Jason Merrill]

On 10/6/25 10:29 AM, Jakub Jelinek wrote:
> On Sat, Oct 04, 2025 at 06:15:49PM +0100, Jason Merrill wrote:
>> Tested x86_64-pc-linux-gnu.  Is the library change OK for trunk?
>>
>> The library patch checks a couple of macros, but I'm not sure that's necessary;
>> can we just assume std::launder in construct_at?
>>
>> -- 8< --
>>
>> I previously tried to clobber an array as a whole, but fell back on a loop
>> due to issues with std::construct_at following the resolution of LWG3436.
>> But the loop seems to make life hard for the optimizers and there was
>> support for reconsidering LWG3436 when I raised the issue on the reflector,
>> so let's pursue that direction.
>>
>> This also fixes some xfails in Warray-bounds-20.C.
> 
> If the intent of this patch is to improve the runtime generated code, I'm
> afraid for construct_at it will be the exact opposite.  The whole array
> clobber will be there but IFN_LAUNDER will hide it from all optimizations,
> so when using the returned pointer it will not know anything about what it
> points to.

Yeah, I suppose the primary purpose of launder is to handle 
non-transparent replacement, and using it to hack 
pointer-interconvertible is sketchy.

But it occurs to me that for T[1] I can just clobber the element type 
and leave construct_at alone, as below.

Tested x86_64-pc-linux-gnu, applying to trunk.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-c-new-expr-clobber-of-constant-size-array.patch
Type: text/x-patch
Size: 4326 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20251007/05f1b3d3/attachment-0001.bin>