[C++ patch] Set attributes for C++ runtime library calls

Gabriel Dos Reis gdr@integrable-solutions.net
Mon Aug 26 14:48:00 GMT 2013


On Mon, Aug 26, 2013 at 9:38 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> 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).

Hmm, let's not make it a default.  Replacing global operator new (e.g. for
tracing purposes) is a valid C++ programming idiom.

>
> 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



More information about the Gcc-patches mailing list