> On 08/22/2013 12:45 PM, Gabriel Dos Reis wrote: > >If the user-supplied operator new returns &a, then it must > >also ensure that 'a' is not used anywhere else -- e.g. I you can't > >do lvalue-to-value conversion on 'a' to see what is written there. > >Because its storage has been reused. That is, aliasing is framed > >in terms of object lifetime and uniqueness of ownership. > > Do you have a reference for this? The wording in 3.8 seems to only > restrict how a pointer is used when there is no object in the > storage, it doesn't say anything about using a pointer to access a > different object at the same location. > > This issue seems to be core 1338: > > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1338 > > which has priority 2, so it's not likely to get resolved any time > soon. I'll ask to reconsider the priority at the next meeting. > > >>We probably can go with -fno-user-overwritten-new or something similar? > > I'd name it something like -fno-aliased-global-new, which would add > the malloc attribute to the built-in declarations.
That sounds good to me. Of course it would be really nice to go for this by default and let users overwritting toplevel new to use an option (like we have -freestanding). Can we consider the original patch (that does not change malloc attributes) and then I can make this as an followup? Also if any of these runtime parts are known to be cold in a way that is not obvious to the backend (i.e. that it is reachable only by EH edges or leading to noreturn), it may be good idea to add cold attribute annotations or use use PREDICT_EXPR to mark the unlikely path. I never tought too much about this, but especially the EH machinery seems to generate a lot of code that is executed only for EH. I would like to try to get reorder-blocks to split those parts away to cold text section just as we do with the profile. Thank you, Honza > > Jason
