> On Tue, Nov 19, 2024 at 11:23:31AM +0100, Jakub Jelinek wrote: > > On Tue, Nov 19, 2024 at 10:25:16AM +0100, Richard Biener wrote: > > > I think it's pretty clear and easy to describe to users what "m " and > > > what "mC" do. But with "pure" this is an odd intermediate state. For > > > both > > > "m " and "mP" you suggest above the new/delete might modify their > > > global state but as you can't rely on the new/delete pair to prevail > > > you cannot rely on the modification to happen. But how do you explain > > > that > > > > If we are willing to make the default not strictly conforming (i.e. > > basically revert PR101480 by default and make the GCC 11.1/11.2 behavior > > the default and allow -fno-sane-operators-new-delete to change to GCC > > 11.3/14.* behavior), I can live with it. > > But we need to make the documentation clear that the default is not strictly > > conforming. > > Here is a modified version of the patch to do that. > > Or do we want to set the default based on -std= option (-std=gnu* implies > -fassume-sane-operators-new-delete, -std=c++* implies > -fno-assume-sane-operators-new-delete)? Though, not sure what to do for > LTO then.
My oriignal plan was to add " sane" attribute to the declarations and prevent them from being merged. Then every direct call to new/delete would know if it came from sane or insane translation unit. Alternatively one can also declare +C++ ObjC++ LTO Var(flag_assume_sane_operators_new_delete) Init(1) +Assume C++ replaceable global operators new, new[], delete, delete[] don't read or write visible global state. as optimization. Then sanity would be function specific. inline_call contains code that drops flag_strict_aliasing for function when it inlines -fno-strict-alising function into -fstrict-aliasing. At same place we can make new/delete operator insanity similarly contagious. If you inline function that has insane new/delete calls you make the combined function also insane. Honza
