https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80390
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Daniel Krügler from comment #6) > Do you recommend to reopen 51222 or should I open a separate bug? I'm > inclined to create a new one at the moment. Agreed, let's have a new bug for that. > Another question I have is the following: What is you main motivation to > introduce the idiom > > struct __uneval_new_t; > inline void* operator new(std::size_t, std::__uneval_new_t*); > decltype(::delete ::new((__uneval_new_t*)0) _Tp(std::declval<_Arg>())) > > compared to the seemingly simpler alternative > > decltype(::delete ::new _Tp(std::declval<_Arg>())) > > ? It's to solve the problem reported in this PR: for over-aligned types we get several lines of output telling us that aligned-new isn't supported without -faligned-new. That isn't useful in this context, because we're not actually trying to allocate it, just test the validity of the expression. It's certainly not useful to the end user, because the new-expression is an implementation detail deep inside libstdc++. By introducing the new overload we avoid that problem, but still test whether the type can be constructed. I could have simply used ::new((void*)0) to use the predefined placement new, but that isn't declared in <type_traits>, so I would have had to add a declaration for it (and that isn't supposed to be declared by <type_traits>).
