https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 12 Apr 2023, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442 > > --- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> --- > (In reply to Jonathan Wakely from comment #10) > > I would prefer if we don't deviate, and get Clang to clarify things instead > > of reinventing something that looks similar but isn't. > > I suppose as long as the common subset of semantics that the library cares > about works the same way, it's OK. > > It would be bad if the library needs to use extra checks beyond __has_builtin > to discover which "flavour" of __builtin_operator_new is present. So if we can get clarification that __builtin_operator_new/delete allow at least all transforms as if using a new or delete expression then we can use the same representation as that in the middle-end for now (just set the CALL_FROM_NEW_OR_DELETE_P flag). If the builtins provide _additional_ guarantees then we can make use of those only when we extend things on the middle-end side. Now we then only need to make the C++ frontend "mangle" the __builtin_operator_new/delete calls to the "correct" allocation function. I suppose the goal is to resolve to exactly the same symbols as when not using the builtins.
