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

[Jakub Jelinek]

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.

I've briefly thought about trying to pattern match the build_vec_init
with CLOBBER inside of it in cp-gimplify.cc and turn it into a single
whole array clobber, but because it is recursive and emits quite a lot
of code, I think it wouldn't be that easy.

Another option would be to emit both with
  if (__builtin_is_constant_evaluated ())
    whole_array = {CLOBBER(bob)};
  else
    vec_init (CLOBBER(bob)};
but that has the drawback that it makes all mce_unknown evaluation
non-constant.  So, could we have a "__builtin_is_constant evaluated" variant
thereof which would be true for mce_unknown/mce_true and false for
mce_false and guard this with that front-end builtin instead (of course
not exposed to users and only used internally where we prefer some different
IL for constant evaluation compared to runtime)?

	Jakub